[Bug 46] URLs in Multistatus

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |



------- Additional Comments From julian.reschke@greenbytes.de  2006-01-17 12:17 -------
"Clear" changes have been proposed over and over again, including in this very
entry.

The current spec text could be improved, but I think replacing all of 12.1 is
the superior approach, because it uses the proper terminology and grammar
productions from RFC3986, adds constraints on the contents of hrefs that the
current text doesn't have, clarifies fuzzy language about URI escaping, and also
adds an example.

I think we should discuss this change again; the current text could be fixed to
say the same, but the effort seems to be much greater than just adopting this one.



12.2  URL Handling

   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 ".."),

   o  use a notation for the authority part of a URI (see "authority",
      [RFC3986], Section 3.2) other the one used in the HTTP request or

   o  use a different notation for the part of the path that identifies
      the Request-URI.

   Identifiers for collections appearing in the results SHOULD end in a
   '/' character.

12.2.1  Example for correct URL handling

   Consider the collection http://example.com/sample/ with the internal
   member URL http://example.com/sample/a%20test and the PROPFIND
   request below:

   >>Request:

     PROPFIND /sample/ HTTP/1.1
     Host: example.com
     Depth: 1

   In this case, the server should return 'href' elements containing
   either

   o  'http://example.com/sample/' and
      'http://example.com/sample/a%20test', or

   o  '/example.com/sample/' and '/example.com/sample/a%20test'.

   Note that even though the server may be storing the member resource
   internally as 'a test', it must be percent-encoded when used inside a
   URI reference (see [RFC3986], Section 2.1).  Also note that a legal
   URI may still contain characters that need to be escaped within XML
   character data, such as the ampersand character.





------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

Received on Tuesday, 17 January 2006 20:17:23 UTC