Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

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

kazuho opened this issue Feb 16, 2016 · 5 comments
Assignees
Labels

Comments

@kazuho
Copy link

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
Copy link
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
Copy link
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
Copy link
Author

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 added a commit to h2o/h2o that referenced this issue Feb 17, 2016
@FabianFrank
Copy link
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 closed this as completed in eb083e0 Feb 17, 2016
@bagder
Copy link
Member

bagder commented Feb 17, 2016

Thanks, both of you!

mingodad pushed a commit to mingodad/h2o that referenced this issue Feb 17, 2016
@lock lock bot locked as resolved and limited conversation to collaborators May 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

3 participants