RE: Collections and Request-URIs

I don't think anybody was proposing that an intermediary server
that is just forwarding the request along would make the decision
about whether trailing slashes are semantically meaningful.
It would just forward the URL along to the server that is actually
going to perform the requested method.  But the server that is
actually performing the requested method should feel free to ignore
trailing slashes, if that is the semantics that it wants to provide.

Cheers,
Geoff

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@apache.org]
Sent: Thursday, June 20, 2002 4:14 PM
To: Clemm, Geoff
Cc: w3c-dist-auth@w3c.org
Subject: Re: Collections and Request-URIs


On Wednesday, June 19, 2002, at 08:04  PM, Clemm, Geoff wrote:
>    From: Roy T. Fielding [mailto:fielding@apache.org]
>
>    ... the ONLY interoperable behavior when faced with a slashless
>    collection request is to perform an external redirect, even if that
>    means existing WebDAV clients will puke and die.
>
> I would have thought that interoperability should take into account
> reality (:-).

Operations must fail safe rather than operating unsafe.  I should have
forced the client to puke and die -- it would have been fixed faster.

> I can see why you wouldn't want the spec to require that a server
> treat identically URIs with and without a trailing slash, but I cannot
> see on what basis you would require a server to not make this
> equivalence.  A client cannot count on them being different
> resources, since the mapping of URIs to resources is up to the
> server, but if a server decided to map trailing URIs with and without
> a trailing slash to the same resource, it should be free to do so. For
> that matter, if it wanted to map every URL in its URL space to the
> same resource, it should be free to do so (although it probably
> wouldn't be an especially popular web site unless that was a really
> interesting resource :-).

You aren't thinking at the right scale.  An "origin server" is a role
played in the communication between client and server over HTTP.  The
trivial case is that there is one server and one client, each residing
within one process and fully aware of the entire request-handling process.
The most common case is a general HTTP server consisting of an array of
resource handlers that are invoked according to a configurable set of
conditions based on elements of the request.  In the complex case, an
origin server consists of a hierarchy of HTTP servers that are selected
based on elements of the request, each of which in turn is made up of
configurable modules ...

The point being that, if the request URI needs to change in order
to handle the request correctly (meaning with the correct server selection,
module selection, and access control checks), a redirect to the correct
URI is necessary because the general-purpose HTTP server cannot know
whether it is the entire origin server or just one cog within a complex
assortment of HTTP servers.  Furthermore, because the hierarchy change
to the URI will change the interpretation of relative URI, none of the
intermediary servers can step in the way of the external redirect
before it gets to the client.

Yes, it is certainly possible for an HTTP server to treat both as
the same resource and not perform a redirect.  However, such software
is a bad HTTP server because it is trading-off a temporary inconvenience
for a potential security hole and a source of broken links.

None of this is an issue for WebDAV if collections are presented to the
client with the correct URL, ending with a slash.  The only time this
does not occur on a regular basis is when the representation of a
collection fails to use the correct URL in its own references.
Under normal circumstances, the only time that a WebDAV client will
need to request the wrong URL is when it is typed into the client
by hand on the very first entry of a Save As dialog.  I don't give a
rat's ass if that one case results in a redirect, and neither does
the user.

....Roy

Received on Thursday, 20 June 2002 23:30:04 UTC