Hi Ray, > Please do not top-post it makes the conversation hard to follow. [1]
Ok. Thanks for correcting me. > It looks like you have solved the first problem and your build is able to > decode compressed content. Right. However, the key fact that has recently confirmed it's correctly working against it is that, while initially I thought their response was the same independently of the ACCEPT_ENCODING being set (case A) or not (case B), I only recently realized they were different in both cases, and that through external tools, manually decompressing the response on case A (doubly compressed) effectively matches the response on case B (singly compressed), whereas decompressing B finally produces the expected human-readable XML output. > I reiterate don't set ACCEPT_ENCODING to specific encodings. Well, I don't see a problem with it since their service specifications state they'll send GZIP compressed responses. > Your second problem seems to be with a specific server that you request gzip > encoding (accept-encoding) and it returns gzip encoding (content-encoding). > Does curl_easy_perform return an error? If not then curl should have received > and decoded the data. No, curl_easy_perform() always returns CURLE_OK (0). Otherwise, the program logs an error and doesn't handle the response. I contacted them showing how my library already performs automatic decompression, attaching both responses with both ACCEPT_ENCODING on/off setups (for same input), and saying it would make no sense at all that our system is compressing the data (original XML) on reception as they claimed, also against our will. No answer yet. If somewhat useful, they seem to be using JBoss. -- Adrián ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
