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 16:56:13 +0000
On 31/12/2020 16:54, Tomalak Geret'kal wrote:
> On 31/12/2020 16:52, Tomalak Geret'kal wrote:
>> Per the headers, it's gzip-encoded. If you output to
>> out.html.gzip, then unzip, it'll be fine.
>>
>> I don't know why this just happened. I would have thought
>> curl would auto decode the contents to be honest.
>>
>> curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0
>> NSS/3.53.1 zlib/1.2.7 libidn/1.28 libssh2/1.8.0
>> Protocols: dict file ftp ftps gopher http https imap imaps
>> ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
>> Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM
>> NTLM_WB SSL libz unix-sockets
>>
>> Tom
>>
> By the way, passing --compressed will request a gzip encoded
> response then also decompress the result automatically.
>
> Perhaps there's a bug with curl not decoding regardless
> (based on response headers), and/or perhaps Amazon only just
> started gzip-encoding the response regardless of the request
> headers.
>
> Cheers
>
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
-------------------------------------------------------------------
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 16:56:13 +0000
On 31/12/2020 16:54, Tomalak Geret'kal wrote:
> On 31/12/2020 16:52, Tomalak Geret'kal wrote:
>> Per the headers, it's gzip-encoded. If you output to
>> out.html.gzip, then unzip, it'll be fine.
>>
>> I don't know why this just happened. I would have thought
>> curl would auto decode the contents to be honest.
>>
>> curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0
>> NSS/3.53.1 zlib/1.2.7 libidn/1.28 libssh2/1.8.0
>> Protocols: dict file ftp ftps gopher http https imap imaps
>> ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
>> Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM
>> NTLM_WB SSL libz unix-sockets
>>
>> Tom
>>
> By the way, passing --compressed will request a gzip encoded
> response then also decompress the result automatically.
>
> Perhaps there's a bug with curl not decoding regardless
> (based on response headers), and/or perhaps Amazon only just
> started gzip-encoding the response regardless of the request
> headers.
>
> Cheers
>
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
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-31