Proposed Language Change to Section 3.1

Currently the last paragraph of section 3.1 reads:

There is a standing convention that when a collection is referred to by its
name without a trailing slash, the trailing slash is automatically appended.
Due to this, a resource may accept a URI without a trailing "/" to point to
a collection. In this case it SHOULD return a location header in the
response pointing to the URL ending with the "/".  For example, if a client
invokes a method on http://foo.bar/blah (no trailing slash), the resource
http://foo.bar/blah/ (trailing slash) may respond as if the operation were
invoked on it, and should return a location header with http://foo.bar/blah/
in it.  In general clients SHOULD use the "/" form of collection names.

I would like to propose a change in the language which will tighten the
collection naming requirements such that a collection's "official" name MUST
end in a "/", specifically I propose replacing the entire paragraph with:

Collections MUST be named with URLs that end in a "/". This does not mean
that all resources whose names end in "/" are collections, only that all
collections must have names that end in "/"s. If a client asks for a
resource without a final "/" and no such resource exists but a resource with
the exact same URL, with the addition of a "/" exists, the server MAY send a
304 Moved Permanently containing a location header that points to the URL
ending with a "/".  For example, if a client invokes a method on
http://foo.bar/blah (no trailing slash), which is a non-existent resource,
the server may respond with a 304 Moved Permanently containing a location
header pointing at http://foo.bar/blah/.

By tightening up the requirement we take care of possible cache confusion.
The use of the location headers for responses other than 201 Created and 3xx
was not foreseen by the HTTP/1.1 specification so there is a strong
possibility that users asking for http://foo.bar/a could get a different
response than looking for http://foo.bar/a/ in the case when both point to
the same resource. The redirect gets rid of this problem. I propose getting
rid of the requirement that clients SHOULD use the "/" form since it is
fairly meaningless now that we define the "/" name as the only "true" name
for collections.

			Yaron

Received on Saturday, 31 January 1998 17:50:48 UTC