rfc3253.txt

RFC 的详细文档！

Clemm, et al.               Standards Track                    [Page 21]

RFC 3253            Versioning Extensions to WebDAV           March 2002


3.2.2 DAV:auto-version

   If the DAV:auto-version value is DAV:checkout-checkin, when a
   modification request (such as PUT/PROPPATCH) is applied to a
   checked-in version-controlled resource, the request is automatically
   preceded by a checkout and followed by a checkin operation.

   If the DAV:auto-version value is DAV:checkout-unlocked-checkin, when
   a modification request is applied to a checked-in version-controlled
   resource, the request is automatically preceded by a checkout
   operation.  If the resource is not write-locked, the request is
   automatically followed by a checkin operation.

   If the DAV:auto-version value is DAV:checkout, when a modification
   request is applied to a checked-in version-controlled resource, the
   request is automatically preceded by a checkout operation.

   If the DAV:auto-version value is DAV:locked-checkout, when a
   modification request is applied to a write-locked checked-in
   version-controlled resource, the request is automatically preceded by
   a checkout operation.

   If an update to a write-locked checked-in resource is automatically
   preceded by a checkout of that resource, the checkout is associated
   with the write lock.  When this write lock is removed (e.g. from an
   UNLOCK or a lock timeout), if the resource has not yet been checked
   in, the removal of the write lock is automatically preceded by a
   checkin operation.

   A server MAY refuse to allow the value of the DAV:auto-version
   property to be modified, or MAY only support values from a subset of
   the valid values.

   <!ELEMENT auto-version (checkout-checkin | checkout-unlocked-checkin
     | checkout | locked-checkout)? >
   <!ELEMENT checkout-checkin EMPTY>
   <!ELEMENT checkout-unlocked-checkin EMPTY>
   <!ELEMENT checkout EMPTY>
   <!ELEMENT locked-checkout EMPTY>

3.3 Checked-Out Resource Properties

   The version-control feature introduces the following REQUIRED
   properties for a checked-out resource.







Clemm, et al.               Standards Track                    [Page 22]

RFC 3253            Versioning Extensions to WebDAV           March 2002


3.3.1 DAV:checked-out (protected)

   This property identifies the version that was identified by the
   DAV:checked-in property at the time the resource was checked out.
   This property is removed when the resource is checked in.

   <!ELEMENT checked-out (href)>

3.3.2 DAV:predecessor-set

   This property determines the DAV:predecessor-set property of the
   version that results from checking in this resource.

   A server MAY reject attempts to modify the DAV:predecessor-set of a
   version-controlled resource.

   <!ELEMENT predecessor-set (href+)>

3.4 Version Properties

   The version-control feature introduces the following REQUIRED
   properties for a version.

3.4.1 DAV:predecessor-set (protected)

   This property identifies each predecessor of this version.  Except
   for the root version, which has no predecessors, each version has at
   least one predecessor.

   <!ELEMENT predecessor-set (href*)>

3.4.2 DAV:successor-set (computed)

   This property identifies each version whose DAV:predecessor-set
   identifies this version.

   <!ELEMENT successor-set (href*)>

3.4.3 DAV:checkout-set (computed)

   This property identifies each checked-out resource whose
   DAV:checked-out property identifies this version.

   <!ELEMENT checkout-set (href*)>







Clemm, et al.               Standards Track                    [Page 23]

RFC 3253            Versioning Extensions to WebDAV           March 2002


