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: Binary garbage for amazon?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Tomalak Geret'kal via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 31 Dec 2020 17:10:48 +0000
On 31/12/2020 16:56, Tomalak Geret'kal via curl-library wrote:
> Okay, this has been discussed before
> (https://github.com/curl/curl/issues/3192) and is deemed
> by-design for compatibility reasons.
>
> I guess Amazon returning gzipped data regardless of the
> request headers is new (but not, in itself, erroneous).
>
> Sorry for the multi-email response :P
>
> Cheers
Again here
(https://github.com/curl/curl/issues/2836#issuecomment-410604612).
However, I believe Daniel's response there is at least
partially incorrect:
> The server shouldn't send |content-encoding: gzip| without
the client having signaled that it is acceptable.
Not so! HTTP 1.1 §5.3.4
<https://tools.ietf.org/html/rfc7231#section-5.3.4>
(https://tools.ietf.org/html/rfc7231#section-5.3.4) says:
"If no Accept-Encoding field is in the request, any
content-coding is considered acceptable by the user agent."
> Besides, when you don't use |--compressed| with curl, you
tell the command line tool you rather store the exact stream
(compressed or not). I don't see a curl bug here...
This does make some sense, though.
Unfortunately it means that, unless you specifically provide
an Accept-Encoding request header, you ALWAYS have to parse
the headers to find out how the response is actually encoded
before you can use it in its logical ("real") representation.
Frankly, in my opinion, if a script is relying on this
behaviour, it should be modified to specify the exact
encoding of the data it wants to receive, and we should make
curl abide by the response headers.
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-31
Date: Thu, 31 Dec 2020 17:10:48 +0000
On 31/12/2020 16:56, Tomalak Geret'kal via curl-library wrote:
> Okay, this has been discussed before
> (https://github.com/curl/curl/issues/3192) and is deemed
> by-design for compatibility reasons.
>
> I guess Amazon returning gzipped data regardless of the
> request headers is new (but not, in itself, erroneous).
>
> Sorry for the multi-email response :P
>
> Cheers
Again here
(https://github.com/curl/curl/issues/2836#issuecomment-410604612).
However, I believe Daniel's response there is at least
partially incorrect:
> The server shouldn't send |content-encoding: gzip| without
the client having signaled that it is acceptable.
Not so! HTTP 1.1 §5.3.4
<https://tools.ietf.org/html/rfc7231#section-5.3.4>
(https://tools.ietf.org/html/rfc7231#section-5.3.4) says:
"If no Accept-Encoding field is in the request, any
content-coding is considered acceptable by the user agent."
> Besides, when you don't use |--compressed| with curl, you
tell the command line tool you rather store the exact stream
(compressed or not). I don't see a curl bug here...
This does make some sense, though.
Unfortunately it means that, unless you specifically provide
an Accept-Encoding request header, you ALWAYS have to parse
the headers to find out how the response is actually encoded
before you can use it in its logical ("real") representation.
Frankly, in my opinion, if a script is relying on this
behaviour, it should be modified to specify the exact
encoding of the data it wants to receive, and we should make
curl abide by the response headers.
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-31