RE: Collections and Request-URIs

Hi,

first of all I really have a problem with the language here. WebDAV clients
that implement RFC2518 and RFC2616 (minus erratum published in March 2001)
*to the letter* suddenly are called "broken".

It's good that the erratum  for RFC2616 allows clients to follow the
redirect automatically.

However, I think the following issues remain:

1) Roy says:

> That is correct.  And, BTW, RFC 2518 is in fact incorrect in the paragraph
> quoted, something which I stated numerous times when it was a draft.
> There are no known examples of HTTP servers for which the URI without a
> slash is the SAME RESOURCE as the URI with a slash.  Automatically
> providing two different URI for the same resource, particularly when
> they cross hierarchical syntax, instantly doubles the application
> name space (bad for IR and QA) and creates holes in access control.
> That is why ALL general HTTP servers provide PERMANENT REDIRECTS
> >from a WRONG URL to a better URL for the sake of stupid authors of
> broken references.  They have never been the same resource on any
> server for which I have ever had readable code.

In this case this needs to be put on the RFC2518 issues list.


2) In the particular case of moddav2, we're stuck with a situation where an
additional roundtrip is required to PROPFIND information about a resource
(if it's not known in advance to be a collection). I'm still interested in
an approch where the roundtip can be avoided.


3) WebDAV's namespace model is not completely compatible to HTTPs: every
WebDAV compliant URL namespace conforms to RFC2616, but not the other way
round. That's a fact the WebDAV WG has to deal with. In particular:

Given a collection /a and HTTP resources "/a/b" and "/a/b/" (where "/a/b"
and "/a/b/" are NOT the same resource) -- what should a PROPFIND on /a with
depth 1 report? I can think of (a) it should fail (because "/a" isn't a
WebDAV compliant collection), (b) it silently suppresses the response
element for "/a/b" or (c) it reports both. Looking at RFC2518, section 5.2
[1], (c) seems to be possible but I'm sure that few WebDAV clients are
prepared to handle this.

Is anybody aware of a WebDAV server that *does* dinstinguish between "/a/b"
and "/a/b/" and behaves as described in (c)? (Can I configure Apache2/moddav
to handle this situation?).

Feedback appreciated,

Julian

[1] <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.5.2>

Received on Wednesday, 19 June 2002 01:19:35 UTC