Re: Range Requests vs Content Codings

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:09:08 UTC