rfc2518.txt

RFC 的详细文档！

   WebDAV servers that support locking can reduce the likelihood that
   clients will accidentally overwrite each other's changes by requiring
   clients to lock resources before modifying them.  Such servers would
   effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying
   resources.

   WebDAV clients can be good citizens by using a lock / retrieve /
   write /unlock sequence of operations (at least by default) whenever
   they interact with a WebDAV server that supports locking.

   HTTP 1.1 clients can be good citizens, avoiding overwriting other
   clients' changes, by using entity tags in If-Match headers with any
   requests that would modify resources.

   Information managers may attempt to prevent overwrites by
   implementing client-side procedures requiring locking before
   modifying WebDAV resources.

7  Write Lock

   This section describes the semantics specific to the write lock type.
   The write lock is a specific instance of a lock type, and is the only
   lock type described in this specification.

7.1 Methods Restricted by Write Locks

   A write lock MUST prevent a principal without the lock from
   successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE,
   DELETE, or MKCOL on the locked resource.  All other current methods,
   GET in particular, function independently of the lock.

   Note, however, that as new methods are created it will be necessary
   to specify how they interact with a write lock.

7.2 Write Locks and Lock Tokens

   A successful request for an exclusive or shared write lock MUST
   result in the generation of a unique lock token associated with the
   requesting principal.  Thus if five principals have a shared write
   lock on the same resource there will be five lock tokens, one for
   each principal.

7.3 Write Locks and Properties

   While those without a write lock may not alter a property on a
   resource it is still possible for the values of live properties to
   change, even while locked, due to the requirements of their schemas.




Goland, et al.              Standards Track                    [Page 20]

RFC 2518                         WEBDAV                    February 1999


   Only dead properties and live properties defined to respect locks are
   guaranteed not to change while write locked.

7.4 Write Locks and Null Resources

   It is possible to assert a write lock on a null resource in order to
   lock the name.

   A write locked null resource, referred to as a lock-null resource,
   MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to
   any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND,
   LOCK, and UNLOCK.  A lock-null resource MUST appear as a member of
   its parent collection.  Additionally the lock-null resource MUST have
   defined on it all mandatory DAV properties.  Most of these
   properties, such as all the get* properties, will have no value as a
   lock-null resource does not support the GET method.  Lock-Null
   resources MUST have defined values for lockdiscovery and
   supportedlock properties.

   Until a method such as PUT or MKCOL is successfully executed on the
   lock-null resource the resource MUST stay in the lock-null state.
   However, once a PUT or MKCOL is successfully executed on a lock-null
   resource the resource ceases to be in the lock-null state.

   If the resource is unlocked, for any reason, without a PUT, MKCOL, or
   similar method having been successfully executed upon it then the
   resource MUST return to the null state.

7.5 Write Locks and Collections

   A write lock on a collection, whether created by a "Depth: 0" or
   "Depth: infinity" lock request, prevents the addition or removal of
   member URIs of the collection by non-lock owners.  As a consequence,
   when a principal issues a PUT or POST request to create a new
   resource under a URI which needs to be an internal member of a write
   locked collection to maintain HTTP namespace consistency, or issues a
   DELETE to remove a resource which has a URI which is an existing
   internal member URI of a write locked collection, this request MUST
   fail if the principal does not have a write lock on the collection.

   However, if a write lock request is issued to a collection containing
   member URIs identifying resources that are currently locked in a
   manner which conflicts with the write lock, the request MUST fail
   with a 423 (Locked) status code.

   If a lock owner causes the URI of a resource to be added as an
   internal member URI of a locked collection then the new resource MUST
   be automatically added to the lock.  This is the only mechanism that



Goland, et al.              Standards Track                    [Page 21]

RFC 2518                         WEBDAV                    February 1999


   allows a resource to be added to a write lock.  Thus, for example, if
   the collection /a/b/ is write locked and the resource /c is moved to
   /a/b/c then resource /a/b/c will be added to the write lock.

7.6 Write Locks and the If Request Header

   If a user agent is not required to have knowledge about a lock when
   requesting an operation on a locked resource, the following scenario
   might occur.  Program A, run by User A, takes out a write lock on a
   resource.  Program B, also run by User A, has no knowledge of the
   lock taken out by Program A, yet performs a PUT to the locked
   resource.  In this scenario, the PUT succeeds because locks are
   associated with a principal, not a program, and thus program B,
   because it is acting with principal A's credential, is allowed to
   perform the PUT.  However, had program B known about the lock, it
   would not have overwritten the resource, preferring instead to
   present a dialog box describing the conflict to the user.  Due to
   this scenario, a mechanism is needed to prevent different programs
   from accidentally ignoring locks taken out by other programs with the
   same authorization.

   In order to prevent these collisions a lock token MUST be submitted
   by an authorized principal in the If header for all locked resources
   that a method may interact with or the method MUST fail.  For
   example, if a resource is to be moved and both the source and
   destination are locked then two lock tokens must be submitted, one
   for the source and the other for the destination.

