- 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>
* 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