cURL / Mailing Lists / curl-users / Single Mail

curl-users

--tr-encoding and HTTP/2

From: Ricki Hirner <r_at_hirner.at>
Date: Sat, 29 Oct 2016 11:18:26 +0200

Hello,

While researching which Web servers/sites support Transfer-Encoding
(because Content-Encoding makes so many problems, especially in
WebDAV/CalDAV/CardDAV context; for instance, GET on a calendar resource
with "Content-Encoding: gzip" returns another ETag as without gzip,
which makes the ETag unusable for further conditional requests),
I tried

curl --tr-encoding https://www.google.com

and was surprised to see it fails (when HTTP/2 is enabled):

-----------
$ curl -vv --tr-encoding https://www.google.com
[…]
* Connected to www.google.com (172.217.21.228) port 443 (#0)
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55ccac3e7aa0)
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.47.1
> Accept: */*
> Connection: TE
> TE: gzip

* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* HTTP/2 stream 1 was not closed cleanly: error_code = 1
* Closing connection 0
curl: (16) HTTP/2 stream 1 was not closed cleanly: error_code = 1
-----------

Tried with:

curl 7.47.1 (x86_64-redhat-linux-gnu) libcurl/7.47.1 NSS/3.26 zlib/1.2.8 libidn/1.33 libpsl/0.13.0 (+libidn/1.33) libssh2/1.7.0 nghttp2/1.7.1
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets Metalink PSL 

and

curl 7.50.3 (amd64-portbld-freebsd10.3) libcurl/7.50.3 OpenSSL/1.0.1s zlib/1.2.8 libidn/1.33 nghttp2/1.15.0
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz HTTP2 UnixSockets 

With --http1.1 or without --tr-encoding, there are no such problems.
Is this a curl or a Google problem? Do I have to expect many problems
when trying to use Transfer-Encoding in the real world?

Thanks,
Ricki
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-users
FAQ: https://curl.haxx.se/docs/faq.html
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-10-29