RFC 2518
HTTP Extensions for Distributed Authoring -- WEBDAV
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")
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
applied.
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.
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].
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.9.4.1.1 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.
9.4.2.1 Example - Tagged List If header
COPY /resource1 HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/resource2 If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token> [W/"A weak ETag"]) (["strong ETag"]) <http://www.bar.bar/random>(["another strong ETag"]) In this example http://www.foo.bar/resource1 is being copied to http://www.foo.bar/resource2. When the method is first applied to http://www.foo.bar/resource1, 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 http://www.bar.bar/random never has the method applied to it (the only other resource listed in the If header) and http://www.foo.bar/resource2 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.
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.
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
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).
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.
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) >
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.
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 >
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?) >
12.9.1.1 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?) >12.9.1.2 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>
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+) >
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.
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).
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.
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) >
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: www.foo.bar 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>http://www.foo.bar/container/</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>
<D:href>
opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
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="http://www.foocorp.com/Project/">
<D:source>
<D:link>
<F:projfiles>Source</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/main.c</D:dst>
</D:link>
<D:link>
<F:projfiles>Library</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/main.lib</D:dst>
</D:link>
<D:link>
<F:projfiles>Makefile</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/makefile</D:dst>
</D:link>
</D:source>
</D:prop>
In this example the resource http://foo.bar/program 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
http://www.foocorp.com/project/ (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
Host: www.foo.bar
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:supportedlock/></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>http://www.foo.bar/container/</D:href>
<D:propstat>
<D:prop>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
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.
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)
