W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Range Requests vs Content Codings

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 18 Jun 2014 07:29:17 +0200
Message-ID: <53A123AD.8090503@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2014-06-18 02:32, Mark Nottingham wrote:
>
> On 17 Jun 2014, at 8:26 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
>
>> Trying to summarize the problem, and trying a solution:
>>
>> Consider a text/plain resource http://example.org/test of 1000000 octets length (representation A), supporting content coding "gzip", yielding 100000 octets (representation B).
>
> Nit: I think you mean a resource with two text/plain representations; one without content-coding that's 1,000,000 octets (A), and one with 'gzip' content-coding that's 100,000 octets (B).

Yes.

>> Upon GET, clients can select which one to use using "Accept-Encoding". For instance
>
> Nit: the server always performs selection.

Yes.

>>   GET /test HTTP/1.1
>>   Host: example.org
>>   Accept-Encoding: gzip
>>
>> is likely to return the representation B, while
>>
>>   GET /test HTTP/1.1
>>   Host: example.org
>>   Accept-Encoding: identity
>>
>> will return representation A.
>
> Yes.
>
>
>> A specified range will always apply to the representation. Thus, a client can't easily ask for a specific range of representation A *and* have the server apply Content-Coding gzip.
>
> Well, that's because A isn't gzipped, but OK...
>
>
>> (Compression could also be achieved by using Transfer Codings, but these are not implemented in practice)
>>
>> One way to combine Content Codings and range requests would be to create a new range unit, "bbcc" (bytes-before-content-coding). In which case the the requested range would be applied to the non-content-coded representation, and the content-coding would be applied to the byte range.
>>
>> Such as:
>>
>>   GET /test HTTP/1.1
>>   Host: example.org
>>   Accept-Encoding: gzip
>>   Range: bbcc=900000-
>>
>> This would retrieve the octets starting at position 900000, and apply content-coding gzip to the resulting octet sequence.
>>
>> Note that to combine range responses using these byte range units, a recipient needs to understand the range unit (simple concatenation isn't going to work).
>>
>> This also requires that both user agent and origin server understand the new range unit, but that appears to be easier to deploy than T-E (which requires all intermediaries to play along).
>>
>> Thoughts?
>
> 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.

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?


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

> - Are there other use cases that are materially different?
>
> Cheers,
>
> P.S. Happy to give agenda time in Toronto to this if you think it's ready to discuss...

Maybe. I was just writing down the idea in order to find out whether 
this is actually one possible way to address this.

Best regards, Julian
Received on Wednesday, 18 June 2014 05:29:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC