in Index   Prev   Next

RFC 2518

HTTP Extensions for Distributed Authoring -- WEBDAV

Pages: 94
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 ETag"]) 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 any. 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 Host: Destination: 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 code. 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 header. 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 [RFC2068].

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 method.

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 action.

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 resource. <!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 lock. 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 properties. 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 methods. <!ELEMENT omit EMPTY >

12.13 propertyupdate XML element

Name: propertyupdate Namespace: DAV: Purpose: Contains a request to alter the properties on a resource. 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 GET. 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 data. <!ELEMENT lockdiscovery (activelock)* >

13.8.1 Example - Retrieving the lockdiscovery Property

>>Request PROPFIND /container/ HTTP/1.1 Host: Content-Length: xxxx Content-Type: text/xml; charset="utf-8" <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D='DAV:'> <D:prop><D:lockdiscovery/></D:prop> </D:propfind> >>Response 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:response> <D:href></D:href> <D:propstat> <D:prop> <D:lockdiscovery> <D:activelock> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:depth>0</D:depth> <D:owner>Jane Smith</D:owner> <D:timeout>Infinite</D:timeout> <D:locktoken>
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 ordering. <!ELEMENT source (link)* >

13.10.1 Example - A source Property

<?xml version="1.0" encoding="utf-8" ?> <D:prop xmlns:D="DAV:" xmlns:F=""> <D:source> <D:link> <F:projfiles>Source</F:projfiles> <D:src></D:src>
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 see. <!ELEMENT supportedlock (lockentry)* >

13.11.1 Example - Retrieving the supportedlock Property

>>Request 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 identifiers.

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.

(next page on part 4)

Next Section