Re: [OT] HTTP etag vs if-* vs range vs content-encoding?

[PA <petite.abeille@...>]

Hi Rici,

On Feb 01, 2007, at 22:01, Rici Lake wrote:

> My understanding, which may not be right :), is that an Etag 
> identifies an actual entity, not a transmission of an entity. So it's 
> computed on the entire original object, not the transmission encoding 
> of the object (or the bits of the object which are being transmitted 
> on a range request.)

Hmmm... well someone named Henrik Nordstrom has this to say about this 
issue:

"Content-Encoding MUST change ETag."
-- Henrik Nordstrom, "ETags vs Variants", Tue, 24 Oct 2006
http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0114

Not sure who Henrik Nordstrom is though.

> Note that there is a difference between requesting an object which is 
> in compressed format, and compressing the tranmission of a request of 
> an object. In the former case, the etag would apply to the compressed 
> data; in the latter case to the uncompressed data. ("The bits of the 
> entity" is what RFC-2616 says, non-normatively.)

Hmmm... the plot thickens... my current understanding is that the etag 
should be related to the entity variant, so etag( gzip( content ) ) 
instead of gzip( etag( content ) )...

In either case, how would a range request behave? Does it apply to the 
gzip or the plain content? One would think the encoded content... 
but... if the content-encoding is a variant (based on the request 
accept-encoding or the phase of the moon), the size of the content 
could change between request for the same entity and render the range 
invalid or meaningless, no?

On top of that... at what point should a conditional request get 
evaluated (e.g. if-none-match)? If the etag refers to the 
content-encoded version then it should be evaluated after the 
encoding... or vis-versa... sigh...

Also... can one combine a conditional request and a range one? e.g. 
if-none-match + range? If yes, what does that mean?!? Getting more 
confused by the minute :P

> Etags only have to be unique between different variants of the same 
> resource; i.e. if the url's are identical. Using a hash is common but 
> not obligatory; as RFC-2616 says, you could simply attach a version 
> number to a given resource and increment it on each modification.

Cheers,

PA.