W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

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

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sun, 4 Dec 2005 16:17:23 -0500
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OFEE20606F.C3D0C0D9-ON852570CD.0074CE6C-852570CD.0074F312@us.ibm.com>
+1 for MUST on the relative URI in a multistatus being interpreted
relative to the Request-URI.


Lisa wrote on 12/04/2005 12:01:06 PM:

> 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
Received on Sunday, 4 December 2005 21:17:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC