curl-library
Re: http2 gzip encoded response expected if not requested?
Date: Thu, 28 Apr 2016 14:51:12 -0400
On 4/28/2016 2:54 AM, Daniel Stenberg wrote:
> On Wed, 27 Apr 2016, Ray Satiro via curl-library wrote:
>
>> I've noticed twitter is sending http2 gzip responses even though I'm
>> not using --compressed. I haven't encountered any other business that
>> does that. Is that allowed by the RFC? I searched it for gzip but
>> it's not mentioned once, and the compression sections seem to apply
>> mostly to headers. Web search only shows [1].
>
> I believe it is fine by the spec[1]. Content-Encoding is the server
> specifying how the content is encoded and it can be gzipped. It
> doesn't necessarily have be negotiated with Accept-Encoding I believe.
> The modern way of using content-encoding gzip is after all a glued on
> "abuse" that we've grown attached to, as it was originally intended
> that Transfer-Encoding should be the method to compress data for
> transfer. And basically nothing execept curl supports gzipped
> Transfer-Encoding...
>
> I also think that there are more sites than just twitter thay does
> this. I've seen it used by for example gzipped tarballs hosted on places.
>
> But I'll agree that it is interesting that twitter decides to only do
> this gzip trick over h2 and not h1. I suspect they do that for other
> reasons. For example all the h2 clients are going to be fairly modern
> so maybe they just then draw the conclusion that such clients are
> likely to handle gzip content automatically too?
>
> [1] = https://tools.ietf.org/html/rfc7231#section-3.1.2.2
>
Unfortunately for me this looks to be correct. As Tatsuhiro hinted at,
this is probably related to [1] which did not end up as part of HTTP/2
RFC 7540. Also, Twitter ignores Accept-Encoding if it's empty or I
request identity, and even if I specifically exclude using gzip;q=0 I
still get gzip, but that is not explicitly forbidden by HTTP/1.1
semantics RFC [1]:
"If an Accept-Encoding header field is present in a request and none of
the available representations for the response have a content-coding
that is listed as acceptable, the origin server SHOULD send a response
without any content-coding."
SHOULD not MUST.
[1]: https://github.com/http2/http2-spec/commit/1471d74
[2]: https://tools.ietf.org/html/rfc7231#section-5.3.4
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-04-28