Re: current HTTP/2 spec prevents gzip of response to "Range" request

On 26 March 2014 05:16, <K.Morgan@iaea.org> wrote:

>  Clients MUST support gzip compression for HTTP response bodies.
> Regardless of the value of the TE request header field, a server MAY send
> responses with gzip transfer encoding. A compressed response MUST still
> bear an appropriate transfer-encoding header field. This effectively
> changes the implicit value of the TE header field ([HTTP-p2], Section
> 14.39) from "chunked" to "gzip, chunked". Servers SHOULD not use gzip
> transfer encoding if the requested content is already compressed (e.g.
> images, videos, compressed files, etc.).
>
Do you mean HTTP-p1, Section 4.3 ?


> Servers MUST not include the values "gzip" or "deflate" in a
> Content-Encoding header, regardless of whether the requested content is
> already compressed, but SHOULD include the appropriate mime type in the
> Content-Type header. Correspondingly, clients SHOULD not include the values
> "gzip" or "deflate" in a Accept-Encoding header.
>
Why? Is this an attempt to work around double-compression? It seems pretty
heavy-handed. How about this example?

* I have an Apache web server which serves two files: index.html and
index.html_gz, the latter beings a gzip-compressed version of the first.
* I have configured the Content-Type of the index.html_gz as "text/html",
and the Content-Encoding as "gzip" [a].
* I have configured my Apache server to detect Accept-Encoding:gzip on
requests for the index.html file, and internally redirect those requests to
index.html_gz
* Apache then handles setting response headers such as Last-Modified, ETag,
etc. based on the file stat, as it would any other file request.

[a]: these response headers are included if a client requests
index.html_gz even without Accept-Encoding:gzip ; my workaround here is to
not expose the _gz file, e.g. by not linking to it.

Because of the MUST NOT, I now cannot take advantage of my proactive
compression in HTTP/2, and instead either 1) require the server to compress
the response on-the-fly each time, or 2) lose the compression. Also,
because TE is hop-by-hop I risk some intermediary terminating the
compression, possibly negatively impacting my site's responsiveness in a
way that is outside my control; but CE is end-to-end, so intermediaries
shouldn't be touching the compressed data (I say "shouldn't" but I know
some still will).

Yes, I said I'd like to do away with CE, but it's widely used and very
popular, we would need to come up with a legitimate replacement. I believe
that mandating support for TE might provide a gradual path for replacement,
especially if/when HTTP/1 fades away from the web (i.e. if every hop
guarantees support for TE, I have one less need for CE).

This paragraph should be a best practice guideline, if anything, not an
interoperability requirement.


> Clients, servers and intermediaries MAY elect to support other compression
> methods for transfer encoding, in which case it MUST be explicitly
> requested by the client in the TE header.
>
Should probably mention the IANA HTTP Transfer Coding Registry here.


-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/