Re: 304 or 412 for If-Modified-Since?

Hi Everyone,

I had responded privately to Cyrus earlier, with the intention of 
writing a better response to the list. I see that Julian has responded 
in the meantime and, while we agree on most all points, I am hoping for 
some thoughtful discussion / clarification of the last issue.


Cyrus Daboo wrote:
> RFC 2616 in Section 14.25 "If-Modified-Since" states that a 304 should 
> be returned if the resource is not modified.
Basically, yes, a conditional request with a valid If-Modified-Since 
header is expected to result in a 304 response if the resource has not 
been modified.

There is further clarification in Section 14, where specific request 
headers are defined, for the other If-* headers and their interaction 
with If-Modified-Since. Whether the server returns 304 vs 412 in the 
case of If-None-Match is dependent on the requested method (GET / HEAD 
vs. others). WRT If-Unmodified-Since, the server is required to return a 
412 if the requested variant has been modified, and If-Match behaves 
similarly.

Confusing, yes, and I suspect that there are a few broken 
implementations of this in the wild, both in actual server behavior and 
in what client libraries expect in various situations.

> RFC 4918 in Section 12.1 "412 Precondition Failed" states that a 412 
> should be returned when a conditional header fails to hold.
> So what should clients expect from WebDAV servers?
The text you reference from 4918 does not override the normative text in 
2616. Note the introductory text in Section 12 --

/"These HTTP codes are not redefined, but their use is somewhat extended 
by WebDAV methods and requirements."/

The following subsections apply to the methods defined in the WebDAV 
spec, not the base HTTP methods...

> Second, does If-Modified-Since make sense for PROPFIND or REPORT 
> requests?
My reading of the specs is that yes, this makes sense -- For these 
methods, the If-* headers apply to the resources that are in the scope 
of the request, with the 412 appearing in the <D: status> element 
associated with a given <D:href>.


So, as above, Julian and I are in agreement on all of the points except 
for this last... I've referenced 4918 briefly to look for some 
clarification of this issue but not found anything. I'm hoping that 
someone can provide a reference or some logical explanation to put my 
mind at ease.



Cheers,
Elias