3.4.4 DAV:version-name (protected)

   This property contains a server-defined string that is different for
   each version in a given version history.  This string is intended for
   display for a user, unlike the URL of a version, which is normally
   only used by a client and not displayed for a user.

   <!ELEMENT version-name (#PCDATA)>
   PCDATA value: string

3.5 VERSION-CONTROL Method

   A VERSION-CONTROL request can be used to create a version-controlled
   resource at the request-URL.  It can be applied to a versionable
   resource or to a version-controlled resource.

   If the request-URL identifies a versionable resource, a new version
   history resource is created, a new version is created whose content
   and dead properties are copied from the versionable resource, and the
   resource is given a DAV:checked-in property that is initialized to
   identify this new version.

   If the request-URL identifies a version-controlled resource, the
   resource just remains under version-control.  This allows a client to
   be unaware of whether or not a server automatically puts a resource
   under version control when it is created.

   If a VERSION-CONTROL request fails, the server state preceding the
   request MUST be restored.

   Marshalling:

      If a request body is included, it MUST be a DAV:version-control
      XML element.

      <!ELEMENT version-control ANY>

      If a response body for a successful request is included, it MUST
      be a DAV:version-control-response XML element.  Note that this
      document does not define any elements for the VERSION-CONTROL
      response body, but the DAV:version-control-response element is
      defined to ensure interoperability between future extensions that
      do define elements for the VERSION-CONTROL response body.

      <!ELEMENT version-control-response ANY>






Clemm, et al.               Standards Track                    [Page 24]

RFC 3253            Versioning Extensions to WebDAV           March 2002


   Postconditions:

      (DAV:put-under-version-control): If the request-URL identified a
      versionable resource at the time of the request, the request MUST
      have created a new version history and MUST have created a new
      version resource in that version history.  The resource MUST have
      a DAV:checked-in property that identifies the new version.  The
      content, dead properties, and DAV:resourcetype of the new version
      MUST be the same as those of the resource.  Note that an
      implementation can choose to locate the version history and
      version resources anywhere that it wishes.  In particular, it
      could locate them on the same host and server as the version-
      controlled resource, on a different virtual host maintained by the
      same server, on the same host maintained by a different server, or
      on a different host maintained by a different server.

      (DAV:must-not-change-existing-checked-in-out): If the request-URL
      identified a resource already under version control at the time of
      the request, the request MUST NOT change the DAV:checked-in or
      DAV:checked-out property of that version-controlled resource.

3.5.1 Example - VERSION-CONTROL

   >>REQUEST

     VERSION-CONTROL /foo.html HTTP/1.1
     Host: www.webdav.org
     Content-Length: 0

   >>RESPONSE

     HTTP/1.1 200 OK

   In this example, /foo.html is put under version control.  A new
   version history is created for it, and a new version is created that
   has a copy of the content and dead properties of /foo.html.  The
   DAV:checked-in property of /foo.html identifies this new version.

3.6 REPORT Method

   A REPORT request is an extensible mechanism for obtaining information
   about a resource.  Unlike a resource property, which has a single
   value, the value of a report can depend on additional information
   specified in the REPORT request body and in the REPORT request
   headers.






Clemm, et al.               Standards Track                    [Page 25]

RFC 3253            Versioning Extensions to WebDAV           March 2002


   Marshalling:

      The body of a REPORT request specifies which report is being
      requested, as well as any additional information that will be used
      to customize the report.

      The request MAY include a Depth header.  If no Depth header is
      included, Depth:0 is assumed.

      The response body for a successful request MUST contain the
      requested report.

      If a Depth request header is included, the response MUST be a 207
      Multi-Status.  The request MUST be applied separately to the
      collection itself and to all members of the collection that
      satisfy the Depth value.  The DAV:prop element of a DAV:response
      for a given resource MUST contain the requested report for that
      resource.

   Preconditions:

      (DAV:supported-report): The specified report MUST be supported by
      the resource identified by the request-URL.

   Postconditions:

      (DAV:no-modification): The REPORT method MUST NOT have changed the
      content or dead properties of any resource.

3.7 DAV:version-tree Report

   The DAV:version-tree report describes the requested properties of all
   the versions in the version history of a version.  If the report is
   requested for a version-controlled resource, it is redirected to its
   DAV:checked-in or DAV:checked-out version.

   The DAV:version-tree report MUST be supported by all version
   resources and all version-controlled resources.

   Marshalling:

      The request body MUST be a DAV:version-tree XML element.

      <!ELEMENT version-tree ANY>
      ANY value: a sequence of zero or more elements, with at most one
      DAV:prop element.
      prop: see RFC 2518, Section 12.11




Clemm, et al.               Standards Track                    [Page 26]

RFC 3253            Versioning Extensions to WebDAV           March 2002


      The response body for a successful request MUST be a
      DAV:multistatus XML element.

      multistatus: see RFC 2518, Section 12.9

      The response body for a successful DAV:version-tree REPORT request
      MUST contain a DAV:response eleme