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

On 01.07.2010 10:53, Elias Sinderson wrote:
> Julian Reschke wrote:
>> On 01.07.2010 01:37, Elias Sinderson wrote:
>>> [...] For If-Modified-Since, depth requests can only really be evaluated
>>> correctly by iterating over the entire set of resources in scope. [...]
>> 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?
> Sorry, I should have been more specific -- I would expect to see 412's
> in the <D:status> elements of the multistatus response, without any
> corresponding propertied returned. Assuming, of course, that the server
> would evaluate the entire resource set at all... This would additionally
> require some mechanism for the client to indicate that it wanted the
> header applied beyond the target resource. (Along the lines of the DAV
> header, as you previously indicated, or otherwise.)

The Depth header? I think this is what the definition of the Depth 
header already requires.

> Yes, expensive, but perhaps not much more than the evaluation of the
> PROPFIND itself, without any If- headers.

PROPFIND/Depth infinity is already expensive (and thus many servers do 
not allow it anyway). When they do, they better *stream* the result to 
the client. So, if there was a requirement to test all resources in 
scope against a condition *before* starting to send the multistatus this 
would be bad.

>>> 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.
> That would certainly simplify things, if possible. :)
>
>
>>> [...] 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.
> Yes, agreed, especially where there is a 1:1 correspondence between
> [E/C]Tag updates and file I/O operations. I'm generally more willing to
> take this hit on the authoring side if it translates into comparable
> savings on the read side, and doubly so in domains that have better than
> an order of magnitude more reads than writes. IMO, this covers a the
> lions share of web apps.
>
>
>> 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.
> Possibly -- do you think such a resource could be generated more cheaply
> than maintaining hierarchies of [E/C]Tags? I think this depends largely
> on the implementation details of a given server architecture.

I'd think of it as a different way to put things on the wire, not really 
changing what the server needs to do in the end.

It would be great if we can avoid adding even more stuff to WebDAV, and 
re-use more of plain HTTP instead.

See, for instance: 
<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html>

Best regards, Julian

Received on Thursday, 1 July 2010 09:07:54 UTC