Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

in Index   Prev   Next  

RFC 2518

HTTP Extensions for Distributed Authoring -- WEBDAV

Pages: 94
Group: IDR

Obsoleted by:  4918
Part 3 of 4 – Pages 52 to 75
First   Prev   Next

ToP   noToC   RFC2518 - Page 52   prevText
9  HTTP Headers for Distributed Authoring

9.1 DAV Header

   DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]

   This header indicates that the resource supports the DAV schema and
   protocol as specified. All DAV compliant resources MUST return the
   DAV header on all OPTIONS responses.

   The value is a list of all compliance classes that the resource
   supports.  Note that above a comma has already been added to the 2.
   This is because a resource can not be level 2 compliant unless it is
   also level 1 compliant. Please refer to section 15 for more details.
   In general, however, support for one compliance class does not entail
   support for any other.

9.2 Depth Header

   Depth = "Depth" ":" ("0" | "1" | "infinity")
ToP   noToC   RFC2518 - Page 53
   The Depth header is used with methods executed on resources which
   could potentially have internal members to indicate whether the
   method is to be applied only to the resource ("Depth: 0"), to the
   resource and its immediate children, ("Depth: 1"), or the resource
   and all its progeny ("Depth: infinity").

   The Depth header is only supported if a method's definition
   explicitly provides for such support.

   The following rules are the default behavior for any method that
   supports the Depth header. A method may override these defaults by
   defining different behavior in its definition.

   Methods which support the Depth header may choose not to support all
   of the header's values and may define, on a case by case basis, the
   behavior of the method if a Depth header is not present. For example,
   the MOVE method only supports "Depth: infinity" and if a Depth header
   is not present will act as if a "Depth: infinity" header had been

   Clients MUST NOT rely upon methods executing on members of their
   hierarchies in any particular order or on the execution being atomic
   unless the particular method explicitly provides such guarantees.

   Upon execution, a method with a Depth header will perform as much of
   its assigned task as possible and then return a response specifying
   what it was able to accomplish and what it failed to do.

   So, for example, an attempt to COPY a hierarchy may result in some of
   the members being copied and some not.

   Any headers on a method that has a defined interaction with the Depth
   header MUST be applied to all resources in the scope of the method
   except where alternative behavior is explicitly defined. For example,
   an If-Match header will have its value applied against every resource
   in the method's scope and will cause the method to fail if the header
   fails to match.

   If a resource, source or destination, within the scope of the method
   with a Depth header is locked in such a way as to prevent the
   successful execution of the method, then the lock token for that
   resource MUST be submitted with the request in the If request header.

   The Depth header only specifies the behavior of the method with
   regards to internal children.  If a resource does not have internal
   children then the Depth header MUST be ignored.
ToP   noToC   RFC2518 - Page 54
   Please note, however, that it is always an error to submit a value
   for the Depth header that is not allowed by the method's definition.
   Thus submitting a "Depth: 1" on a COPY, even if the resource does not
   have internal members, will result in a 400 (Bad Request). The method
   should fail not because the resource doesn't have internal members,
   but because of the illegal value in the header.

9.3 Destination Header

   Destination = "Destination" ":" absoluteURI

   The Destination header specifies the URI which identifies a
   destination resource for methods such as COPY and MOVE, which take
   two URIs as parameters.  Note that the absoluteURI production is
   defined in [RFC2396].

9.4 If Header

   If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
   No-tag-list = List
   Tagged-list = Resource 1*List
   Resource = Coded-URL
   List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
   State-token = Coded-URL
   Coded-URL = "<" absoluteURI ">"

   The If header is intended to have similar functionality to the If-
   Match header defined in section 14.25 of [RFC2068].  However the If
   header is intended for use with any URI which represents state
   information, referred to as a state token, about a resource as well
   as ETags.  A typical example of a state token is a lock token, and
   lock tokens are the only state tokens defined in this specification.

   All DAV compliant resources MUST honor the If header.

   The If header's purpose is to describe a series of state lists.  If
   the state of the resource to which the header is applied does not
   match any of the specified state lists then the request MUST fail
   with a 412 (Precondition Failed).  If one of the described state
   lists matches the state of the resource then the request may succeed.

   Note that the absoluteURI production is defined in [RFC2396].
