Subject: RE: Issue: Requiring server to use / terminated URL for returned collections

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 17 Sep 2002 17:37:21 -0400

There was not enough information in this message to determine
what exactly was the problem that he was reporting.  You can type
in a non-slash terminated URL into IE5 (e.g.
<http://www.webdav.org/deltav>, and relative references are
handled properly.

Perhaps he was testing against a poorly implemented server
(i.e. one that did not either 302-redirect to the slash terminated
or did not return a slash-terminated Content-Location header).

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Tuesday, September 17, 2002 1:28 PM
To: 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: Issue: Requiring server to use / terminated URL for
returned collections

I dug out another testimonial to the interoperability problems of not
consistently using trailing slashes. 

Geoff Alexander said:
"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."

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0247.html

lisa

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 18 Sep 2002 10:38:51 -0400

> ... I need to see some compelling reasons why a
   > collection requires protocol-imposed naming constraints.

   Another reason was given by Roy in an older mail:

   "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.

That is because pre-WebDAV HTTP servers just redirected a request on
what WebDAV identifies as a collection (with or without the last
slash) to some server-defined member of that collection
(e.g. index.html).

   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."

If that is in fact a problem, then the server won't do it.  On the
other hand, if the server's implementation does not support trailing
separator characters, and the user expects this equivalence because
all other protocols that access this server do so, it may be
significantly more complex (for both the implementor and a user of the
repository) to try to fake trailing separator characters as indicating
a separate resource.  That is why the mapping of URIs to types of
resources needs to be under the server's control, not predefined by
the protocol.

   If the server consistently uses the same URL for each resource,
   then it's easier for clients and intermediaries to handle (cache,
   compare, concatenate paths, etc) those resources.

With the presence of multiple bindings to the same resource
(something that is explicitly allowed by the rfc2616, and
explicitly supported by the BIND protocol extension), the
client cannot assume that there is only one URI for a given
resource.  Any client that assumes otherwise has a serious bug
that should be fixed.

   > Since when is a collection path without a trailing slash a "bad
   > Request-URI"?  RFC-2518 explicitly states in Section 5.2 that "a
   > resource may accept a URI without a trailing '/' to point to a
   > collection."  If you are proposing to change this semantics, then
   > I object even more vigorously (but I'll save those objections
   > until I verify that you are proposing to make this change).

   I don't think it matters too much which one you pick, with trailing
   slash or without (with trailing slash is slightly more convenient
   because it's a marker for collections). However, there was strong
   opinion that the spec should pick one. Allowing such flexibility,
   as usual, makes life harder for clients.

The only client complexity that we have identified is the need for the
client to add a '/' before adding a new segment, if there is not yet a
slash there (usually in one line of code).  Given that file system
clients have dealt with this for years with no issues, I see no reason
why this is any harder for HTTP/WebDAV clients.  If the spec is
ambiguous, or the algorithms required are complex, then certainly one
can fix the protocol, but if a client just has a bug with a simple
fix, you fix the client -- you don't change the protocol to workaround
that bug for a few special cases.

   > Note also that there is no requirement in 2518 for a server to
   > redirect a non-GET request (it just needs to return the '/'
   > terminated name in a Location header).  Note that I have no
   > problem with requiring that a Location header be returned, since
   > if the server is applying a method to a resource, it will have
   > had to find out what type of resource it is anyway.

   Yes. And if the server returns the slash-terminated name in a
   Location header, it should use the SAME name everywhere else in the
   response.

That is an opinion with which I disagree.

   > The only real interoperability problem I saw identified above was
   > the "clients don't redirect properly", and the solution there is
   > to fix the broken clients, not change URL conventions so that the
   > broken clients work better in this one case of redirection.  (I
   > consider the addition of a slash when extending a URL to be a
   > trivial coding issue, not an interoperability problem).

   Also an interoperability problem found was "clients don't append new
   child names properly onto collection names".

That was the "trivial coding issue" I was referring to.  A client that
appends a new segment to a URL without ensuring there is a
preceding '/' just has a bug, and a bug that is trivial to fix.

Cheers,
Geoff

---

From: Jason Crawford <[email-masked]>
Date: Mon, 23 Sep 2002 19:13:23 -0400

Wow.  What a discussion this has been.   I'll try to pull this together.  I
can't claim to have understood everything said since some comments were
terse and were not followed up.

There has been a statement that there is an interoperability issue with not
having the server always return a trailing slash when refering to a
collection.   Apparently there were true interoperability problems, but no
hard interoperability problems were brought up in the discussion except as
noted below.

Geoff admitted that it is helpful for a client/server to use the slash for
GET requests to collections because it creates the possibility of just
returning the content of the ./index.html file (for example) without a
redirect.   (Otherwise the relative URL's inside the index.html file might
need to be fixed up.)   There was some additional discussion that the
redirect might not even be necessary if browsers better supported the
Content-Location header.  (Perhaps we need to get the attention of some
teams writing some browsers?)

Geoff asserted that it can be expensive for a server to determine if a
non-slash terminated URL maps to a collection or not.  He'd rather not have
to make that calculation unless explicitly required.   Some folks expressed
the thinking that hopefully that cost can be avoided by techniques and that
making a second request to the server clearly has a performance price.
Geoff asserted that (in my words, not his) that the second request
(PROPFIND) is probably necessary anyway if any other information is needed.

It was asserted that the server should at least be consistant in what it
returns.  Although no detail on this point was provided I think the point
was that a server shouldn't be passing a mixture of slash terminated and
non-terminated URL's for the same resource.  By doing so it leaves the
client to notice and assume at some risk  that they are really the same
resource.  (An example might help make this case.)

No one has protested the returning of the terminating slash.  There was
just some protesting that it be required.

As far as I know, and I know there had previously been discussion that
would violate this assertion, if the server sends a URL with a terminating
slash, the client can assume there is a collection at that location.  If
this assertion remains true, the server returning this slash when accessed
by a client that leverages this insight, can appear to be a more responsive
server than one that doesn't return the trailing slash.

I think the remaining issues are...

Were there truly some interop issues with not always returning a trailing
slash?  What were they?  Would a requirement of consistancy work just as
well as requiring a terminating slash?

Certain broken behaviors in existing clients/servers was mentioned.  What
products, people, etc do we need to follow up with?

Can a client assume that, if a server returns a URL that ends in a slash,
the resource referenced is a collection?

------------------------------------------
Phone: 914-784-7569

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 25 Sep 2002 11:48:31 -0400

From: Jason Crawford [mailto:[email-masked]]

   Were there truly some interop issues with not always returning a
   trailing slash?  What were they?  Would a requirement of
   consistancy work just as well as requiring a terminating slash?

   Certain broken behaviors in existing clients/servers was mentioned.
   What products, people, etc do we need to follow up with?

   Can a client assume that, if a server returns a URL that ends in a
   slash, the resource referenced is a collection?

I would have no problem with that requirement, if it can be 
demonstrated to have significant client value.

Cheers,
Geoff

---

From: Jason Crawford <[email-masked]>
Date: Fri, 27 Sep 2002 00:29:29 -0400

> demonstrated to have significant client value.

Okay guys. I could make this case, but I'd prefer someone
that builds clients to make it  since it is clients that would would
benefit.

A proposal came out of the
interop that we have servers always return slash terminated
URL's for collections.  That proposal is meeting some
resistance, but there is another proposal on the table that appears
to have some of the advantages of the original proposal.  Geoff
has left the door open for this proposal if a case is made.  If you
were at the interop and have a case to present related
to slash termination, please present it.

J.