W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: conditional-request implementation feedback

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Mon, 06 Sep 2010 00:45:18 +0200
To: "Eric J. Bowman" <eric@bisonsystems.net>
Cc: ietf-http-wg@w3.org
Message-ID: <1283726718.4459.59.camel@henriknordstrom.net>
tis 2010-08-24 klockan 02:01 -0600 skrev Eric J. Bowman:

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

All these "normally result in anything other than a 200 (OK) or 412"
type of statements should be generalized to "normally without any
conditionals result in anything other than a 2xx", not just the specific
conditional being discussed. Alternative all references to 412 in those
statements replaced with 304 instead. Having 412 there do not make
sense, no other conditions can make a 412 a non-412. Equally referencing
200 in specific is nonsense. Success is 2xx, not just 200.

If there is multiple conditionals in an request then all conditionals

There is no specific order of evaluation between specified conditionals,
but there is several MUST return 412 and SHOULD return 304/2xx
conditions where MUST as always have higher priority than SHOULD.

The order of evaluation of conditionals is

0. Conditionals not applicable, ignored. (MUST)
1. MUST respond with XXX (generally 412)
3. SHOULD respond with YYY

If conditionals contradict then 412 is generally the only possible
result, even if one condition in isolation would cause a 304 response.
Or put another way if one condition in isolation says MUST respond with
412 then it's 412 no matter what the other conditions says.


If-Match: "a"
If-None-Match: "a"

GET/HEAD -> 304 if resource has etag "a", 412 otherwise.
other methods -> 412 only possible result

Received on Monday, 6 September 2010 12:34:47 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:23 UTC