#241: clarify eval order/interaction of conditional headers

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/241>

Roy documented the evaluation order for conditional that Apache uses (which, he pointed out, is the only logical way to do it, once you look at it):

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/241#comment:4>

> Here is the order that Apache httpd uses. When I wrote it, I realized that there is only one logical order for preconditions because ETag is presumed to be more accurate than LM. Likewise, the exact match fields (If-Match and If-Unmodified-Since) have priority over the weaker conditions in the unlikely event that they are ever used together in the same request.
> 
> Check for conditional requests — note that we only want to do this if we are successful so far and we are not processing a subrequest or an ErrorDocument?.
> 
> The order of the checks is important, since ETag checks are supposed to be more accurate than checks relative to the modification time. However, not all documents are guaranteed to have ETags, and some might have Last-Modified values w/o ETags, so this gets a little complicated.
> 
> If an If-Match request-header field was given AND the field value is not "*" (meaning match anything) AND if our strong ETag does not match any entity tag in that field, respond with a status of 412 (Precondition Failed).
> 
> Else if a valid If-Unmodified-Since request-header field was given AND the requested resource has been modified since the time specified in this field, then the server MUST respond with a status of 412 (Precondition Failed).
> 
> If an If-None-Match request-header field was given AND the field value is "*" (meaning match anything) OR our ETag matches any of the entity tags in that field, fail.
> 
> If the request method was GET or HEAD, failure means the server SHOULD respond with a 304 (Not Modified) response. For all other request methods, failure means the server MUST respond with a status of 412 (Precondition Failed).
> 
> GET or HEAD allow weak etag comparison, all other methods require strong comparison. We can only use weak if it's not a range request.
> 
> If a valid If-Modified-Since request-header field was given AND it is a GET or HEAD request AND the requested resource has not been modified since the time specified in this field, then the server MUST respond with a status of 304 (Not Modified). A date later than the server's current request time is invalid.

This is somewhat implementation-specific, but I think the next step is for the editors to turn this into suitable specification text. If you have feedback on the *high-level* approach taken here, now would be good.

Regards,


--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 3 July 2012 07:37:47 UTC