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

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:lisa@xythos.com]
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
...

Received on Monday, 16 September 2002 09:24:13 UTC