conditional-request implementation feedback

I've been implementing conditional-request handling, which I haven't
done in years, by following HTTPbis the past few days.  I have some
fresh-set-of-eyes feedback to offer.  I think 6.3.1 could use some
streamlining, suggest:

"If the request would normally result in anything other than a 200 (OK)
status code, or if the passed If-Modified-Since date is later than the
server's current time or otherwise invalid, the response is exactly the
same as for a normal GET."

There's also some awkward wording in 6.4, suggest:

"If any of the entity-tags match the entity-tag of the representation
that would have been returned in response to a similar GET request
(without the If-None-Match header) on that resource, or if "*" is given
and any current representation exists for that resource:

 1. If the request method was GET or HEAD, the server SHOULD respond
with a 304 (Not Modified) response including the cache-related header
fields (particularly Etag) of one of the representations that matched. 

 2. For all other request methods, the server MUST respond with a 412
(Precondition Failed) status code, unless processing is required
because the resource's modification date fails to match that supplied
in an If-Modified-Since header field."

I also think the last paragraph should be removed from each of sections
p4 6.2 - 6.5 as confusing and contradictory.  Instead, it should be
noted that these headers should be handled in the order in which they
appear, and that order changed to:

p4 6.5
p4 6.2
p4 6.3
p4 6.4
p5 5.4
p5 5.3

Taken in this order, and ignoring those end paragraphs, led me to a
simple algorithm for which the assertions don't hold true.  For example,
how can the handling of both If-Match and If-None-Match in the same
request be considered "undefined"?  The spec says:

"If the request would, without the If-Match header field, result in
anything other than a 2xx or 412 status code, then the If-Match header
MUST be ignored."

Evaluating If-None-Match without If-Match results in a 2xx, 304 or 412
response.  Doesn't this mean that, if If-None-Match results in a 304,
If-Match MUST be ignored?  Conversely:

"If the request would, without the If-None-Match header field, result
in anything other than a 2xx or 304 status code, then the If-None-Match
header MUST be ignored."

Evaluating If-Match without If-None-Match results in a 2xx or a 412
response.  Doesn't this mean that, if If-Match results in a 412, If-
None-Match MUST be ignored?

So the response codes 304 and 412 MUST ignore either one or the other
conditional header, while a 2xx response remains true to both.  While I
can't think of any reason to send both If-Match and If-None-Match, I'm
not seeing any paradox which justifies the disclaimer paragraphs -- in
which case they're just confusing.

-Eric

Received on Tuesday, 24 August 2010 08:02:00 UTC