RE: Relative URIs in DAV:reftarget

The general tenor of your comments here seems right to me.

The whole idea of redirect references is supposed to be that the server
never actually has to follow them to their targets.  It's not required to
guarantee their integrity; it never has to check whether DAV:reftarget
actually maps to a resource.  They're supposed to be very simple for servers
to support using just the 302 capabilities that they already have.  My
assumption would be that the server just uses the value of DAV:reftarget
that is passed in with a MKRESOURCE request exactly as it appears there, and
treats DAV:reftarget as a dead property.  

It's up to the client whether it passes in an absolute or a relative URI.
For some applications, like the one you describe where whole hierarchies
tend to be moved, a relative URI is preferable.  For others, where
individual resources tend to get moved, an absolute URI may be preferable.

Yes, the server does have to resolve any relative URIs in DAV:reftarget to
absolute URIs when it returns the Location header.

It sounds as if all this needs clarification in Section 9.

> -----Original Message-----
> From: Joe Orton [mailto:joe@orton.demon.co.uk]
> Sent: Saturday, January 29, 2000 4:48 PM
> To: w3c-dist-auth@w3.org
> Subject: Relative URIs in DAV:reftarget
> 
> 
> Section 9 of redirectref-02 talks about resolving relative URI's in
> DAV:reftarget.
> 
> It talks about resolving them in the context of a MKRESOURCE 
> request, and
> gives an example of this, but I'm not sure why. This implies 
> to me that
> when a client submits a MKRESOURCE with a relative URI, the 
> server will
> resolve that URI immediately and store it in DAV:reftarget as 
> an absolute
> URI?
> 
> Of course, if you MOVE the reference resource, this is an 
> important issue:
> does the reftarget still point to the same place as before (if it was
> resolved at the time of MKRESOURCE), or is it now used 
> relative to the new
> URI of the RR?
> 
> IMO the latter behaviour is strongly desired: if you have a deep
> collection heirarchy with some relative cross-referencing amongst the
> leaves of the tree, you want them to still work if you rename 
> a top-level
> collection. Unix symlinks are like this if you want some 
> precedence. (I'm
> not sure, but I don't think you can store relative targets in Windows
> "shortcuts"?)
> 
> I think the most important point about relative URIs in 
> DAV:reftarget is
> that they must be resolved by the server when it returns the Location
> header in a 302 response, since this must be absolute. Other 
> than that,
> the value of this property should be pretty opaque to the server, just
> like any other dead property?
> 
> joe
>

Received on Tuesday, 1 February 2000 13:59:16 UTC