RE: RFC2518 issue: DAV:href format

The specific reference in RFC2518 is to the definition of "URI" in section
3.2.1 in RFC2068, which corresponds to the definition of "URI-reference" in
section 4 of RFC2396. In both places, the definition is

  [ absoluteURI | relativeURI ] [ '#' fragment ]

which seems clear to me that the content of a DAV:href element can be either
an absolute or relative URI.

Also, as an implementor of a mod_dav "repository provider", I can say that
it would be difficult to construct absolute URI's in the layer of code which
generates DAV:href elements, since that layer has no access to the Apache
request info needed to construct an absolute URI.

So relative URI's are desirable, both from an implementor's standpoint, and
from the fact that they reduce message size somewhat. From the above
definitions, RFC2518 clearly allows relative URI's in DAV:href elements. I
agree that it should be clarified what the base URI is; since all the
clients I've looked at assume it is the request URI, then that seems like
the right thing to say.

John

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Thursday, February 28, 2002 9:39 AM
> To: w3c-dist-auth@w3c.org
> Subject: RFC2518 issue: DAV:href format
> 
> 
> See <http://www.greenbytes.de/tech/webdav/rfc2518.html#ELEMENT_href>.
> 
> RFC2518 says that the contents of DAV:href is a URI as 
> defined by RFC2068
> (which should be updated to refer to RFC2396).
> 
> The spec seems to be consistent with this (all examples 
> include protocol and
> authority).
> 
> However, Apache moddav only returns relative URI references 
> (protocol and
> authority are missing), so technically doesn't return URIs at 
> all. Microsoft
> IIS returns correct URIs. All clients seem to be happy with both.
> 
> So,
> 
> 1) either Apache moddav should be fixed, or
> 2) RFC2518 should allow relative URI references.
> 
> *If* we go with 2), the spec will have to define which base 
> URI needs to be
> used to resolve the URI reference to a full URI (the request 
> URI comes to
> mind). Note that this would allow new kinds of PROPFIND responses that
> *will* not interoperate with many clients:
> 
> PROPFIND /foo/bar
> Depth: 1
> 
> ..
> 
> <multistatus>
>   <reponse>
>     <href/>
>     ...
>   </response>
>   <response>
>     <href>child-of-bar</href>
>     ..
>   </response>
> </multistatus>
> 
> 
> (This could be avoided by saying that the base URI *always* is
> "<protocol>://<host>:<port>/").
> 
> 
> 
> 
> 
> 
>

Received on Thursday, 28 February 2002 13:00:27 UTC