RE: Range Requests vs Content Codings

On 18 June 2014 18:35, zhong.j.yu@gmail.com wrote:
> On Wed, Jun 18, 2014 at 5:10 AM, Roland Zink <roland@zinks.de> wrote:
>> A slightly different use case is to access the end of the log file without
>> reading the whole log file. When the log file is content-encoded gzip then a
>> client would need to read the whole log file (possible in chunks) just to be
>> able to decompress the last chunk. With the bbcc scheme and the addition
>> that only the range response is content-encoded this is not necessary.
>
> There is some logistic issues with this use case that makes it
> unrealistic. There is just one log file (accessible from one URI) that
> grows forever. Assuming the growth is very fast (otherwise we won't
> need gzip+range), the file will quickly reach an impractical size.
> ...
> Another difficulty is at the assumption that the file is only appended
> to, and previously written bytes are never altered. ...
> ...
> ... The proponents
> of bbcc need to uncover a lot more benefit of the feature to justify
> its cost.

I basically agree with everything you said, despite the fact that we actually do have this use case (but nobody cares unless you are Google or their little brother [1] :)

We have rapidly growing append-only files.  Currently we use gzip Transfer-Encoding to compress an identity range request.  But since T-E went away (again) in h2, it's no longer possible.

I realize it's a controversial issue, but if I understand correctly, h2 is supposed to replace *everything* you could do in 1.1.

As far as I can tell, there are four solutions for maintaining this capability...

1. Julian's bbcc
2. Matthew's DATA frame compression - possibly as an extension now that it was removed from the main spec.
3. My & Christoph's Message-Encoding HTTP extension (an end-to-end version of T-E that is applied after C-E, but before T-E)
4. Keep T-E in h2 (I dare say nobody wants this solution)


[1] http://www.nationmultimedia.com/breakingnews/Google-to-pay-Firefox-almost-1-billion-dollars-in--30172517.html
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 Saturday, 21 June 2014 16:35:33 UTC