Re: Range Requests vs Content Codings

On Wed, Jun 18, 2014 at 5:10 AM, Roland Zink <roland@zinks.de> wrote:
> On 18.06.2014 02:32, Mark Nottingham wrote:
>>
>> To me, whenever we have someone propose a new range-unit, one of the
>> deciding factors is whether it'll be useful and implemented by
>
> 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.

I think this is the use case we've been talking about. Any other examples?

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.

If there is log rotation, then we are talking about different URIs at
different times, which is an app-specific protocol.

Another difficulty is at the assumption that the file is only appended
to, and previously written bytes are never altered. There is no
mechanism in HTTP to express that property. ETag obviously must evolve
when the file grows, so it cannot be relied upon. How could the client
be certain about the assumption then? There must be some size-channel
secrete shared by the server and the client.

The use case, which assumes byte-level append-only growth, is a tiny
fraction of the slightly more common case where growth is append-only,
but at various semantic units (e.g. blog article). We live by
app-specific protocols to handle these cases. What is so special about
byte unit that it must be addressed by http (in a very ugly way)?

The motivation, I think, is from subconscious association - byte range
is widely used, therefore bbcc is probably also justified.

However, byte range solves a real, important use case - that in our
current world, downloading a resource may take very long time, during
which time various events can and do interrupt the download. Resumed
download via byte range probably helps millions of users every day.

But we cannot say that about bbcc, by any measure, therefore the merit
of byte range cannot be automatically extended to bbcc. The proponents
of bbcc need to uncover a lot more benefit of the feature to justify
its cost.

Zhong Yu
http://bayou.io

Received on Wednesday, 18 June 2014 16:35:46 UTC