If a service returns a different ETag simply because the request allows
different content encoding, that is a problem with the server. ETags should
only change when the object at the URL has different content.

Have you observed this for more than one service, or is it a single service
only?

Even though the ETag is different between zip and non-zip, is it at least
consistent for each? If it is consistent across with zip calls, then there
would be a reload hiccup on the transition to zip, but after that ETag
processing would still work as expected.

Do you have a test case that does not expose anything confidential?

On Sat, Oct 29, 2016 at 5:18 AM, Ricki Hirner <r_at_hirner.at> wrote:

> 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
>

-------------------------------------------------------------------
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