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: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Wed, 26 Mar 2014 11:06:25 +0000
To: K.Morgan@iaea.org
cc: ietf-http-wg@w3.org, roland@zinks.de, derhoermi@gmx.net
Message-ID: <2880.1395831985@critter.freebsd.dk>
In message <0356EBBE092D394F9291DA01E8D28EC20100F3EFF0@sem002pd.sg.iaea.org>, K.Morgan@iaea.org wr
ites:

>Earlier in this conversation, Björn gave the following example...
>
>> 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 retriev
>e 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
>> Transfer-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?

You must have overlooked the "real-world" I put in my question ?  :-)

If your goal is to make HTTP the protocol that can do *everything*, then you
are going to get a protocol which is good for nothing.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Wednesday, 26 March 2014 11:06:47 UTC

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