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

> In general, this is not true.  A given segment name can refer to
> various types of resources.  In particular, it is not true for any of
> the DeltaV types (activity, version history, workspace) or of any of
> the ACL types (principal, group principal).  It is not true for the
> advanced collection types (redirect reference).  In fact, the only
> exception is collection vs. non-collection.  In all other cases, we
> let the client (preferably) or the server decide on any naming
> conventions/constraints, and 2518 gives servers the option in this
> case (i.e. to automatically add a slash to a request, to produce
> typeless names).  I need to see some compelling reasons why a
> collection requires protocol-imposed naming constraints.

Another reason was given by Roy in an older mail:

"There are no known examples of HTTP servers for which the URI without a
slash is the SAME RESOURCE as the URI with a slash.  Automatically
providing two different URI for the same resource, particularly when
they cross hierarchical syntax, instantly doubles the application
name space (bad for IR and QA) and creates holes in access control."

If the server consistently uses the same URL for each resource, then
it's easier for clients and intermediaries to handle (cache, compare,
concatenate paths, etc) those resources.

> Since when is a collection path without a trailing slash a "bad
> Request-URI"?  RFC-2518 explicitly states in Section 5.2 that "a
> resource may accept a URI without a trailing '/' to point to a
> collection."  If you are proposing to change this semantics, then I
> object even more vigorously (but I'll save those objections until
> I verify that you are proposing to make this change).

I don't think it matters too much which one you pick, with trailing
slash or without (with trailing slash is slightly more convenient
because it's a marker for collections). However, there was strong
opinion that the spec should pick one. Allowing such flexibility, as
usual, makes life harder for clients.

> Note also that there is no requirement in 2518 for a server to
> redirect a non-GET request (it just needs to return the '/' terminated
> name in a Location header).  Note that I have no problem with
> requiring that a Location header be returned, since if the server
> is applying a method to a resource, it will have had to find out
> what type of resource it is anyway.

Yes. And if the server returns the slash-terminated name in a Location
header, it should use the SAME name everywhere else in the response.

> This appears to be based on the same false premise as above, i.e.
> that a client needs to add a trailing slash to make a request
> on a collection.  

Not only that, but the client also needs to add a trailing slash in
order to make a request on children of the collection.

 
> The only real interoperability problem I saw identified above was the
> "clients don't redirect properly", and the solution there is to fix
> the broken clients, not change URL conventions so that the broken
> clients work better in this one case of redirection.  (I consider the
> addition of a slash when extending a URL to be a trivial coding issue,
> not an interoperability problem).

Also an interoperability problem found was "clients don't append new
child names properly onto collection names".

Lisa

Received on Tuesday, 17 September 2002 13:37:10 UTC