c-e:gzip silently decoded when HTTP/2 is used #661

Closed
kazuho opened this Issue Feb 16, 2016 · 5 comments

Projects

None yet

3 participants

@kazuho
kazuho commented Feb 16, 2016

If HTTP/1 is used, curl -H Accept-Encoding:gzip returns gzipped content, when connecting to a server that sends the response with Content-Encoding: gzip specified.
However when HTTP/2 is used, the response is decompressed by curl itself.

Steps to reproduce:

  1. build and run h2o with this configuration file; a text file should be stored in the document root
  2. run curl -H Accept-Encoding:zip http://127.0.0.1:8080/name-of-the-text-file | gzip -cd. The original text shows up
  3. run curl --http2 -H Accept-Encoding:gzip http://127.0.0.1:8080/name-of-the-text-file | gzip -cd. gzip complains: gzip: unknown compression format, since curl itself decodes the content-encoding in this case.
@bagder bagder added the HTTP/2 label Feb 16, 2016
@bagder
Member
bagder commented Feb 16, 2016

Right. Made on purpose: https://github.com/curl/curl/blob/master/lib/http.c#L3596

... introduced in commit 133cdd2 by @FabianFrank:

A server might respond with a content-encoding header and a response
that was encoded accordingly in HTTP-draft-09/2.0 mode, even if the
client did not send an accept-encoding header earlier. The server might
not send a content-encoding header if the identity encoding was used to
encode the response.

See:
http://tools.ietf.org/html/draft-ietf-httpbis-http2-09#section-9.3
@bagder
Member
bagder commented Feb 16, 2016

As far as I can tell, that's just a trace for our support of earlier h2 versions and we should remove that again. Anyone disagreeing with that?

@bagder bagder self-assigned this Feb 16, 2016
@kazuho
kazuho commented Feb 17, 2016

@bagder Thank you for looking into the issue.

As far as I can tell, that's just a trace for our support of earlier h2 versions and we should remove that again.

+1

Considering the fact that curl automatically uses HTTP/2 for https (after a successful negotation using ALPN), I think that would be the only way to preserve compatibility with older versions of curl with support for HTTP/1 only.

@kazuho kazuho added a commit to h2o/h2o that referenced this issue Feb 17, 2016
@kazuho kazuho skip tests affected by curl/curl#661 13d0571
@FabianFrank
Contributor

I agree with @bagder, the gzip requirement part of the draft that resulted in this code didn't make it into the final RFC and the code should thus no longer be needed.

@bagder bagder added a commit that closed this issue Feb 17, 2016
@bagder bagder http2: don't decompress gzip decoding automatically
At one point during the development of HTTP/2, the commit 133cdd2
introduced automatic decompression of Content-Encoding as that was what
the spec said then. Now however, HTTP/2 should work the same way as
HTTP/1 in this regard.

Reported-by: Kazuho Oku

Closes #661
eb083e0
@bagder bagder closed this in eb083e0 Feb 17, 2016
@bagder
Member
bagder commented Feb 17, 2016

Thanks, both of you!

@mingodad mingodad added a commit to mingodad/h2o that referenced this issue Feb 17, 2016
@kazuho @mingodad kazuho + mingodad skip tests affected by curl/curl#661 ed33dd8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment