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

[kazuho]

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]

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]

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]

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]

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?

[kazuho]

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

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

[FabianFrank]

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.

[FabianFrank]

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]

Thanks, both of you!

[bagder]

Thanks, both of you!