Re: [Bug 12] Destination header "consistent"

Lisa Dusseault wrote:
> Trying to fill in a little background here: we've discussed this related 
> issues before, from June 22 to 26, 2003 and Oct 9 2003.  I think part of 

For the former time range, I'm not sure what messages you're referring 
to (URL?). For the latter, this was about DAV:location elements in 
DAV:multistatus (see 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/thread.html#35>).

> what we concluded was that if a resource that is mentioned in a PROPFIND 
> response would normally return a Location header (if you did a HEAD to 
> that resource alone) we needed to find a way to return the same info 
> inside the PROPFIND response. So we discussed use of 302/303 and a 
> <DAV:location> element to provide the information that would have been 
> in the Location header, all inside the 207 response.

That's all true, but what does this have to do with what the spec 
currently says? It talks about some interaction of a "Location" response 
header and a multistatus response body (on the very same message), and I 
really don't get what this has to do with the issue mentioned above.

> But a slightly different case: if *all* of the resources had been 
> redirected (if the target collection itself or a parent had been 
> redirected) then one single Location header for the entire response 

That's a different situation, described in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-13.html#redirect.references.to.collections>. 
As a redirect reference resource is not a collection, a PROPFIND on it 
with no Redirect-specific request headers simply would return in a 302 
status, just like GET or HEAD.

> might work for the whole shebang.  Thus, I don't agree that returning 
> 207 with a Location header is meaningless.  (I have no reason to 
> disagree with the assertion that existing implementations probably don't 
> do that, though).

The nature of a redirect resource is that it redirects to a different 
URL, using 3xx and Location header. Applying PROPFIND to a redirect gets 
you a 3xx and a Location header, not a 207 and multistatus.

The REDIRECT spec defines an extension so that you can PROPFIND the 
properties of the redirect, instead of being redirected. That still 
doesn't make a redirect a WebDAV collection.

On the other hand, a WebDAV collection that *contains* redirects will 
respond with 207/multistatus to a PROPFIND.

> It might well be premature optimization, however.  The "dumber" way to 
> handle this case -- when the request is to a collection that has been 
> moved/redirected -- is simply to return the appropriate 300 level 
> response and Location and make the client repeat the request against the 
> new URL.  Two roundtrips, but probably not a case worth optimizing for, 
> because we'd have to define either how to combine the Location header 
> with relative URLs inside the response, or how the Location header must 
> be consistent with absolute URLs inside the response.

This sounds a bit like you want to re-invent redirects altogether. 
Applying an HTTP method to a redirect causes a 3xx with a Location 
header. That's it, unless the client uses specific extensions to request 
different behaviour (one approach is defined in the REDIRECT spec).

> Is there consensus that the Location header MUST NOT be used with 207?  
> (and while we're at it, should we generalize to all status responses 
> besides 201 and 301, 302, 303, 305, 307?)

Lisa, it seems that whatever we discuss, you try to turn this into a 
discussion about even more spec text. RFC2518bis doesn't need to say 
anything about it. Whatever RFC2616 already says and a future WebDAV 
REDIRECT spec will say is sufficient.

Best regards, Julian

Received on Saturday, 22 October 2005 18:05:13 UTC