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

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?)

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

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.

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

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.

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

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.

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

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

> 
> -----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 16:41:11 UTC