ToP   noToC   RFC2518 - Page 55
9.4.1 No-tag-list Production

   The No-tag-list production describes a series of state tokens and
   ETags.  If multiple No-tag-list productions are used then one only
   needs to match the state of the resource for the method to be allowed
   to continue.

   If a method, due to the presence of a Depth or Destination header, is
   applied to multiple resources then the No-tag-list production MUST be
   applied to each resource the method is applied to. Example - No-tag-list If Header

   If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another

   The previous header would require that any resources within the scope
   of the method must either be locked with the specified lock token and
   in the state identified by the "I am an ETag" ETag or in the state
   identified by the second ETag "I am another ETag".  To put the matter
   more plainly one can think of the previous If header as being in the
   form (or (and <locktoken:a-write-lock-token> ["I am an ETag"]) (and
   ["I am another ETag"])).

9.4.2 Tagged-list Production

   The tagged-list production scopes a list production.  That is, it
   specifies that the lists following the resource specification only
   apply to the specified resource.  The scope of the resource
   production begins with the list production immediately following the
   resource production and ends with the next resource production, if

   When the If header is applied to a particular resource, the Tagged-
   list productions MUST be searched to determine if any of the listed
   resources match the operand resource(s) for the current method.  If
   none of the resource productions match the current resource then the
   header MUST be ignored.  If one of the resource productions does
   match the name of the resource under consideration then the list
   productions following the resource production MUST be applied to the
   resource in the manner specified in the previous section.

   The same URI MUST NOT appear more than once in a resource production
   in an If header.
ToP   noToC   RFC2518 - Page 56 Example - Tagged List If header

   COPY /resource1 HTTP/1.1
   If: <> (<locktoken:a-write-lock-token>
   [W/"A weak ETag"]) (["strong ETag"])
   <>(["another strong ETag"])

   In this example is being copied to  When the method is first applied to, resource1 must be in the state
   specified by "(<locktoken:a-write-lock-token> [W/"A weak ETag"])
   (["strong ETag"])", that is, it either must be locked with a lock
   token of "locktoken:a-write-lock-token" and have a weak entity tag
   W/"A weak ETag" or it must have a strong entity tag "strong ETag".

   That is the only success condition since the resource never has the method applied to it (the
   only other resource listed in the If header) and is not listed in the If header.

9.4.3 not Production

   Every state token or ETag is either current, and hence describes the
   state of a resource, or is not current, and does not describe the
   state of a resource. The boolean operation of matching a state token
   or ETag to the current state of a resource thus resolves to a true or
   false value.  The not production is used to reverse that value.  The
   scope of the not production is the state-token or entity-tag
   immediately following it.

   If: (Not <locktoken:write1> <locktoken:write2>)

   When submitted with a request, this If header requires that all
   operand resources must not be locked with locktoken:write1 and must
   be locked with locktoken:write2.

9.4.4 Matching Function

   When performing If header processing, the definition of a matching
   state token or entity tag is as follows.

   Matching entity tag: Where the entity tag matches an entity tag
   associated with that resource.

   Matching state token: Where there is an exact match between the state
   token in the If header and any state token on the resource.
ToP   noToC   RFC2518 - Page 57
9.4.5 If Header and Non-DAV Compliant Proxies

   Non-DAV compliant proxies will not honor the If header, since they
   will not understand the If header, and HTTP requires non-understood
   headers to be ignored.  When communicating with HTTP/1.1 proxies, the
   "Cache-Control: no-cache" request header MUST be used so as to
   prevent the proxy from improperly trying to service the request from
   its cache.  When dealing with HTTP/1.0 proxies the "Pragma: no-cache"
   request header MUST be used for the same reason.

9.5 Lock-Token Header

   Lock-Token = "Lock-Token" ":" Coded-URL

   The Lock-Token request header is used with the UNLOCK method to
   identify the lock to be removed.  The lock token in the Lock-Token
   request header MUST identify a lock that contains the resource
   identified by Request-URI as a member.

   The Lock-Token response header is used with the LOCK method to
   indicate the lock token created as a result of a successful LOCK
   request to create a new lock.

