- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 28 Feb 2008 12:56:58 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
Issue referenced at the bottom is <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/107 >. On 13/02/2008, at 5:25 PM, Mark Nottingham wrote: >> 14.25 (If-Modified-Since) >>> The If-Modified-Since request-header field is used with a method >>> to make it conditional: if the requested variant has not been >>> modified since the time specified in this field, an entity will >>> not be returned from the server [...] >>> A GET method with an If-Modified-Since header and no Range header >>> requests that the identified entity be transferred only if it has >>> been modified since the date given by the If-Modified-Since >>> header. The algorithm for determining this includes the following >>> cases: a) If the request would normally result in anything other >>> than a 200 (OK) status, or if the passed If-Modified-Since date is >>> invalid, the response is exactly the same as for a normal GET. A >>> date which is later than the server's current time is invalid. b) >>> If the variant has been modified since the If-Modified-Since date, >>> the response is exactly the same as for a normal GET. c) If the >>> variant has not been modified since a valid If- Modified-Since >>> date, the server SHOULD return a 304 (Not Modified) response. >> >> 14.28 (If-Unmodified-Since) >>> If the requested variant has been modified since the specified >>> time, the server MUST NOT perform the requested operation, and >>> MUST return a 412 (Precondition Failed). >> >> 14.29 (Last-Modified) >>> The Last-Modified entity-header field indicates the date and time >>> at which the origin server believes the variant was last modified. >> Interestingly, Last-Modified validation is defined in terms of >> 'requested variant', whereas ETag validation (If-Match, If-None- >> Match) seem to go out of their way to say that *any* entity that >> meets the conditional can be returned, and never mind the selecting >> headers. I'd be interested in hearing if any implementations >> actually do that, and unless some are found, I'd suggest we need to >> tighten up how ETag validation is defined.. > > PROPOSAL: s/requested variant/selected representation/g; s/variant/ > selected representation/g > > And, add an issue about the implied divergence in the ETag and LM > validation models. -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 28 February 2008 01:57:13 UTC