Re: Using absolute URIs in headers and properties in DAV

Lisa Dusseault wrote:

> Originally in RFC2518, the Destination header, the If header and the 
> <href> element all contained only absolute URIs (no paths).  Then, after 
> the 2002 Interop, we opened that up so that RFC2518bis now says the 
> Destination header could take "abs path" as well.  However, it was then 
> pointed out (Dec 9 2002 mail) that we should make the If header 
> consistent with the Destination header, which might also imply making 
> the <href> format the same.  Nobody followed up on that Dec 9 2002 mail 
> as far as I can see, so I'd like to reraise the issue.
> 
> 1.  Status quo in 'bis' -- are we really sure we want to make the 
> Destination header inconsistent with the other DAV elements that take 
> URI values?
> 2.  Back to RFC2518 status -- only one option (full URIs) consistent 
> across all uses
> 3.  Forge ahead and allow absolute paths in Destination, If header, and 
> possibly also <href>.  Doesn't this have backward compatibility issues?
> 
> I'd like to recheck our reasoning on this one, and whether there's 
> really a need to allow absolute paths in the value of Destination 
> header.  It was an interoperability issue, but I don't have all the 
> details on why clients might find it difficult to include the 
> server/host part of the URI.

Note that we already allow non-absolute URIs in href elements (right now 
defined as per 3.2.1 of RFC2068), so the inconsistency is just with 
places where we currently require "Coded-URL".

Anyway, the spec should only be changed if that change doesn't break 
existing servers. So if one of Apache/moddav, MS IIS (and possibly 
others) do not allow non-absolute URIs , we shouldn't make any change.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 8 July 2004 02:13:19 UTC