9.6 Overwrite Header

   Overwrite = "Overwrite" ":" ("T" | "F")

   The Overwrite header specifies whether the server should overwrite
   the state of a non-null destination resource during a COPY or MOVE.
   A value of "F" states that the server must not perform the COPY or
   MOVE operation if the state of the destination resource is non-null.
   If the overwrite header is not included in a COPY or MOVE request
   then the resource MUST treat the request as if it has an overwrite
   header of value "T". While the Overwrite header appears to duplicate
   the functionality of the If-Match: * header of HTTP/1.1, If-Match
   applies only to the Request-URI, and not to the Destination of a COPY
   or MOVE.

   If a COPY or MOVE is not performed due to the value of the Overwrite
   header, the method MUST fail with a 412 (Precondition Failed) status

   All DAV compliant resources MUST support the Overwrite header.

9.7 Status-URI Response Header

   The Status-URI response header may be used with the 102 (Processing)
   status code to inform the client as to the status of a method.
ToP   noToC   RFC2518 - Page 58
   Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code
   is defined in 6.1.1 of [RFC2068]

   The URIs listed in the header are source resources which have been
   affected by the outstanding method.  The status code indicates the
   resolution of the method on the identified resource.  So, for
   example, if a MOVE method on a collection is outstanding and a 102
   (Processing) response with a Status-URI response header is returned,
   the included URIs will indicate resources that have had move
   attempted on them and what the result was.

9.8 Timeout Request Header

   TimeOut = "Timeout" ":" 1#TimeType
   TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
   DAVTimeOutVal = 1*digit
   Other = "Extend" field-value   ; See section 4.2 of [RFC2068]

   Clients may include Timeout headers in their LOCK requests.  However,
   the server is not required to honor or even consider these requests.
   Clients MUST NOT submit a Timeout request header with any method
   other than a LOCK method.

   A Timeout request header MUST contain at least one TimeType and may
   contain multiple TimeType entries. The purpose of listing multiple
   TimeType entries is to indicate multiple different values and value
   types that are acceptable to the client.  The client lists the
   TimeType entries in order of preference.

   Timeout response values MUST use a Second value, Infinite, or a
   TimeType the client has indicated familiarity with.  The server may
   assume a client is familiar with any TimeType submitted in a Timeout

   The "Second" TimeType specifies the number of seconds that will
   elapse between granting of the lock at the server, and the automatic
   removal of the lock.  The timeout value for TimeType "Second" MUST
   NOT be greater than 2^32-1.

   The timeout counter SHOULD be restarted any time an owner of the lock
   sends a method to any member of the lock, including unsupported
   methods, or methods which are unsuccessful.  However the lock MUST be
   refreshed if a refresh LOCK method is successfully received.

   If the timeout expires then the lock may be lost.  Specifically, if
   the server wishes to harvest the lock upon time-out, the server
   SHOULD act as if an UNLOCK method was executed by the server on the
   resource using the lock token of the timed-out lock, performed with
ToP   noToC   RFC2518 - Page 59
   its override authority. Thus logs should be updated with the
   disposition of the lock, notifications should be sent, etc., just as
   they would be for an UNLOCK request.

   Servers are advised to pay close attention to the values submitted by
   clients, as they will be indicative of the type of activity the
   client intends to perform.  For example, an applet running in a
   browser may need to lock a resource, but because of the instability
   of the environment within which the applet is running, the applet may
   be turned off without warning.  As a result, the applet is likely to
   ask for a relatively small timeout value so that if the applet dies,
   the lock can be quickly harvested.  However, a document management
   system is likely to ask for an extremely long timeout because its
   user may be planning on going off-line.

   A client MUST NOT assume that just because the time-out has expired
   the lock has been lost.

10 Status Code Extensions to HTTP/1.1

   The following status codes are added to those defined in HTTP/1.1

10.1 102 Processing

   The 102 (Processing) status code is an interim response used to
   inform the client that the server has accepted the complete request,
   but has not yet completed it.  This status code SHOULD only be sent
   when the server has a reasonable expectation that the request will
   take significant time to complete. As guidance, if a method is taking
   longer than 20 seconds (a reasonable, but arbitrary value) to process
   the server SHOULD return a 102 (Processing) response. The server MUST
   send a final response after the request has been completed.

   Methods can potentially take a long period of time to process,
   especially methods that support the Depth header.  In such cases the
   client may time-out the connection while waiting for a response.  To
   prevent this the server may return a 102 (Processing) status code to
   indicate to the client that the server is still processing the

10.2 207 Multi-Status

   The 207 (Multi-Status) status code provides status for multiple
   independent operations (see section 11 for more information).
