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

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html