Re: Range Requests vs Content Codings

On 18 Jun 2014, at 3:29 pm, Julian Reschke <julian.reschke@gmx.de> wrote:

>> Also, this won't work with intermediaries until they actually support it.
> 
> Um, no. Intermediaries can ignore it. It just makes all responses using the new range unit uncacheable.
> 
> Intermediaries that fail for unknown range units are broken, no?

Yes, of course they wouldn't break, but they also wouldn't be able to cache partial responses using the new range-unit, nor would they be able to 
service requests that use it. So there's a loss of functionality which may outweigh the usefulness of the new function.


>> 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)?
> 
> That it would work with standard software such as httpd, static files, and a new module?

Yes. 

I'm remembering that in the past, we've had people suggest standardising other range-units (e.g., "entries" of a blog, etc.) and there's been a fair amount of pushback, some of it for the reasons that I describe (that intermediaries won't understand / implement it).

I think what might make this different is that a) it's "closer" to the wire; it's still a byte-counting mechanism, just at a different "layer", and b) gzip is already part of HTTP.

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 18 June 2014 05:52:41 UTC