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

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

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


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



Regards,
Elias

Received on Thursday, 1 July 2010 08:53:45 UTC