Subject: conditional-request implementation feedback

From: "Eric J. Bowman" <[email-masked]>
Date: Tue, 24 Aug 2010 02:01:36 -0600

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Aug 2010 16:41:27 +0200

> done in years, by following HTTPbis the past few days.  I have some

Great!

> fresh-set-of-eyes feedback to offer.  I think 6.3.1 could use some

(I assume you mean item 1 in the ordered list in Section 6.3...)

> same as for a normal GET."

"valid date" is used again in item 3, so maybe we should define upfront 
once.

> in an If-Modified-Since header field."

I like the grouping, but the shouldn't the special case wrt 
If-Modified-Since apply to both?

> appear, and that order changed to:

The order is alphabetical, and I don't believe we want to change that.

That being said, we need to clarify evaluation order, Section 1 already 
states:

"...In particular, the sections on resource metadata will be discussed 
first and then followed by each conditional request-header, concluding 
with a definition of precedence and the expectation of ordering strong 
validator checks before weak validator checks..."

> which case they're just confusing.

Thanks for the input, this needs indeed work, I'm opening a ticket for 
this -- <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/241>.

It would be cool to have test data on this (what do httpd and IIS do 
here???).

Best regards, Julian