Re: Range Requests vs Content Codings

I just want to weigh in that I think it's useful to be able to do range requests for bytes in both representation A and representation B. So I may want to ask for bytes X-Y of a compressed file where X and Y are offsets into the compressed representation or offsets into the original representation.

Thanks,

Peter


On Jun 17, 2014, at 1:08 PM, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2014-06-17 13:42, Roland Zink wrote:
>> 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?
> 
> It's asking for a range of B, to be generated from A. So I think it ought to use ETags applying to B. But of course that's something to properly write down.
> 
>> 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.
> 
> Optimal behavior of intermediaries is an interesting topic, but I don't see intermediaries implementing this anyway. The idea was to enable clients to do something they can't do now.
> 
>> When the client should the send the range request with the etag for A
>> then how does the client get the etag for A?
>> ...
> 
> HEAD?
> 
> Best regards, Julian
>

Received on Tuesday, 17 June 2014 17:20:13 UTC