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

On 01.07.2010 01:37, Elias Sinderson wrote:
> ...
> With some further analysis, my earlier statement obviously does not
> hold. Here are my current thoughts --
>
> For If-Modified-Since, depth requests can only really be evaluated
> correctly by iterating over the entire set of resources in scope. Given
> the unfortunate diversity in how timestamps are managed by different
> systems, the only reliable way to support this would be to specify that
> the server must consider the entire set of resources in scope and treat
> If-Modified-Since as if it applies to everything. That is, we can't
> indicate any optimizations in the spec wrt evaluation of a collections
> children / descendants. Given that, however, this is a rather
> straightforward feature to support since a single date is used across
> multiple comparisons and there may be some obvious performance
> optimizations to be made for a specific architecture.
> ...

I'm not completely sure I understand.

Are you saying that the overall response code (not the multistatus body) 
for a PROPFIND with Depth:infinity and If-Modified must take the 
last-modified dates for all resources in scope into account?

I don't think this is what the spec says, nor that it should (it would 
be extremely expensive to implement, and to work reliably would require 
internal atomicity that usually can't be guaranteed).

> If-None-Match is more interesting. For this, we need something akin to
> CTags. I thought this had been discussed on the dist-auth list

I'm not convinced we need those. We really should make all of this more 
compatible with GET, and rely on ETags.

> previously but a quick search of the archives came up empty. Cyrus has
> written up a quickie draft proposal on this idea for CalDAV [1], so
> maybe it was only discussed on that list? A critical behavior to address
> is whether CTag changes 'bubble up' to parent containers. The existing
> writeup doesn't specify this, but it is necessary if CTags are to
> support the semantics necessary for efficient evaluation of PROPFIND /
> REPORT type methods at depth. While obviously a performance hit for
> servers to maintain, it would provide some (perhaps more?) performance
> benefit downstream when evaluating requests with depth 1 or infinity.
>
> Have you considered this at any length before?

I'm currently not in the business of writing servers. That being said, 
change tags "bubbling up" will be very expensive to implement in many 
servers.

It would probably be a good idea to look at the problem that needs to be 
solved first. Maybe defining a related resource that aggregates all this 
hierarchy state (and which as a proper ETag) is all that's needed.

Best regards, Julian

Received on Thursday, 1 July 2010 07:44:34 UTC