Subject: Issue: Requiring server to use / terminated URL for returned coll ections

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 16 Sep 2002 08:54:06 -0400

I strongly object to adding a MUST for servers returning slash
terminated URLs for collections.

Most repositories do not allow trailing segment-separator characters
in the segment name of a resource, and therefore these trailing
segment-separator characters are commonly just stripped off before
that segment name is stored in the repository.  This means that in
order to decide whether to add the segement-separator character back
on, the implementation must query the repository for the type of each
resource identified by that segment.  Forcing this cost on the server
is only justified if it provides some compelling benefit to the
client.

The only concrete motivation I have heard for making this requirement
is to save a 302 redirect round trip for a client when the server
redirects a GET request on a collection to an internal member of the
request-URL (e.g. redirects "GET /foo" to "GET /foo/index.html").
Having the trailing slash present in the request-URL allows the server
to silently redirect the request to the internal member of the
request-URL without breaking client-side relative reference
processing.

But no WebDAV methods other than GET is redirected in this
fashion, and WebDAV clients will commonly not be doing a GET on a
collection (they will be doing a PROPFIND, and use the results to
construct a display), and so the overall benefit to a client of
avoiding a redirect on a GET to a collection is significantly
outweighed by the server cycles being wasted to determine whether or
not a collection member is a collection.

If a client cares whether or not a resource is a collection, it
can do a PROPFIND for its DAV:resourcetype.  That way, server
cycles are spent only when needed.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Sunday, September 15, 2002 2:14 PM
Subject: Issues from Interop/Interim WG Meeting

...
- Servers must use trailing slash whenever collection URLs are returned.
Language proposed for 2518 bis
...

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 16 Sep 2002 13:40:03 -0700

I'll try to recall more of the interop issues around using trailing
slashes in collection URLs.  If anybody else can remember details,
please fill in.
(Dan B?)

> is only justified if it provides some compelling benefit to the

Yes, the server must know the type of each resource in order to
construct its URL properly. Or the repository could save or cache the
URL for each resource. There are lots of options.

> request-URL without breaking client-side relative reference

There are other problems encountered and discussed at the interop.  In
fact, the GET/redirect problem is one of the least troublesome because
it's just a performance problem, not (typically) an interoperability
problem.
 - Clients aren't consistent in supporting redirects for other methods
besides GET. Yet if the client sends a bad Request-URI (a collection
path without a trailing slash), the server needs to do something.
 - Servers aren't consistent in putting the trailing slash in various
places: the Content-Location header, the Location header, and <href>
elements inside Multi-Status. Clients need to look for the trailing
slash and possibly add it in order to be able to do further operations.
E.g. clients would like to be able to display results consistently in
folder views, yet servers aren't consistent.
 - Clients need to know how to generate a correct URL for a MKCOL, PUT,
MOVE or COPY to create a new resource in an existing collection. This
means parsing the collection URL to make sure it ends in a slash before
adding the terminal part.

> not a collection member is a collection.

First, this is an issue not only for GET.  The problems with other
methods are not just redirects, but how the client constructs URLs for
new resources.  

Second, it's a matter of opinion what situation has what benefits and
which wastes cycles where. Certainly avoiding redirects improves
performance for the client because it reduces roundtrips. Also providing
correct URLs saves cycles on the client although that's usually less of
a concern.  Note that for some servers, a redirect is higher cost than
just making the URLs correct, because a redirect is an entirely new
request, new database or filesystem query, etc.

> cycles are spent only when needed.

It's not only that the client cares what type of resource the URL refers
to, although knowing that is nice. It's also how to construct correct
new URLs and how to interpret the results of a PROPFIND.

Since there have been actual interoperability problems, I still find
this a good candidate for making the specification clearer, even if this
is a few more cycles on the server. Real interoperability problems are
much worse problems than a minor increased burden on the server.

Lisa

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 16 Sep 2002 17:48:37 -0700

> is only justified if it provides some compelling benefit to the

That's simply not true.  Most repositories store the type of a resource
along with the resource name in the collection (a.k.a. directory) and
thus that information is available at the time the segment is used
within a link describing the collection at no extra cost to the server.

All other repositories are fully capable of improving their internal
implementation.  OTOH, the protocol specification is responsible for
specifying that which is clearly most efficient for the protocol and
for those servers that have already anticipated its implementation.

....Roy