RE: href element, type of URI inside?

The URI is relative to the request-URI unless of course there is a
content-base header or if the content type has its own base declaration (as
HTML files can do). I can't wait till someone introduces the "reset the base
URI" header into XML and then wonders why none of their requests/responses
work properly.

Even if you somehow figure out the rules then you end up with implementation
issues. Lots of folks use one system to handle their HTTP, another their XML
and a third adds WebDAV specific capabilities. My experience has been that
most HTTP stacks don't do anything special with content-base so it never
makes it to the XML parser and thus the WebDAV specific code has no idea
that the header is there. This works on both requests and responses.

I'm trying not to imagine what the few systems who do understand relative
URIs will do with non-HTTP relative URIs.

So unless your idea of interoperability involves a random number generator I
would stay away from relative URIs in HREF elements.

> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Wednesday, March 31, 1999 5:27 PM
> To: ccjason@us.ibm.com
> Cc: w3c-dist-auth@w3.org
> Subject: Re: href element, type of URI inside?
> 
> 
> The WebDAV spec, section X states:
> 
> HTTP 1.1 protocol spec (I.D. rev6, an update to RFC2068), 
> section 3.2.1
> states:
> 
> "URIs in HTTP can be represented in absolute form or relative to some
> known base URI [11], depending upon the context of their use."
> 
> A response containing an <href> element definitely has a 
> known base URI
> (the resource that the PROPFIND was issued against). Therefore, a
> relative URI should be acceptable.
> 
> Caveat: well, maybe it doesn't "definitely" have a known base 
> since that
> was not specified in the WebDAV spec, but it seemed obvious to me ;-)
> 
> ccjason@us.ibm.com wrote:
> >...
> > Which is recommended?
> > 
> >      /mypath
> >  or
> >    http://myhost/mypath
> > 
> > Are there situations where one is better than the other?    
> Are there
> > situations where one or the other is required?
> 
> I'm biased of course :-), but I don't see a lot of problem with using
> either the two. For a server writer, it is sometimes more difficult to
> use the absolute form. This is because it can be hard to know what
> absolute-URI was used to access the resource. Specifically, multiple
> hostnames may be used to access the same resource (e.g. a bunch of
> CNAMES or partially-qualified host names)
> 
> [ caveat: actually, this could simply be an artifact of server design,
> rather than a difficulty derived from the protocol itself. ]
> 
> > Just to get the mind working...
> > 
> > <rhetorical>
> > If a scheme and host are specified, must it point to the 
> webdav enabled
> > URI?  For example, if the main server is on port 80 and 
> webdav access is
> > only allowed on port 8080, then MUST the URI include 8080 if it also
> > specifies the host and scheme?
> 
> Absolutely. The <href> must provide a URI that can be used, and that
> actually contains the properties listed in the PROPFIND result.
> 
> Let's say you asked for http://myhost:8080/mypath and the result said
> http://myhost/mypath. Now you attempt to issue a PROPPATCH against the
> returned URI to correct a value that you found in there. Oops! Doesn't
> work.
> 
> > Are there situations where a scheme or host other than that 
> used for the
> > current webdav connection might be appropriate?  ie...
> >    shttp://myhost/mypath
> >    http://otherhost/mypath
> > might be appropriate?   Is this even allowed?  Or are these 
> possibilities
> > reserved for further extensions?
> 
> I would think that you could return any "direct reference" in 
> the <href>
> element, where that direct reference specifies the resource 
> on which you
> reported the properties.
> 
> > Does the presense/possibility of references/passthru affect 
> the answers
> > above?
> 
> Yup. IMO, any direct reference should be acceptable for 
> reporting, since
> they (technically) provide access to the properties reported in the
> PROPFIND.
> 
> Cheers,
> -g
> 
> --
> Greg Stein, http://www.lyra.org/
>

Received on Friday, 2 April 1999 11:05:24 UTC