Re: Range Requests vs Content Codings

So the range request is really  for representation A and return some 
representation C, e.g. gzip content which is most likely different from 
representation B. My question is now what Etags (if there are etags) are 
send in the requests (when conditional) and responses. When the client 
sends the range request then will it send the etag for B?

A cache then can build A with the ETAG of B using several bbcc range 
requests from a client. If it gets normal byte range requests for B then 
it can't use it (cache has only A and C) and need to forward the request 
to the origin server. If the cache has B and gets a bbcc range request 
then it can respond from the cache by decompressing to A, select the 
requested range and return the compressed content. If the cache has B 
and gets a normal byte range request for A then it could do the same but 
will not match as it doesn't know about the Etag for A. Seems like more 
effort for caches, but maybe still an acceptable price.

When the client should the send the range request with the etag for A 
then how does the client get the etag for A?

Regards,
Roland


On 17.06.2014 12:26, Julian Reschke 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 11:43:16 UTC