Subject: RE: Collections and Request-URIs

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 18 Jun 2002 12:42:19 -0400

Yes, I would want the statement to hold, independent of what kind of
resource (if any) is currently identified by that URI.  I also would
prefer a MUST over a SHOULD.

Cheers,
Geoff

-----Original Message-----
From: Dan Brotsky [mailto:[email-masked]]
Sent: Tuesday, June 18, 2002 12:06 PM
To: Clemm, Geoff
Cc: [email-masked]
Subject: Re: Collections and Request-URIs

On Tuesday, June 18, 2002, at 04:49 AM, Clemm, Geoff wrote:
> I agree with Julian (i.e. that trailing slashes are allowed by
> the syntax), but I also have argued vigorously that the RFC-2518
> "guidance" is incorrect, and the next revision of RFC-2518 should
> simply state "a URI with a trailing slash SHOULD identify the
> same resource as the URI with the trailing slash removed".

But do you also want this to be the case for non-collection resources?  
Perhaps you mean "if a URI that ends in a trailing slash identifies a 
DAV-compliant collection resource, then the same URI with the trailing 
slash removed SHOULD identify the same resource."  I would actually go 
for MUST in that case, although such a change would break some existing 
servers.

     dan

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 28 Jun 2002 15:48:58 -0700

Accidentally caught by the spam filter. I have added <[email-masked]> to
the accept2 list, so future email from Geoff Alexander will go straight
through to the list. Please cc Geoff on your reply, since it's unclear
whether he's subscribed to the list.

- Jim

-----Original Message-----
From: Geoff Alexander [mailto:[email-masked]]
Sent: Friday, June 28, 2002 2:44 PM
To: [email-masked]
Subject: [Moderator Action] Re: Collections and Request-URIs

On Mon, 17 Jun 2002 16:45:44 -0700, Jim Luther wrote:
RFC 2518, section 5.2 says:

"There is a standing convention that when a collection is referred to by
its name without a trailing slash, the trailing slash is automatically
appended.  Due to this, a resource may accept a URI without a
trailing "/" to point to a collection. In this case it SHOULD return a
content-location header in the response pointing to the URI ending with
the "/". For example, if a client invokes a method on
http://foo.bar/blah (no trailing slash), the resource
http://foo.bar/blah/ (trailing slash) may respond as if the operation
were invoked on it, and should return a content-location header with
http://foo.bar/blah/ in it.  In general clients SHOULD use the "/" form
of collection names."

We are developing a WebDAV server and have encountered interoperability
problem with request on collections in which the resource does not have a
trailing slash.  Where do things stand on this issue?  Our testing indicates
that the above does not work in the real world.  For example, both IE 5 and
Netscape 4.7 do not properly process relative references in response to a
GET request on a collection without the trailing slash..  I guess one could
say that IE and Netscape only support the HTTP protocol and not WebDAV
protocol, but then our server would have to determine whether the request
was HTTP or WebDAV (which is not a workable solution).  Also, we have
encountered interoperability problem with other WebDAV clients.

I see three possible solutions:

1. Treat the collection URI with out a trailing slash the same as same URI
with a trailing slash and include a Content-Location header with "corrected"
URI in the response.

2. Perform a a redirect by sending a 301 Moved Permanently response on safe
requests such as GET, HEAD, OPTIONS, and PROPFIND (Where can we find the
definitive list of the safe WebDAV and Delta-V safe methods?) and treat a
collection URI with out a trailing slash the same as same URI with a
trailing slash for unsafe requests.

3. Perform a redirect by sending a 301 Moved Permanently response on all
requests.
It seems that all of three of the solutions result in interoperability
problems with some WebDAV clients.  So what is a WebDAV server writer to do?

Thanks,
Geoff Alexander, Ph.D.
919/254-5216 T/L 444-5216
CMVC WebDAV Development
IBM Corporation
RTP, NC