additional state such as entity bodies returned by GET.  An internal
   member URI MUST be immediately relative to a base URI of the
   collection.  That is, the internal member URI is equal to a
   containing collection's URI plus an additional segment for non-
   collection resources, or additional segment plus trailing slash "/"
   for collection resources, where segment is defined in section 3.3 of
   [RFC2396].

   Any given internal member URI MUST only belong to the collection
   once, i.e., it is illegal to have multiple instances of the same URI
   in a collection.  Properties defined on collections behave exactly as
   do properties on non-collection resources.





 
RFC 2518                         WEBDAV                    February 1999


   For all WebDAV compliant resources A and B, identified by URIs U and
   V, for which U is immediately relative to V, B MUST be a collection
   that has U as an internal member URI. So, if the resource with URL
   http://foo.com/bar/blah is WebDAV compliant and if the resource with
   URL http://foo.com/bar/ is WebDAV compliant then the resource with
   URL http://foo.com/bar/ must be a collection and must contain URL
   http://foo.com/bar/blah as an internal member.

   Collection resources MAY list the URLs ofnon-WebDAV compliant
   children in the HTTP URL namespace hierarchy as internal members but
   are not required to do so. For example, if the resource with URL
   http://foo.com/bar/blah is not WebDAV compliant and the URL
   http://foo.com/bar/ identifies a collection then URL
   http://foo.com/bar/blah may or may not be an internal member of the
   collection with URL http://foo.com/bar/.

   If a WebDAV compliant resource has no WebDAV compliant children in
   the HTTP URL namespace hierarchy then the WebDAV compliant resource
   is not required to be a collection.

   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.

   A resource MAY be a collection but not be WebDAV compliant.  That is,
   the resource may comply with all the rules set out in this
   specification regarding how a collection is to behave without
   necessarily supporting all methods that a WebDAV compliant resource
   is required to support.  In such a case the resource may return the
   DAV:resourcetype property with the value DAV:collection but MUST NOT
   return a DAV header containing the value "1" on an OPTIONS response.

5.3 Creation and Retrieval of Collection Resources

   This document specifies the MKCOL method to create new collection
   resources, rather than using the existing HTTP/1.1 PUT or POST
   method, for the following reasons:







 
RFC 2518                         WEBDAV                    February 1999


   In HTTP/1.1, the PUT method is defined to store the request body at
   the location specified by the Request-URI.  While a description
   format for a collection can readily be constructed for use with PUT,
   the implications of sending such a description to the server are
   undesirable.  For example, if a description of a collection that
   omitted some existing resources were PUT to a server, this might be
   interpreted as a command to remove those members.  This would extend
   PUT to perform DELETE functionality, which is undesirable since it
   changes the semantics of PUT, and makes it difficult to control
   DELETE functionality with an access control scheme based on methods.

   While the POST method is sufficiently open-ended that a "create a
   collection" POST command could be constructed, this is undesirable
   because it would be difficult to separate access control for
   collection creation from other uses of POST.

   The exact definition of the behavior of GET and PUT on collections is
   defined later in this document.

5.4 Source Resources and Output Resources

   For many resources, the entity returned by a GET method exactly
   matches the persistent state of the resource, for example, a GIF file