ToP   noToC   RFC2518 - Page 60
10.3 422 Unprocessable Entity

   The 422 (Unprocessable Entity) status code means the server
   understands the content type of the request entity (hence a
   415(Unsupported Media Type) status code is inappropriate), and the
   syntax of the request entity is correct (thus a 400 (Bad Request)
   status code is inappropriate) but was unable to process the contained
   instructions.  For example, this error condition may occur if an XML
   request body contains well-formed (i.e., syntactically correct), but
   semantically erroneous XML instructions.

10.4 423 Locked

   The 423 (Locked) status code means the source or destination resource
   of a method is locked.

10.5 424 Failed Dependency

   The 424 (Failed Dependency) status code means that the method could
   not be performed on the resource because the requested action
   depended on another action and that action failed.  For example, if a
   command in a PROPPATCH method fails then, at minimum, the rest of the
   commands will also fail with 424 (Failed Dependency).

10.6 507 Insufficient Storage

   The 507 (Insufficient Storage) status code means the method could not
   be performed on the resource because the server is unable to store
   the representation needed to successfully complete the request.  This
   condition is considered to be temporary.  If the request which
   received this status code was the result of a user action, the
   request MUST NOT be repeated until it is requested by a separate user

11 Multi-Status Response

   The default 207 (Multi-Status) response body is a text/xml or
   application/xml HTTP entity that contains a single XML element called
   multistatus, which contains a set of XML elements called response
   which contain 200, 300, 400, and 500 series status codes generated
   during the method invocation.  100 series status codes SHOULD NOT be
   recorded in a response XML element.
ToP   noToC   RFC2518 - Page 61
12 XML Element Definitions

   In the section below, the final line of each section gives the
   element type declaration using the format defined in [REC-XML]. The
   "Value" field, where present, specifies further restrictions on the
   allowable contents of the XML element using BNF (i.e., to further
   restrict the values of a PCDATA element).

12.1 activelock XML Element

   Name:       activelock
   Namespace:  DAV:
   Purpose:    Describes a lock on a resource.

   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
   locktoken?) >

