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

On Wednesday,26 March 2014 11:23, Poul-Henning Kamp wrote:
> In message <5332A640.60404@zinks.de>, Roland Zink writes:
>>Range works fine with C-E as long as the client retrieves the whole
>>beginning of the file. If the client wants to skip some parts of it
>>then it is unable to decompress. Retrieving 0-999 then 1000-1999 and so
>>on is fine. But retrieving 0-999 and then 2000-2999 is a problem.
>
>Can you give an example of a real-world application where this is anything but a minor inconvenience ?

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

In fact in this example, where you are requesting "Content-Encoding: gzip" and a range from the end of the file, an HTTP/1.1 compliant server would have to return "416 Requested Range Not Satisfiable" because first it would compress the whole file and then look for the range which would likely begin beyond the length of the compressed file (if it is at all compressible).

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Wednesday, 26 March 2014 10:54:17 UTC