 |
lua-l archive |
|
|
||
|
On 1-Feb-07, at 4:29 PM, PA wrote:
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.
Right, there is a difference between content-encoding and transmission-encoding. According to RFC 2616, you can use compression as either a content-encoding or a transmission-encoding, but it seems like content-encoding is more common, so maybe what I said before was misleading.
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?
It would probably be best to experiment with Apache, as a sort of definitive implementation, but my guess is that ranges apply to the bytes in the content-encoded entity, prior to encoding it for transmission.
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...
The intent of content-encoding was that you would store the original content in encoded form (that's for static resources). So the etag would naturally have been computed at that point, and stored with the variant (or in a database associated with the variant).
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
If-Range: should be used with a specific Etag, and means that the requested range should be returned if the specified Etag is the current version of the resource, and otherwise the Range: header should be ignored, so that the entire current version of the resource is sent. That seems to me to be orthogonal to other conditional requests, since it doesn't affect whether or not the resource is sent; rather, whether or not all of it is returned.
There's nothing stopping you from asking for a Range: of a resource you know nothing about. In particular, PDF and other file formats keep the document index at the end of the the document, so it's quite reasonable for a browser to ask for the last, say, 4k of a file that it knows nothing about except for it's imputed filetype (say, by analyzing the extension). Of course, that would be singularly useless with precompressed content, but it would work fine if the transmission were being compressed, since that would apply to just the byte-range being sent.