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

Hi Elias,

nice to see you back on the mailing list! :-)

On 30.06.2010 09:01, Elias Sinderson wrote:
> ...
> 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.
> ...

Indeed. In HTTPbis we still plan to add guidelines on defining new 
headers, and we probably add a paragraph about what to do when defining 
new conditional headers.

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

Agreed. But then it *does* redefine them :-)

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

That might have been the intent, but it doesn't say that, right?

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

We're now talking about multistatus/depth processing, right?

So we need to distinguish two cases:

- applying the condition to the requested resource (which may cause the 
whole request to fail with 412, and which needs to be in sync with HTTP/1.1)

- once the server *does* decide to execute the request, how the 
condition is applied during Depth:1/infinity processing.

The second case indeed is interesting, I assume you're looking at it 
because of collection syncing?

It's *tempting* to claim that RFC 4918 already defines this, but I think 
it would overly optimistic. Better define it properly, and potentially 
add a way for the server to signal that it does this (DAV header comes 
to mind).

> ...

Best regards, Julian

Received on Wednesday, 30 June 2010 07:23:01 UTC