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

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

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.

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.

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

Hi Elias,

--On July 1, 2010 6:53:08 PM +1000 Elias Sinderson <elias <at> cse.ucsc.edu> 
wrote:

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

So the WebDAV collection Sync REPORT is meant to take over the role of a 
ctag and provide a true "what changed" synchronization capability. Please 
review past messages on this mailing list.

The one open issue on that REPORT (that I need to follow up on) is whether 
a true Depth:infinity capability should be added to the current Depth:1 
behavior.

--

-- 
Cyrus Daboo

Could not access /webdav/

status code 425

Hi,

I just found in <http://www.iana.org/assignments/http-status-codes>:

> 425       Reserved for WebDAV advanced             [RFC2817]
>           collections expired proposal

RFC 2817 says 
(<http://greenbytes.de/tech/webdav/rfc2817.html#rfc.section.7.1>):

 > 3. WebDAV Advanced Collections [5] (Work in Progress) [defines 425]

where [5] is:

>    [5]  Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections
>         Protocol",  Work In Progress.

...which of course isn't *that* helpful (RFC Editor, you listening? 

Anyway, this seems to come from 
<http://tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04#section-7.2> 
which says:

> 7.2 425 Unordered Collection
>
>
> The 425 (Unordered Collection) status code indicates that the client
> attempted to set the position of an internal collection member in an
> unordered collection or in a collection with a server-maintained
> ordering.

That draft was never finished, but RFC 3648 ("Web Distributed Authoring 
and Versioning (WebDAV) Ordered Collections Protocol") was. That uses 
the precondition name "DAV:collection-must-be-ordered" instead 
(<http://greenbytes.de/tech/webdav/rfc3648.html#rfc.section.6.1>).

I don't believe anybody has implemented status code 425.

Maybe we should un-reserve it in the IANA registry?

Best regards, Julian

Re: status code 425

Hi Julian,

--On July 20, 2010 7:11:21 PM +0200 Julian Reschke <julian.reschke <at> gmx.de> 
wrote:

> That draft was never finished, but RFC 3648 ("Web Distributed Authoring
> and Versioning (WebDAV) Ordered Collections Protocol") was. That uses the
> precondition name "DAV:collection-must-be-ordered" instead
> (<http://greenbytes.de/tech/webdav/rfc3648.html#rfc.section.6.1>).
>
> I don't believe anybody has implemented status code 425.
>
> Maybe we should un-reserve it in the IANA registry?

+1.

Speaking of RFC 3648, have implementations of that been done? How would a 
server signal to a client that just the order of child resources in the 
collection has changed, but not the actual resource bodies? It would be 
really handy if the server could send a "diff" of the ordering changes to 
not require the client to do a depth:1 PROPFIND (which the sync REPORT 
seeks to reduce use of).

--

-- 
Cyrus Daboo

Re: status code 425

On 20.07.2010 20:12, Cyrus Daboo wrote:
> ...
> Speaking of RFC 3648, have implementations of that been done? How would

Yes.

> a server signal to a client that just the order of child resources in
> the collection has changed, but not the actual resource bodies? It would
> be really handy if the server could send a "diff" of the ordering
> changes to not require the client to do a depth:1 PROPFIND (which the
> sync REPORT seeks to reduce use of).

The issue never came up 

Do you believe that a PROPFIND with Depth:1 (and not using allprop) is 
expensive? It might be for large collections, but those are expensive in 
WebDAV anyway...

BR, Julian