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

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 
correct!)


>> On 30.06.2010 03:29, Cyrus Daboo wrote: 
>>> 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?
Yes ...

> 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)
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 [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?



Regards,
Elias
________________
[1] 
<http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/caldav-ctag.txt>

Received on Wednesday, 30 June 2010 23:38:33 UTC