12.1.1 depth XML Element

   Name:       depth
   Namespace:  DAV:
   Purpose:    The value of the Depth header.
   Value:      "0" | "1" | "infinity"

   <!ELEMENT depth (#PCDATA) >

12.1.2 locktoken XML Element

   Name:       locktoken
   Namespace:  DAV:
   Purpose:    The lock token associated with a lock.
   Description: The href contains one or more opaque lock token URIs
   which all refer to the same lock (i.e., the OpaqueLockToken-URI
   production in section 6.4).

   <!ELEMENT locktoken (href+) >

12.1.3 timeout XML Element

   Name:       timeout
   Namespace:  DAV:
   Purpose:    The timeout associated with a lock
   Value:      TimeType ;Defined in section 9.8

   <!ELEMENT timeout (#PCDATA) >
ToP   noToC   RFC2518 - Page 62
12.2 collection XML Element

   Name:       collection
   Namespace:  DAV:
   Purpose:    Identifies the associated resource as a collection. The
   resourcetype property of a collection resource MUST have this value.

   <!ELEMENT collection EMPTY >

12.3 href XML Element

   Name:       href
   Namespace:  DAV:
   Purpose:    Identifies the content of the element as a URI.
   Value:      URI ; See section 3.2.1 of [RFC2068]

   <!ELEMENT href (#PCDATA)>

12.4 link XML Element

   Name:       link
   Namespace:  DAV:
   Purpose:    Identifies the property as a link and contains the source
   and destination of that link.
   Description: The link XML element is used to provide the sources and
   destinations of a link.  The name of the property containing the link
   XML element provides the type of the link.  Link is a multi-valued
   element, so multiple links may be used together to indicate multiple
   links with the same type.  The values in the href XML elements inside
   the src and dst XML elements of the link XML element MUST NOT be
   rejected if they point to resources which do not exist.

   <!ELEMENT link (src+, dst+) >

12.4.1 dst XML Element

   Name:       dst
   Namespace:  DAV:
   Purpose:    Indicates the destination of a link
   Value:      URI

   <!ELEMENT dst (#PCDATA) >

12.4.2 src XML Element

   Name:       src
   Namespace:  DAV:
   Purpose:    Indicates the source of a link.
ToP   noToC   RFC2518 - Page 63
   Value:      URI

   <!ELEMENT src (#PCDATA) >

12.5 lockentry XML Element

   Name:       lockentry
   Namespace:  DAV:
   Purpose:    Defines the types of locks that can be used with the

   <!ELEMENT lockentry (lockscope, locktype) >

12.6 lockinfo XML Element

   Name:       lockinfo
   Namespace:  DAV:
   Purpose:    The lockinfo XML element is used with a LOCK method to
   specify the type of lock the client wishes to have created.

   <!ELEMENT lockinfo (lockscope, locktype, owner?) >

12.7 lockscope XML Element

   Name:       lockscope
   Namespace:  DAV:
   Purpose:    Specifies whether a lock is an exclusive lock, or a
   shared lock.

   <!ELEMENT lockscope (exclusive | shared) >

12.7.1 exclusive XML Element

   Name:       exclusive
   Namespace:  DAV:
   Purpose:    Specifies an exclusive lock

   <!ELEMENT exclusive EMPTY >

12.7.2 shared XML Element

   Name:       shared
   Namespace:  DAV:
   Purpose:    Specifies a shared lock

   <!ELEMENT shared EMPTY >
ToP   noToC   RFC2518 - Page 64
12.8 locktype XML Element

   Name:       locktype
   Namespace:  DAV:
   Purpose:    Specifies the access type of a lock.  At present, this
   specification only defines one lock type, the write lock.

   <!ELEMENT locktype (write) >

12.8.1 write XML Element

   Name:       write
   Namespace:  DAV:
   Purpose:    Specifies a write lock.

   <!ELEMENT write EMPTY >

12.9 multistatus XML Element

   Name:       multistatus
   Namespace:  DAV:
   Purpose:    Contains multiple response messages.
   Description: The responsedescription at the top level is used to
   provide a general message describing the overarching nature of the
   response.  If this value is available an application may use it
   instead of presenting the individual response descriptions contained
   within the responses.

   <!ELEMENT multistatus (response+, responsedescription?) >

12.9.1 response XML Element

   Name:       response
   Namespace:  DAV:
   Purpose:    Holds a single response describing the effect of a
   method on resource and/or its properties.
   Description: A particular href MUST NOT appear more than once as the
   child of a response XML element under a multistatus XML element.
   This requirement is necessary in order to keep processing costs for a
   response to linear time.  Essentially, this prevents having to search
   in order to group together all the responses by href.  There are,
   however, no requirements regarding ordering based on href values.

   <!ELEMENT response (href, ((href*, status)|(propstat+)),
   responsedescription?) >
ToP   noToC   RFC2518 - Page 65  propstat XML Element

   Name:       propstat
   Namespace:  DAV:
   Purpose:    Groups together a prop and status element that is
   associated with a particular href element.
   Description: The propstat XML element MUST contain one prop XML
   element and one status XML element.  The contents of the prop XML
   element MUST only list the names of properties to which the result in
   the status element applies.

   <!ELEMENT propstat (prop, status, responsedescription?) >  status XML Element

   Name:       status
   Namespace:  DAV:
   Purpose:    Holds a single HTTP status-line
   Value:      status-line   ;status-line defined in [RFC2068]

   <!ELEMENT status (#PCDATA) >

12.9.2 responsedescription XML Element

   Name:       responsedescription
   Namespace:  DAV:
   Purpose:    Contains a message that can be displayed to the user
   explaining the nature of the response.
   Description: This XML element provides information suitable to be
   presented to a user.

   <!ELEMENT responsedescription (#PCDATA) >

12.10 owner XML Element

   Name:       owner
   Namespace:  DAV:
   Purpose:    Provides information about the principal taking out a
   Description: The owner XML element provides information sufficient
   for either directly contacting a principal (such as a telephone
   number or Email URI), or for discovering the principal (such as the
   URL of a homepage) who owns a lock.

   <!ELEMENT owner ANY>
ToP   noToC   RFC2518 - Page 66
12.11 prop XML element

   Name:       prop
   Namespace:  DAV:
   Purpose:    Contains properties related to a resource.
   Description: The prop XML element is a generic container for
   properties defined on resources.  All elements inside a prop XML
   element MUST define properties related to the resource.  No other
   elements may be used inside of a prop element.

   <!ELEMENT prop ANY>

12.12 propertybehavior XML element

   Name:       propertybehavior Namespace:  DAV:  Purpose:    Specifies
   how properties are handled during a COPY or MOVE.
   Description: The propertybehavior XML element specifies how
   properties are handled during a COPY or MOVE.  If this XML element is
   not included in the request body then the server is expected to act
   as defined by the default property handling behavior of the
   associated method.  All WebDAV compliant resources MUST support the
   propertybehavior XML element.

   <!ELEMENT propertybehavior (omit | keepalive) >

12.12.1 keepalive XML element

   Name:       keepalive
   Namespace:  DAV:
   Purpose:    Specifies requirements for the copying/moving of live
   Description: If a list of URIs is included as the value of keepalive
   then the named properties MUST be "live" after they are copied
   (moved) to the destination resource of a COPY (or MOVE).  If the
   value "*" is given for the keepalive XML element, this designates
   that all live properties on the source resource MUST be live on the
   destination.  If the requirements specified by the keepalive element
   can not be honored then the method MUST fail with a 412 (Precondition
   Failed).  All DAV compliant resources MUST support the keepalive XML
   element for use with the COPY and MOVE methods.
   Value:      "*" ; #PCDATA value can only be "*"

   <!ELEMENT keepalive (#PCDATA | href+) >
ToP   noToC   RFC2518 - Page 67
12.12.2 omit XML element

   Name:       omit
   Namespace:  DAV:
   Purpose:    The omit XML element instructs the server that it should
   use best effort to copy properties but a failure to copy a property
   MUST NOT cause the method to fail.  Description: The default behavior
   for a COPY or MOVE is to copy/move all properties or fail the method.
   In certain circumstances, such as when a server copies a resource
   over another protocol such as FTP, it may not be possible to
   copy/move the properties associated with the resource. Thus any
   attempt to copy/move over FTP would always have to fail because
   properties could not be moved over, even as dead properties.  All DAV
   compliant resources MUST support the omit XML element on COPY/MOVE

   <!ELEMENT omit EMPTY >

12.13 propertyupdate XML element

   Name:       propertyupdate
   Namespace:  DAV:
   Purpose:    Contains a request to alter the properties on a
   Description: This XML element is a container for the information
   required to modify the properties on the resource.  This XML element
   is multi-valued.

   <!ELEMENT propertyupdate (remove | set)+ >

12.13.1 remove XML element

   Name:       remove
   Namespace:  DAV:
   Purpose:    Lists the DAV properties to be removed from a resource.
   Description: Remove instructs that the properties specified in prop
   should be removed.  Specifying the removal of a property that does
   not exist is not an error.  All the XML elements in a prop XML
   element inside of a remove XML element MUST be empty, as only the
   names of properties to be removed are required.

   <!ELEMENT remove (prop) >

12.13.2 set XML element

   Name:       set
   Namespace:  DAV:
   Purpose:    Lists the DAV property values to be set for a resource.
ToP   noToC   RFC2518 - Page 68
   Description: The set XML element MUST contain only a prop XML
   element.  The elements contained by the prop XML element inside the
   set XML element MUST specify the name and value of properties that
   are set on the resource identified by Request-URI.  If a property
   already exists then its value is replaced. Language tagging
   information in the property's value (in the "xml:lang" attribute, if
   present) MUST be persistently stored along with the property, and
   MUST be subsequently retrievable using PROPFIND.

   <!ELEMENT set (prop) >

12.14 propfind XML Element

   Name:       propfind
   Namespace:  DAV:
   Purpose:    Specifies the properties to be returned from a PROPFIND
   method.  Two special elements are specified for use with propfind,
   allprop and propname.  If prop is used inside propfind it MUST only
   contain property names, not values.

   <!ELEMENT propfind (allprop | propname | prop) >

12.14.1 allprop XML Element

   Name:       allprop Namespace:  DAV:  Purpose:    The allprop XML
   element specifies that all property names and values on the resource
   are to be returned.

   <!ELEMENT allprop EMPTY >

12.14.2 propname XML Element

   Name:       propname Namespace:  DAV:  Purpose:    The propname XML
   element specifies that only a list of property names on the resource
   is to be returned.

   <!ELEMENT propname EMPTY >

13 DAV Properties

   For DAV properties, the name of the property is also the same as the
   name of the XML element that contains its value. In the section
   below, the final line of each section gives the element type
   declaration using the format defined in [REC-XML]. The "Value" field,
   where present, specifies further restrictions on the allowable
   contents of the XML element using BNF (i.e., to further restrict the
   values of a PCDATA element).
ToP   noToC   RFC2518 - Page 69
13.1 creationdate Property

   Name:       creationdate
   Namespace:  DAV:
   Purpose:    Records the time and date the resource was created.
   Value:      date-time ; See Appendix 2
   Description: The creationdate property should be defined on all DAV
   compliant resources.  If present, it contains a timestamp of the
   moment when the resource was created (i.e., the moment it had non-
   null state).

   <!ELEMENT creationdate (#PCDATA) >

13.2 displayname Property

   Name:       displayname
   Namespace:  DAV:
   Purpose:    Provides a name for the resource that is suitable for
   presentation to a user.
   Description: The displayname property should be defined on all DAV
   compliant resources.  If present, the property contains a description
   of the resource that is suitable for presentation to a user.

   <!ELEMENT displayname (#PCDATA) >

13.3 getcontentlanguage Property

   Name:       getcontentlanguage
   Namespace:  DAV:
   Purpose:    Contains the Content-Language header returned by a GET
   without accept headers
   Description: The getcontentlanguage property MUST be defined on any
   DAV compliant resource that returns the Content-Language header on a
   Value:      language-tag   ;language-tag is defined in section 14.13
   of [RFC2068]

   <!ELEMENT getcontentlanguage (#PCDATA) >

13.4 getcontentlength Property

   Name:       getcontentlength
   Namespace:  DAV:
   Purpose:    Contains the Content-Length header returned by a GET
   without accept headers.
   Description: The getcontentlength property MUST be defined on any
   DAV compliant resource that returns the Content-Length header in
   response to a GET.
ToP   noToC   RFC2518 - Page 70
   Value:      content-length ; see section 14.14 of [RFC2068]

   <!ELEMENT getcontentlength (#PCDATA) >

13.5 getcontenttype Property

   Name:       getcontenttype
   Namespace:  DAV:
   Purpose:    Contains the Content-Type header returned by a GET
   without accept headers.
   Description: This getcontenttype property MUST be defined on any DAV
   compliant resource that returns the Content-Type header in response
   to a GET.
   Value:      media-type   ; defined in section 3.7 of [RFC2068]

   <!ELEMENT getcontenttype (#PCDATA) >

13.6 getetag Property

   Name:       getetag
   Namespace:  DAV:
   Purpose:    Contains the ETag header returned by a GET without
   accept headers.
   Description: The getetag property MUST be defined on any DAV
   compliant resource that returns the Etag header.
   Value:      entity-tag  ; defined in section 3.11 of [RFC2068]

   <!ELEMENT getetag (#PCDATA) >

13.7 getlastmodified Property

   Name:       getlastmodified
   Namespace:  DAV:
   Purpose:    Contains the Last-Modified header returned by a GET
   method without accept headers.
   Description: Note that the last-modified date on a resource may
   reflect changes in any part of the state of the resource, not
   necessarily just a change to the response to the GET method.  For
   example, a change in a property may cause the last-modified date to
   change. The getlastmodified property MUST be defined on any DAV
   compliant resource that returns the Last-Modified header in response
   to a GET.
   Value:      HTTP-date  ; defined in section 3.3.1 of [RFC2068]

   <!ELEMENT getlastmodified (#PCDATA) >
ToP   noToC   RFC2518 - Page 71
13.8 lockdiscovery Property

   Name:       lockdiscovery
   Namespace:  DAV:
   Purpose:    Describes the active locks on a resource
   Description: The lockdiscovery property returns a listing of who has
   a lock, what type of lock he has, the timeout type and the time
   remaining on the timeout, and the associated lock token.  The server
   is free to withhold any or all of this information if the requesting
   principal does not have sufficient access rights to see the requested

   <!ELEMENT lockdiscovery (activelock)* >

13.8.1 Example - Retrieving the lockdiscovery Property


   PROPFIND /container/ HTTP/1.1
   Content-Length: xxxx
   Content-Type: text/xml; charset="utf-8"

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D='DAV:'>


   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D='DAV:'>
                              <D:owner>Jane Smith</D:owner>
ToP   noToC   RFC2518 - Page 72
               <D:status>HTTP/1.1 200 OK</D:status>

   This resource has a single exclusive write lock on it, with an
   infinite timeout.

13.9 resourcetype Property

   Name:       resourcetype
   Namespace:  DAV:
   Purpose:    Specifies the nature of the resource.
   Description: The resourcetype property MUST be defined on all DAV
   compliant resources.  The default value is empty.

   <!ELEMENT resourcetype ANY >

13.10 source Property

   Name:       source
   Namespace:  DAV:
   Purpose:    The destination of the source link identifies the
   resource that contains the unprocessed source of the link's source.
   Description: The source of the link (src) is typically the URI of the
   output resource on which the link is defined, and there is typically
   only one destination (dst) of the link, which is the URI where the
   unprocessed source of the resource may be accessed.  When more than
   one link destination exists, this specification asserts no policy on

   <!ELEMENT source (link)* >

13.10.1 Example - A source Property

   <?xml version="1.0" encoding="utf-8" ?>
   <D:prop xmlns:D="DAV:" xmlns:F="">
ToP   noToC   RFC2518 - Page 73

   In this example the resource has a source
   property that contains three links.  Each link contains three
   elements, two of which, src and dst, are part of the DAV schema
   defined in this document, and one which is defined by the schema (Source, Library, and Makefile).  A
   client which only implements the elements in the DAV spec will not
   understand the foocorp elements and will ignore them, thus seeing the
   expected source and destination links.  An enhanced client may know
   about the foocorp elements and be able to present the user with
   additional information about the links.  This example demonstrates
   the power of XML markup, allowing element values to be enhanced
   without breaking older clients.

13.11 supportedlock Property

   Name:       supportedlock
   Namespace:  DAV:
   Purpose:    To provide a listing of the lock capabilities supported
   by the resource.
   Description: The supportedlock property of a resource returns a
   listing of the combinations of scope and access types which may be
   specified in a lock request on the resource.  Note that the actual
   contents are themselves controlled by access controls so a server is
   not required to provide information the client is not authorized to

   <!ELEMENT supportedlock (lockentry)* >

13.11.1 Example - Retrieving the supportedlock Property


   PROPFIND  /container/ HTTP/1.1
ToP   noToC   RFC2518 - Page 74
   Content-Length: xxxx
   Content-Type: text/xml; charset="utf-8"

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:">


   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:">
               <D:status>HTTP/1.1 200 OK</D:status>

14 Instructions for Processing XML in DAV

   All DAV compliant resources MUST ignore any unknown XML element and
   all its children encountered while processing a DAV method that uses
   XML as its command language.

   This restriction also applies to the processing, by clients, of DAV
   property values where unknown XML elements SHOULD be ignored unless
   the property's schema declares otherwise.
ToP   noToC   RFC2518 - Page 75
   This restriction does not apply to setting dead DAV properties on the
   server where the server MUST record unknown XML elements.

   Additionally, this restriction does not apply to the use of XML where
   XML happens to be the content type of the entity body, for example,
   when used as the body of a PUT.

   Since XML can be transported as text/xml or application/xml, a DAV
   server MUST accept DAV method requests with XML parameters
   transported as either text/xml or application/xml, and DAV client
   MUST accept XML responses using either text/xml or application/xml.

15 DAV Compliance Classes

   A DAV compliant resource can choose from two classes of compliance.
   A client can discover the compliance classes of a resource by
   executing OPTIONS on the resource, and examining the "DAV" header
   which is returned.

   Since this document describes extensions to the HTTP/1.1 protocol,
   minimally all DAV compliant resources, clients, and proxies MUST be
   compliant with [RFC2068].

   Compliance classes are not necessarily sequential. A resource that is
   class 2 compliant must also be class 1 compliant; but if additional
   compliance classes are defined later, a resource that is class 1, 2,
   and 4 compliant might not be class 3 compliant.  Also note that
   identifiers other than numbers may be used as compliance class

15.1 Class 1

   A class 1 compliant resource MUST meet all "MUST" requirements in all
   sections of this document.

   Class 1 compliant resources MUST return, at minimum, the value "1" in
   the DAV header on all responses to the OPTIONS method.

15.2 Class 2

   A class 2 compliant resource MUST meet all class 1 requirements and
   support the LOCK method, the supportedlock property, the
   lockdiscovery property, the Time-Out response header and the Lock-
   Token request header.  A class "2" compliant resource SHOULD also
   support the Time-Out request header and the owner XML element.

   Class 2 compliant resources MUST return, at minimum, the values "1"
   and "2" in the DAV header on all responses to the OPTIONS method.