W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

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

From: Jason Crawford <nn683849@smallcue.com>
Date: Mon, 23 Sep 2002 19:13:23 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <OFDE4294DA.56D4AE1C-ON85256C3D.007B87DA@us.ibm.com>

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
Received on Monday, 23 September 2002 19:34:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC