Re: Range Requests vs Content Codings

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 
> intermediaries -- because one of the main benefits of adding new HTTP 
> mechanisms like this is to allow generic software to take advantage of 
> it. For this scheme to work in an intermediary, it looks like it'll 
> have to cache the uncompressed response to use this range unit, and 
> decompress responses as they come back. That doesn't seem terribly 
> attractive, from their standpoint. Also, this won't work with 
> intermediaries until they actually support it.
Some intermediaries already access the uncompressed content like virus 
scanners. For such proxies it may be attractive to do this. It would 
even be more attractive when the intermediary would be enabled to do 
content-encoding gzip (or other) for non compressed content.

> The alternative is to do what people do now -- to use an 
> application-specific mechanism (e.g., a URL query parameter) to fetch 
> parts of the response. That seems like it would satisfy the use case 
> that was talked about earlier (from Bjoern):
>> 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.
>
> The natural questions seem to be:
>
> - What benefits does standardising a range-unit bring this use case (over just using application-specific semantics)?
An application specific semantic doesn't allow the caching of the 
original file in intermediaries.
It does provide a way to do a seek using range request and use 
compression at the same time.
The application can get simpler, e.g. the web server can do the work.
Applications can use this feature without the need to control the server 
side and write code for the server.
> - Are there other use cases that are materially different?
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.

> Cheers,
>
> P.S. Happy to give agenda time in Toronto to this if you think it's ready to discuss...
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>

Received on Wednesday, 18 June 2014 10:10:56 UTC