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

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

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder Feb 16, 2016

Member

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

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder Feb 16, 2016

Member

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?

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

This comment has been minimized.

Show comment
Hide comment
@kazuho

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

This comment has been minimized.

Show comment
Hide comment
@FabianFrank

FabianFrank Feb 17, 2016

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.

Contributor

FabianFrank commented Feb 17, 2016

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 in eb083e0 Feb 17, 2016

@bagder

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder Feb 17, 2016

Member

Thanks, both of you!

Member

bagder commented Feb 17, 2016

Thanks, both of you!

mingodad added 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.