Re: Range Requests vs Content Codings

This will subvert the current ordering of Range and Content-Encoding,
adding an exception for a particular range unit. I think that is a
high cost.

And the use case seems quite limited. We've heard that someone want
this feature for log tailing. But I don't understand how it could be
easier to change the HTTP spec and deployments, than to change the
server application (by adding the range to the request URI).

Zhong Yu



On Tue, Jun 17, 2014 at 5:26 AM, 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).
>
> Upon GET, clients can select which one to use using "Accept-Encoding". For
> instance
>
>   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.
>
> 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.
>
> (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?
>
> Best regards, Julian
>
>
>
>
>

Received on Tuesday, 17 June 2014 22:33:49 UTC