RFC2616]), 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. The server MUST do authorization checks before checking this or any conditional header. All DAV-compliant resources MUST support the Overwrite header.
Section 6.6 for a description of lock timeout behavior. RFC2616]. Section 13 for more information).
Section 9.6.2). Some method definitions provide information about specific status codes clients should be prepared to see in a response. However, clients MUST be able to handle other status codes, using the generic rules defined in Section 10 of [RFC2616]. 2. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat' element instead of 'status', providing information about individual properties of a resource. This format is specific to PROPFIND and PROPPATCH, and is described in detail in Sections 9.1 and 9.2.
RFC2518] did not have any place for the server to provide the new URI for redirected resources. This specification does define a 'location' element for this information (see Section 14.9). Servers MUST use this new element with redirect responses in Multi-Status. Clients encountering redirected resources in Multi-Status MUST NOT rely on the 'location' element being present with a new URI. If the element is not present, the client MAY reissue the request to the individual redirected resource, because the response to that request can be redirected with a Location header containing the new URI. Sections 9.2.1, 9.1.2, 9.6.1, 9.8.3, and 9.9.2 define various status codes used in Multi-Status responses. This specification does not define the meaning of other status codes that could appear in these responses. 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). Note that all of the elements defined here may be extended according to the rules defined in Section 17. All elements defined here are in the "DAV:" namespace.
RFC2616], Section 14.30) for use with some status codes (such as 201 and the 300 series codes). When these codes are used inside a 'multistatus' element, the 'location' element can be used to provide the accompanying Location header value.
Description: Contains a single href element with the same value that would be used in a Location header. <!ELEMENT location (href)>
of a homepage) who created a lock. The value provided MUST be treated as a dead property in terms of XML Information Item preservation. The server MUST NOT alter the value unless the owner value provided by the client is empty. For a certain amount of interoperability between different client implementations, if clients have URI-formatted contact information for the lock creator suitable for user display, then clients SHOULD put those URIs in 'href' child elements of the 'owner' element. Extensibility: MAY be extended with child elements, mixed content, text content or attributes. <!ELEMENT owner ANY >
Purpose: Specifies the properties to be returned from a PROPFIND method. Four special elements are specified for use with 'propfind': 'prop', 'allprop', 'include', and 'propname'. If 'prop' is used inside 'propfind', it MUST NOT contain property values. <!ELEMENT propfind ( propname | (allprop, include?) | prop ) >
attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND. <!ELEMENT set (prop) > Section 6.1 of [RFC2616]) <!ELEMENT status (#PCDATA) > Section 10.7) <!ELEMENT timeout (#PCDATA) >
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). A protected property is one that cannot be changed with a PROPPATCH request. There may be other requests that would result in a change to a protected property (as when a LOCK request affects the value of DAV:lockdiscovery). Note that a given property could be protected on one type of resource, but not protected on another type of resource. A computed property is one with a value defined in terms of a computation (based on the content and other properties of that resource, or even of some other resource). A computed property is always a protected property. COPY and MOVE behavior refers to local COPY and MOVE operations. For properties defined based on HTTP GET response headers (DAV:get*), the header value could include LWS as defined in [RFC2616], Section 4.2. Server implementors SHOULD strip LWS from these values before using as WebDAV property values. RFC3339], see the ABNF in Section 5.6.) Protected: MAY be protected. Some servers allow DAV:creationdate to be changed to reflect the time the document was created if that is more meaningful to the user (rather than the time it was uploaded). Thus, clients SHOULD NOT use this property in synchronization logic (use DAV:getetag instead). COPY/MOVE behavior: This property value SHOULD be kept during a MOVE operation, but is normally re-initialized when a resource is created with a COPY. It should not be set in a COPY.
Description: The DAV:creationdate property SHOULD be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created. Servers that are incapable of persistently recording the creation date SHOULD instead leave it undefined (i.e. report "Not Found"). <!ELEMENT creationdate (#PCDATA) > RFC2518] might have made this a protected property as this is a new requirement. COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations. Description: Contains a description of the resource that is suitable for presentation to a user. This property is defined on the resource, and hence SHOULD have the same value independent of the Request-URI used to retrieve it (thus, computing this property based on the Request-URI is deprecated). While generic clients might display the property value to end users, client UI designers must understand that the method for identifying resources is still the URL. Changes to DAV:displayname do not issue moves or copies to the server, but simply change a piece of meta-data on the individual resource. Two resources can have the same DAV: displayname value even within the same collection. <!ELEMENT displayname (#PCDATA) > Section 14.12 of [RFC2616]) as it would be returned by a GET without accept headers. Value: language-tag (language-tag is defined in Section 3.10 of [RFC2616])
Protected: SHOULD NOT be protected, so that clients can reset the language. Note that servers implementing [RFC2518] might have made this a protected property as this is a new requirement. COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations. Description: The DAV:getcontentlanguage property MUST be defined on any DAV-compliant resource that returns the Content-Language header on a GET. <!ELEMENT getcontentlanguage (#PCDATA) > Section 14.13 of [RFC2616]. Protected: This property is computed, therefore protected. Description: The DAV:getcontentlength property MUST be defined on any DAV-compliant resource that returns the Content-Length header in response to a GET. COPY/MOVE behavior: This property value is dependent on the size of the destination resource, not the value of the property on the source resource. <!ELEMENT getcontentlength (#PCDATA) > Section 14.17 of [RFC2616]) as it would be returned by a GET without accept headers. Value: media-type (defined in Section 3.7 of [RFC2616]) Protected: Potentially protected if the server prefers to assign content types on its own (see also discussion in Section 9.7.1).
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations. Description: This property MUST be defined on any DAV-compliant resource that returns the Content-Type header in response to a GET. <!ELEMENT getcontenttype (#PCDATA) > Section 14.19 of [RFC2616]) as it would be returned by a GET without accept headers. Value: entity-tag (defined in Section 3.11 of [RFC2616]) Protected: MUST be protected because this value is created and controlled by the server. COPY/MOVE behavior: This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. Also note the considerations in Section 8.8. Description: The getetag property MUST be defined on any DAV- compliant resource that returns the Etag header. Refer to Section 3.11 of RFC 2616 for a complete definition of the semantics of an ETag, and to Section 8.6 for a discussion of ETags in WebDAV. <!ELEMENT getetag (#PCDATA) > Section 14.29 of [RFC2616]) as it would be returned by a GET method without accept headers. Value: rfc1123-date (defined in Section 3.3.1 of [RFC2616]) Protected: SHOULD be protected because some clients may rely on the value for appropriate caching behavior, or on the value of the Last-Modified header to which this property is linked.
COPY/MOVE behavior: This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Note that some server implementations use the file system date modified value for the DAV:getlastmodified value, and this can be preserved in a MOVE even when the HTTP Last-Modified value SHOULD change. Note that since [RFC2616] requires clients to use ETags where provided, a server implementing ETags can count on clients using a much better mechanism than modification dates for offline synchronization or cache control. Also note the considerations in Section 8.8. Description: The last-modified date on a resource SHOULD only reflect changes in the body (the GET responses) of the resource. A change in a property only SHOULD NOT cause the last-modified date to change, because clients MAY rely on the last-modified date to know when to overwrite the existing body. The DAV: getlastmodified property MUST be defined on any DAV-compliant resource that returns the Last-Modified header in response to a GET. <!ELEMENT getlastmodified (#PCDATA) > Section 7). <!ELEMENT lockdiscovery (activelock)* >
This resource has a single exclusive write lock on it, with an infinite timeout. Section 14.3). If the element contains the 'collection' child element plus additional unrecognized elements, it should generally be treated as a collection. If the element contains no recognized child elements, it should be treated as a non-collection resource. The default value is empty. This element MUST NOT contain text or mixed content. Any custom child element is considered to be an identifier for a resource type. Example: (fictional example to show extensibility) <x:resourcetype xmlns:x="DAV:"> <x:collection/> <f:search-results xmlns:f="http://www.example.com/ns"/> </x:resourcetype>
COPY/MOVE behavior: This property value is dependent on the kind of locks supported at the destination, not on the value of the property at the source resource. Servers attempting to COPY to a destination should not attempt to set this property at the destination. Description: Returns a listing of the combinations of scope and access types that 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. This property is NOT lockable with respect to write locks (Section 7). <!ELEMENT supportedlock (lockentry)* >
<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> Section 8.7, extra information on error conditions can be included in the body of many status responses. This section makes requirements on the use of the error body mechanism and introduces a number of precondition and postcondition codes. A "precondition" of a method describes the state of the server that must be true for that method to be performed. A "postcondition" of a method describes the state of the server that must be true after that method has been completed. Each precondition and postcondition has a unique XML element associated with it. In a 207 Multi-Status response, the XML element MUST appear inside an 'error' element in the appropriate 'propstat or 'response' element depending on whether the condition applies to one or more properties or to the resource as a whole. In all other error responses where this specification's 'error' body is used, the precondition/postcondition XML element MUST be returned as the child of a top-level 'error' element in the response body, unless otherwise negotiated by the request, along with an appropriate response status. The most common response status codes are 403 (Forbidden) if the request should not be repeated because it will always fail, and 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request. The 'error' element MAY contain child elements with specific error information and MAY be extended with any custom child elements. This mechanism does not take the place of using a correct numeric status code as defined here or in HTTP, because the client must always be able to take a reasonable course of action based only on the numeric code. However, it does remove the need to define new numeric codes. The new machine-readable codes used for this purpose are XML elements classified as preconditions and postconditions, so naturally, any group defining a new condition code can use their own namespace. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups.
A server supporting this specification SHOULD use the XML error whenever a precondition or postcondition defined in this document is violated. For error conditions not specified in this document, the server MAY simply choose an appropriate numeric status and leave the response body blank. However, a server MAY instead use a custom condition code and other supporting text, because even when clients do not automatically recognize condition codes, they can be quite useful in interoperability testing and debugging. Example - Response with precondition code >>Response HTTP/1.1 423 Locked Content-Type: application/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:error xmlns:D="DAV:"> <D:lock-token-submitted> <D:href>/workspace/webdav/</D:href> </D:lock-token-submitted> </D:error> In this example, a client unaware of a depth-infinity lock on the parent collection "/workspace/webdav/" attempted to modify the collection member "/workspace/webdav/proposal.doc". Some other useful preconditions and postconditions have been defined in other specifications extending WebDAV, such as [RFC3744] (see particularly Section 7.1.1), [RFC3253], and [RFC3648]. All these elements are in the "DAV:" namespace. If not specified otherwise, the content for each condition's XML element is defined to be empty. Name: lock-token-matches-request-uri Use with: 409 Conflict Purpose: (precondition) -- A request may include a Lock-Token header to identify a lock for the UNLOCK method. However, if the Request-URI does not fall within the scope of the lock identified by the token, the server SHOULD use this error. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
Name: lock-token-submitted (precondition) Use with: 423 Locked Purpose: The request could not succeed because a lock token should have been submitted. This element, if present, MUST contain at least one URL of a locked resource that prevented the request. In cases of MOVE, COPY, and DELETE where collection locks are involved, it can be difficult for the client to find out which locked resource made the request fail -- but the server is only responsible for returning one such locked resource. The server MAY return every locked resource that prevented the request from succeeding if it knows them all. <!ELEMENT lock-token-submitted (href+) > Name: no-conflicting-lock (precondition) Use with: Typically 423 Locked Purpose: A LOCK request failed due the presence of an already existing conflicting lock. Note that a lock can be in conflict although the resource to which the request was directed is only indirectly locked. In this case, the precondition code can be used to inform the client about the resource that is the root of the conflicting lock, avoiding a separate lookup of the "lockdiscovery" property. <!ELEMENT no-conflicting-lock (href)* > Name: no-external-entities Use with: 403 Forbidden Purpose: (precondition) -- If the server rejects a client request because the request body contains an external entity, the server SHOULD use this error. Name: preserved-live-properties Use with: 409 Conflict Purpose: (postcondition) -- The server received an otherwise-valid MOVE or COPY request, but cannot maintain the live properties with the same behavior at the destination. It may be that the server
only supports some live properties in some parts of the repository, or simply has an internal error. Name: propfind-finite-depth Use with: 403 Forbidden Purpose: (precondition) -- This server does not allow infinite-depth PROPFIND requests on collections. Name: cannot-modify-protected-property Use with: 403 Forbidden Purpose: (precondition) -- The client attempted to set a protected property in a PROPPATCH (such as DAV:getetag). See also [RFC3253], Section 3.12. REC-XML-NAMES]) is used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the "DAV:" namespace SHOULD NOT be used in the request or response body unless that XML element is explicitly defined in an IETF RFC reviewed by a WebDAV working group. For WebDAV to be both extensible and backwards-compatible, both clients and servers need to know how to behave when unexpected or unrecognized command extensions are received. For XML processing, this means that clients and servers MUST process received XML documents as if unexpected elements and attributes (and all children of unrecognized elements) were not there. An unexpected element or attribute includes one that may be used in another context but is not expected here. Ignoring such items for purposes of processing can of course be consistent with logging all information or presenting for debugging. This restriction also applies to the processing, by clients, of DAV property values where unexpected 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 all 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. Processing instructions in XML SHOULD be ignored by recipients. Thus, specifications extending WebDAV SHOULD NOT use processing instructions to define normative behavior. XML DTD fragments are included for all the XML elements defined in this specification. However, correct XML will not be valid according to any DTD due to namespace usage and extension rules. In particular: o Elements (from this specification) are in the "DAV:" namespace, o Element ordering is irrelevant unless otherwise stated, o Extension attributes MAY be added, o For element type definitions of "ANY", the normative text definition for that element defines what can be in it and what that means. o For element type definitions of "#PCDATA", extension elements MUST NOT be added. o For other element type definitions, including "EMPTY", extension elements MAY be added. Note that this means that elements containing elements cannot be extended to contain text, and vice versa. With DTD validation relaxed by the rules above, the constraints described by the DTD fragments are normative (see for example Appendix A). A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD. Note that this section describes backwards-compatible extensibility rules. There might also be times when an extension is designed not to be backwards-compatible, for example, defining an extension that reuses an XML element defined in this document but omitting one of the child elements required by the DTDs in this specification.