content-location vs. location for "/" appending?

RFC 2518 says:
   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 content-location header in the response pointing to
   the URI 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 content-location header with
   http://foo.bar/blah/ in it.  In general clients SHOULD use the "/"
   form of collection names.


However, "Content-Location" as a header in RFC 2616 (section 14.14)
refers to the location of the entity body, not the revised location
of the resource.

If you're going to supply a new location in response to, for example,
a PROPFIND, I think you should use the "Location:" header and not
"Content-Location".

I know at the interop there were some difficulties with trailing slash
equivalences for collections, so maybe this is something that can be
fixed.

Received on Sunday, 26 August 2001 01:34:52 UTC