Re: 304 or 412 for If-Modified-Since?
Elias Sinderson <elias <at> cse.ucsc.edu>
2010-06-30 23:37:56 GMT
On 30.06.2010, Julian Reschke wrote:
> 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.
I think this would be well received by the broader community.
> On 30.06.2010 09:01, Elias Sinderson wrote:
>> 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?
Correct, a clarification would help here. (Assuming my interpretation is
>> On 30.06.2010 03:29, Cyrus Daboo wrote:
>>> Second, does If-Modified-Since make sense for PROPFIND or REPORT
>> 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
Agreed. The depth 0 case is pretty well understood (or, at least, can be
inferred from the related text in 2616 and 4918).
> - 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?
More or less -- there are obviously application / domain specific
scenarios, but they all seem to collapse to this basic idea. As you
said, it is interesting ... more details on this below.
> 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).
Yes, well, that would explain why I couldn't find anything relevant when
I referenced the specs! :)
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.
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
previously but a quick search of the archives came up empty. Cyrus has
written up a quickie draft proposal on this idea for CalDAV , 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?