7.6.1 Example - Write Lock

   >>Request

   COPY /~fielding/index.html HTTP/1.1
   Host: www.ics.uci.edu
   Destination: http://www.ics.uci.edu/users/f/fielding/index.html
   If: <http://www.ics.uci.edu/users/f/fielding/index.html>
       (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)

   >>Response

   HTTP/1.1 204 No Content

   In this example, even though both the source and destination are
   locked, only one lock token must be submitted, for the lock on the
   destination.  This is because the source resource is not modified by
   a COPY, and hence unaffected by the write lock. In this example, user
   agent authentication has previously occurred via a mechanism outside
   the scope of the HTTP protocol, in the underlying transport layer.



Goland, et al.              Standards Track                    [Page 22]

RFC 2518                         WEBDAV                    February 1999


7.7 Write Locks and COPY/MOVE

   A COPY method invocation MUST NOT duplicate any write locks active on
   the source.  However, as previously noted, if the COPY copies the
   resource into a collection that is locked with "Depth: infinity",
   then the resource will be added to the lock.

   A successful MOVE request on a write locked resource MUST NOT move
   the write lock with the resource. However, the resource is subject to
   being added to an existing lock at the destination, as specified in
   section 7.5. For example, if the MOVE makes the resource a child of a
   collection that is locked with "Depth: infinity", then the resource
   will be added to that collection's lock. Additionally, if a resource
   locked with "Depth: infinity" is moved to a destination that is
   within the scope of the same lock (e.g., within the namespace tree
   covered by the lock), the moved resource will again be a added to the
   lock. In both these examples, as specified in section 7.6, an If
   header must be submitted containing a lock token for both the source
   and destination.

7.8 Refreshing Write Locks

   A client MUST NOT submit the same write lock request twice.  Note
   that a client is always aware it is resubmitting the same lock
   request because it must include the lock token in the If header in
   order to make the request for a resource that is already locked.

   However, a client may submit a LOCK method with an If header but
   without a body.  This form of LOCK MUST only be used to "refresh" a
   lock.  Meaning, at minimum, that any timers associated with the lock
   MUST be re-set.

   A server may return a Timeout header with a lock refresh that is
   different than the Timeout header returned when the lock was
   originally requested.  Additionally clients may submit Timeout
   headers of arbitrary value with their lock refresh requests.
   Servers, as always, may ignore Timeout headers submitted by the
   client.

   If an error is received in response to a refresh LOCK request the
   client SHOULD assume that the lock was not refreshed.

8  HTTP Methods for Distributed Authoring

   The following new HTTP methods use XML as a request and response
   format.  All DAV compliant clients and resources MUST use XML parsers
   that are compliant with [REC-XML].  All XML used in either requests
   or responses MUST be, at minimum, well formed.  If a server receives



Goland, et al.              Standards Track                    [Page 23]

RFC 2518                         WEBDAV                    February 1999


   ill-formed XML in a request it MUST reject the entire request with a
   400 (Bad Request).  If a client receives ill-formed XML in a response
   then it MUST NOT assume anything about the outcome of the executed
   method and SHOULD treat the server as malfunctioning.

8.1 PROPFIND

   The PROPFIND method retrieves properties defined on the resource
   identified by the Request-URI, if the resource does not have any
   internal members, or on the resource identified by the Request-URI
   and potentially its member resources, if the resource is a collection
   that has internal member URIs.  All DAV compliant resources MUST
   support the PROPFIND method and the propfind XML element (section
   12.14) along with all XML elements defined for use with that element.

   A client may submit a Depth header with a value of "0", "1", or
   "infinity" with a PROPFIND on a collection resource with internal
   member URIs.  DAV compliant servers MUST support the "0", "1" and
   "infinity" behaviors. By default, the PROPFIND method without a Depth
   header MUST act as if a "Depth: infinity" header was included.

   A client may submit a propfind XML element in the body of the request
   method describing what information is being requested.  It is
   possible to request particular property values, all property values,
   or a list of the names of the resource's properties.  A client may
   choose not to submit a request body.  An empty PROPFIND request body
   MUST be treated as a request for the names and values of all
   properties.

   All servers MUST support returning a response of content type
   text/xml or application/xml that contains a multistatus XML element
   that describes the results of the attempts to retrieve the various
   properties.

   If there is an error retrieving a property then a proper error result
   MUST be included in the response.  A request to retrieve the value of
   a property which does not exist is an error and MUST be noted, if the
   response uses a multistatus XML element, with a response XML element
   which contains a 404 (Not Found) status value.

   Consequently, the multistatus XML element for a collection resource