Subject: Proposal for response URLs in Multi-Status: always based on Request-URI

From: Lisa Dusseault <[email-masked]>
Date: Sun, 4 Dec 2005 09:01:06 -0800

We've discussed the allowability of relative URLs in the 'href' element 
in the 'response' elements of Multi-Status responses.  I'll call each 
of these a "response URL" for now.  I believe our conclusion was that 
in response to PROPFIND, response URLs which are relative URLs MUST be 
relative to the Request-URI, and those which are absolute MUST begin 
with the Request-URI (exactly the same scheme, host, port and path).

For MOVE and COPY, one could consider relative URLs as being resolved 
against the Destination header instead of the Request-URI, but I don't 
believe that anybody does this.  One could also imagine seeing absolute 
URLs that were part of the Destination namespace rather than the 
Request-URI namespace, but again, I don't believe that anybody does 
this.

Thus, are there any objections if we treat all Multi-Status responses 
the same way -- for MOVE and COPY as well as PROPFIND and PROPATCH?  
That the response URLs MUST always be in the Request-URI namespace, and 
if relative, be resolved against the Request-URI?

Would making this requirement a MUST for all Multi-Status responses 
break any extensions using Multi-Status -- or do we limit the 
requirement to Multi-Status responses to methods defined in RFC2518bis 
only?

Lisa

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 4 Dec 2005 16:17:23 -0500

+1 for MUST on the relative URI in a multistatus being interpreted
relative to the Request-URI.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Dec 2005 01:26:05 +0100

> We've discussed the allowability of relative URLs in the 'href' element 

I think we should stick with proper terminology: there is no such thing 
as a relative URL, RFC3986 calls these things "relative references".

> in the 'response' elements of Multi-Status responses.  I'll call each of 
> these a "response URL" for now.  I believe our conclusion was that in 
> response to PROPFIND, response URLs which are relative URLs MUST be 

Yes.

> Request-URI namespace, but again, I don't believe that anybody does this.
> 

No. Of course a multistatus upon COPY/MOVE can contain URLs below the 
destination URI, not the Request-URI. And other methods such as REPORT 
and SEARCH may return URLs completely independently of the Request-URI.

But yes, if an <href> is a relative reference, it is always relative to 
the Request-URI. That was certainly the consensus each time this was 
discussed.

> requirement to Multi-Status responses to methods defined in RFC2518bis 

See above, and please review 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#url.handling> 
(you do remember that we agreed on the conference call that I should 
make a proposal for spec text, right?).

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 4 Dec 2005 20:40:18 -0500

Note that my +1 was for interpreting relative references in the
DAV:response elements as being relative to the Request URI, but
as Julian states below, there should be no restriction on a URI
that appears in the DAV:response element (i.e. they can reference
any resource, not just resources under the Request URI).

I vote that we adopt Julian's text.

Cheers,
Geoff

> > in the 'response' elements of Multi-Status responses.  I'll call each 
of 

this.