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

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

Received on Monday, 23 January 2006 17:33:01 UTC