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

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