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

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 Sunday, 22 January 2006 17:32:10 UTC