W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

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

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Mon, 24 Mar 2014 18:14:00 +0100
To: Martin Thomson <martin.thomson@gmail.com>
Cc: K.Morgan@iaea.org, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <glp0j9h4jroho6uslfnb0r4tnd2354d714@hive.bjoern.hoehrmann.de>
* Martin Thomson wrote:
>That's because Transfer-Encoding is a hop-by-hop thing and the
>non-standard "gzip" Transfer-Encoding would need to be understood by
>all hops in the chain if it were to be used for ranges.  I'm not aware
>of any use of Transfer-Encoding other than "chunked", because it's
>virtually impossible to define a new one that interoperates.
>As I said, I think that this is a confusion between two different but
>oft-confused headers:
>Content-Encoding: gzip
>Transfer-Encoding: chunked

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?
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Monday, 24 March 2014 17:14:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC