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

On 24 March 2014 10:14, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>
> Imagine you have a remote resource that is regularily appended to, like
> a log file or a mailing list archive mbox file. You synchronise with it
> by making regular Range requests to it to retrieve the content that has
> since been appended, if any. To save bandwidth, you ask the server to
> compress the data on the fly. In HTTP/1.1 this can be done using Trans-
> fer-Encoding: gzip. How would you ask a HTTP/2.0 sever to send you the
> newly appended content in a on-the-fly compressed form?

Yes, this is a feature that we have removed in HTTP/2.  We could
probably do more to make this clear.

To be fair, support for Transfer-Encoding: gzip is only hop-by-hop in
HTTP/1.1.  We're introducing a hop that *cannot* do gzip (or any
as-yet-undefined Transfer-Encoding).

For the application you describe, I would recommend a different
architecture.  Range requests serve a very narrow purpose, and this is
probably extending their usefulness a little too much to be properly
reliable in the fact of ...say changing circumstances.  Why not
consider naming the things that this client retrieves?  Then
Content-Encoding will be sufficient.

Received on Monday, 24 March 2014 17:30:41 UTC