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
