- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 22 Jan 2006 18:29:39 +0100
- To: WebDav <w3c-dist-auth@w3.org>
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