Issue 241 conditional header eval order, was: conditional-request implementation feedback

On 24.08.2010 10:01, Eric J. Bowman wrote:
> I've been implementing conditional-request handling, which I haven't
> 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
> streamlining, suggest:

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

> "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."

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

> 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 like the grouping, but the shouldn't the special case wrt 
If-Modified-Since apply to both?

> 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

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..."

> 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.

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

Received on Thursday, 26 August 2010 14:42:09 UTC