Subject: URL rewriting in PROPFIND responses (related to Bugzilla issue 46)

From: Julian Reschke <[email-masked]>
Date: Sun, 22 Jan 2006 18:29:39 +0100

Hi,

related to <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46>, 
we discussed on the mailing list in which ways a server may rewrite the 
Request-URI in multistatus responses.

For instance, is it legal to rewrite (that is, are clients expected to 
handle):

1) changing the authority, for instance, by replacing a host name by an 
IP address,

2) change URL escaping of individual characters,

3) replace parts of the URL based on server-internal equivalence rules?

As far as I can tell, the answers to this should be:

1) no, otherwise a client would potentially need to lookup DNS, and 
clients just don't do that,

2) yes, because that's usually hard to prevent inside the server if the 
request URL isn't kept as a plain string,

3) clearly no, because clients do not have knowledge about these 
server-specific equivalence rules (such as whether the distinction 
between "a" and "A" is irrelevant).

Note re 1) this point becomes irrelevant if the server is smart enough 
to put relative references into the <href> elements.

I therefore propose the following change to Section 12.2 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-10.html#rfc.section.12.2>):

Section 12., para. 6:
OLD:

     A Multi-Status body contains one or more 'response' elements.  Each
     response element describes a resource, and has an 'href' element
     identifying the resource.  The 'href' element MUST contain an
     absolute URI or relative reference.  It MUST NOT include "." or ".."
     as path elements.

     If a 'href' element contains a relative reference, it MUST be
     resolved against the Request-URI.  A relative reference MUST be an
     absolute path (note that clients are not known to support relative
     paths).

NEW:

     The Multi-Status response format may contain 'href' elements
     (Section 13.7) in multiple places, namely as child element of
     'response' elements (Section 13.24).  When the contents of an 'href'
     element contains a Relative Reference ([RFC3986], Section 4.2), it is
     relative to the Request-URI of the HTTP request.

     Interoperability experience shows that many clients do not fully
     implement the Reference Resolution defined in Section 5 of [RFC3986].
     Therefore servers SHOULD NOT use 'href' values that:

     o  use forms of relative references other than absolute paths (see
        "absolute-path", [RFC3986], Section 3.3),

     o  use dot-segments ("." or "..") or

     o  have prefixes that do not match the Request-URI (using the
        comparison rules defined in Section 3.2.3 of [RFC2616]).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 23 Jan 2006 09:32:46 -0800

So if the server won't use the same prefix that the Request-URI  
contained, then the guidance would be that the server should redirect  
the entire request?

Lisa

On Jan 22, 2006, at 9:29 AM, Julian Reschke wrote:

>
> Hi,
>
> related to <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi? 
> id=46>, we discussed on the mailing list in which ways a server may  
> rewrite the Request-URI in multistatus responses.
>
> For instance, is it legal to rewrite (that is, are clients expected  
> to handle):
>
> 1) changing the authority, for instance, by replacing a host name  
> by an IP address,
>
> 2) yes, because that's usually hard to prevent inside the server if  
> the request URL isn't kept as a plain string,
>
> Note re 1) this point becomes irrelevant if the server is smart  
> enough to put relative references into the <href> elements.
>
> I therefore propose the following change to Section 12.2 (<http:// 
> greenbytes.de/tech/webdav/draft-ietf-webdav- 
> rfc2518bis-10.html#rfc.section.12.2>):
>
> Section 12., para. 6:
> OLD:
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jan 2006 18:41:53 +0100

> contained, then the guidance would be that the server should redirect 

Either that, or send a Content-Location header (as already proposed for 
trailing slash conflicts).

Letting it return 207 with URLs the client can't map will probably not help.

Best regards, Julian