Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: CURLOPT_ACCEPT_ENCODING not working (help)
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Adrián Gimeno Balaguer via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 12 Feb 2021 13:32:12 +0100
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.
Date: Fri, 12 Feb 2021 13:32:12 +0100
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.htmlReceived on 2021-02-12