Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4918

HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)

Pages: 127
Proposed Standard
Obsoletes:  2518
Updated by:  5689
Part 5 of 5 – Pages 103 to 127
First   Prev   None

Top   ToC   RFC4918 - Page 103   prevText

18. DAV Compliance Classes

A DAV-compliant resource can advertise several 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. Note particularly that resources, rather than servers, are spoken of as being compliant. That is because theoretically some resources on a server could support different feature sets. For example, a server could have a sub-repository where an advanced feature like versioning was supported, even if that feature was not supported on all sub-repositories. Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV-compliant resources, clients, and proxies MUST be compliant with [RFC2616]. A resource that is class 2 or class 3 compliant must also be class 1 compliant.

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

18.2. Class 2

A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the DAV:supportedlock property, the DAV: lockdiscovery property, the Time-Out response header and the Lock- Token request header. A class 2 compliant resource SHOULD also support the Timeout 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.

18.3. Class 3

A resource can explicitly advertise its support for the revisions to [RFC2518] made in this document. Class 1 MUST be supported as well. Class 2 MAY be supported. Advertising class 3 support in addition to class 1 and 2 means that the server supports all the requirements in this specification. Advertising class 3 and class 1 support, but not class 2, means that the server supports all the requirements in this specification except possibly those that involve locking support.
Top   ToC   RFC4918 - Page 104

            DAV: 1, 3

19. Internationalization Considerations

In the realm of internationalization, this specification complies with the IETF Character Set Policy [RFC2277]. In this specification, human-readable fields can be found either in the value of a property, or in an error message returned in a response entity body. In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [RFC3629] and UTF-16 [RFC2781] encodings of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header (defined in [RFC3023]), as well as XML charset declarations. XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. The "xml:lang" attribute appears on an XML element to identify the language of its content and attributes. See [REC-XML] for definitions of values and scoping. WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. Implementors of WebDAV applications are strongly encouraged to read "XML Media Types" [RFC3023] for instruction on which MIME media type to use for XML transport, and on use of the charset parameter of the Content-Type header. Names used within this specification fall into four categories: names of protocol elements such as methods and headers, names of XML elements, names of properties, and names of conditions. Naming of protocol elements follows the precedent of HTTP, using English names encoded in US-ASCII for methods and headers. Since these protocol elements are not visible to users, and are simply long token identifiers, they do not need to support multiple languages. Similarly, the names of XML elements used in this specification are not visible to the user and hence do not need to support multiple languages. WebDAV property names are qualified XML names (pairs of XML namespace name and local name). Although some applications (e.g., a generic property viewer) will display property names directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the property name and namespace to a human-readable field when displaying the property name
Top   ToC   RFC4918 - Page 105
   to a user.  It is only in the case where the set of properties is not
   known ahead of time that an application need display a property name
   to a user.  We recommend that applications provide human-readable
   property names wherever feasible.

   For error reporting, we follow the convention of HTTP/1.1 status
   codes, including with each status code a short, English description
   of the code (e.g., 423 (Locked)).  While the possibility exists that
   a poorly crafted user agent would display this message to a user,
   internationalized applications will ignore this message, and display
   an appropriate message in the user's language and character set.

   Since interoperation of clients and servers does not require locale
   information, this specification does not specify any mechanism for
   transmission of this information.

20. Security Considerations

This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware. All of the security considerations of HTTP/1.1 (discussed in [RFC2616]) and XML (discussed in [RFC3023]) also apply to WebDAV. In addition, the security risks inherent in remote authoring require stronger authentication technology, introduce several new privacy concerns, and may increase the hazards from poor server design. These issues are detailed below.

20.1. Authentication of Clients

Due to their emphasis on authoring, WebDAV servers need to use authentication technology to protect not just access to a network resource, but the integrity of the resource as well. Furthermore, the introduction of locking functionality requires support for authentication. A password sent in the clear over an insecure channel is an inadequate means for protecting the accessibility and integrity of a resource as the password may be intercepted. Since Basic authentication for HTTP/1.1 performs essentially clear text transmission of a password, Basic authentication MUST NOT be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server MUST NOT send a Basic authentication challenge in a WWW-Authenticate header unless the connection is secure. An example of a secure connection would be a Transport Layer Security (TLS) connection employing a strong cipher suite and server authentication.
Top   ToC   RFC4918 - Page 106
   WebDAV applications MUST support the Digest authentication scheme
   [RFC2617].  Since Digest authentication verifies that both parties to
   a communication know a shared secret, a password, without having to
   send that secret in the clear, Digest authentication avoids the
   security problems inherent in Basic authentication while providing a
   level of authentication that is useful in a wide range of scenarios.

20.2. Denial of Service

Denial-of-service attacks are of special concern to WebDAV servers. WebDAV plus HTTP enables denial-of-service attacks on every part of a system's resources. o The underlying storage can be attacked by PUTting extremely large files. o Asking for recursive operations on large collections can attack processing time. o Making multiple pipelined requests on multiple connections can attack network connections. WebDAV servers need to be aware of the possibility of a denial-of- service attack at all levels. The proper response to such an attack MAY be to simply drop the connection. Or, if the server is able to make a response, the server MAY use a 400-level status request such as 400 (Bad Request) and indicate why the request was refused (a 500- level status response would indicate that the problem is with the server, whereas unintentional DoS attacks are something the client is capable of remedying).

20.3. Security through Obscurity

WebDAV provides, through the PROPFIND method, a mechanism for listing the member resources of a collection. This greatly diminishes the effectiveness of security or privacy techniques that rely only on the difficulty of discovering the names of network resources. Users of WebDAV servers are encouraged to use access control techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.

20.4. Privacy Issues Connected to Locks

When submitting a lock request, a user agent may also submit an 'owner' XML field giving contact information for the person taking out the lock (for those cases where a person, rather than a robot, is taking out the lock). This contact information is stored in a DAV: lockdiscovery property on the resource, and can be used by other
Top   ToC   RFC4918 - Page 107
   collaborators to begin negotiation over access to the resource.
   However, in many cases, this contact information can be very private,
   and should not be widely disseminated.  Servers SHOULD limit read
   access to the DAV:lockdiscovery property as appropriate.
   Furthermore, user agents SHOULD provide control over whether contact
   information is sent at all, and if contact information is sent,
   control over exactly what information is sent.

20.5. Privacy Issues Connected to Properties

Since property values are typically used to hold information such as the author of a document, there is the possibility that privacy concerns could arise stemming from widespread access to a resource's property data. To reduce the risk of inadvertent release of private information via properties, servers are encouraged to develop access control mechanisms that separate read access to the resource body and read access to the resource's properties. This allows a user to control the dissemination of their property data without overly restricting access to the resource's contents.

20.6. Implications of XML Entities

XML supports a facility known as "external entities", defined in Section 4.2.2 of [REC-XML], which instructs an XML processor to retrieve and include additional XML. An external XML entity can be used to append or modify the document type declaration (DTD) associated with an XML document. An external XML entity can also be used to include XML within the content of an XML document. For non- validating XML, such as the XML used in this specification, including an external XML entity is not required by XML. However, XML does state that an XML processor may, at its discretion, include the external XML entity. External XML entities have no inherent trustworthiness and are subject to all the attacks that are endemic to any HTTP GET request. Furthermore, it is possible for an external XML entity to modify the DTD, and hence affect the final form of an XML document, in the worst case, significantly modifying its semantics or exposing the XML processor to the security risks discussed in [RFC3023]. Therefore, implementers must be aware that external XML entities should be treated as untrustworthy. If a server chooses not to handle external XML entities, it SHOULD respond to requests containing external entities with the 'no-external-entities' condition code. There is also the scalability risk that would accompany a widely deployed application that made use of external XML entities. In this situation, it is possible that there would be significant numbers of requests for one external XML entity, potentially overloading any
Top   ToC   RFC4918 - Page 108
   server that fields requests for the resource containing the external
   XML entity.

   Furthermore, there's also a risk based on the evaluation of "internal
   entities" as defined in Section 4.2.2 of [REC-XML].  A small,
   carefully crafted request using nested internal entities may require
   enormous amounts of memory and/or processing time to process.  Server
   implementers should be aware of this risk and configure their XML
   parsers so that requests like these can be detected and rejected as
   early as possible.

20.7. Risks Connected with Lock Tokens

This specification encourages the use of "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) for lock tokens (Section 6.5), in order to guarantee their uniqueness across space and time. Version 1 UUIDs (defined in Section 4) MAY contain a "node" field that "consists of an IEEE 802 MAC address, usually the host address. For systems with multiple IEEE addresses, any available one can be used". Since a WebDAV server will issue many locks over its lifetime, the implication is that it may also be publicly exposing its IEEE 802 address. There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address: o It is possible to track the movement of hardware from subnet to subnet. o It may be possible to identify the manufacturer of the hardware running a WebDAV server. o It may be possible to determine the number of each type of computer running WebDAV. This risk only applies to host-address-based UUID versions. Section 4 of [RFC4122] describes several other mechanisms for generating UUIDs that do not involve the host address and therefore do not suffer from this risk.

20.8. Hosting Malicious Content

HTTP has the ability to host programs that are executed on client machines. These programs can take many forms including Web scripts, executables, plug-in modules, and macros in documents. WebDAV does not change any of the security concerns around these programs, yet often WebDAV is used in contexts where a wide range of users can publish documents on a server. The server might not have a close
Top   ToC   RFC4918 - Page 109
   trust relationship with the author that is publishing the document.
   Servers that allow clients to publish arbitrary content can usefully
   implement precautions to check that content published to the server
   is not harmful to other clients.  Servers could do this by techniques
   such as restricting the types of content that is allowed to be
   published and running virus and malware detection software on
   published content.  Servers can also mitigate the risk by having
   appropriate access restriction and authentication of users that are
   allowed to publish content to the server.

21. IANA Considerations

21.1. New URI Schemes

This specification defines two URI schemes: 1. the "opaquelocktoken" scheme defined in Appendix C, and 2. the "DAV" URI scheme, which historically was used in [RFC2518] to disambiguate WebDAV property and XML element names and which continues to be used for that purpose in this specification and others extending WebDAV. Creation of identifiers in the "DAV:" namespace is controlled by the IETF. Note that defining new URI schemes for XML namespaces is now discouraged. "DAV:" was defined before standard best practices emerged.

21.2. XML Namespaces

XML namespaces disambiguate WebDAV property names and XML elements. Any WebDAV user or application can define a new namespace in order to create custom properties or extend WebDAV XML syntax. IANA does not need to manage such namespaces, property names, or element names.

21.3. Message Header Fields

The message header fields below should be added to the permanent registry (see [RFC3864]).

21.3.1. DAV

Header field name: DAV Applicable protocol: http Status: standard
Top   ToC   RFC4918 - Page 110
   Author/Change controller: IETF

   Specification document: this specification (Section 10.1)

21.3.2. Depth

Header field name: Depth Applicable protocol: http Status: standard Author/Change controller: IETF Specification document: this specification (Section 10.2)

21.3.3. Destination

Header field name: Destination Applicable protocol: http Status: standard Author/Change controller: IETF Specification document: this specification (Section 10.3)

21.3.4. If

Header field name: If Applicable protocol: http Status: standard Author/Change controller: IETF Specification document: this specification (Section 10.4)

21.3.5. Lock-Token

Header field name: Lock-Token Applicable protocol: http Status: standard
Top   ToC   RFC4918 - Page 111
   Author/Change controller: IETF

   Specification document: this specification (Section 10.5)

21.3.6. Overwrite

Header field name: Overwrite Applicable protocol: http Status: standard Author/Change controller: IETF Specification document: this specification (Section 10.6)

21.3.7. Timeout

Header field name: Timeout Applicable protocol: http Status: standard Author/Change controller: IETF Specification document: this specification (Section 10.7)

21.4. HTTP Status Codes

This specification defines the HTTP status codes o 207 Multi-Status (Section 11.1) o 422 Unprocessable Entity (Section 11.2), o 423 Locked (Section 11.3), o 424 Failed Dependency (Section 11.4) and o 507 Insufficient Storage (Section 11.5), to be updated in the registry at <>. Note: the HTTP status code 102 (Processing) has been removed in this specification; its IANA registration should continue to reference RFC 2518.
Top   ToC   RFC4918 - Page 112

22. Acknowledgements

A specification such as this thrives on piercing critical review and withers from apathetic neglect. The authors gratefully acknowledge the contributions of the following people, whose insights were so valuable at every stage of our work. Contributors to RFC 2518 Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners- Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood. Two from this list deserve special mention. The contributions by Larry Masinter have been invaluable; he both helped the formation of the working group and patiently coached the authors along the way. In so many ways he has set high standards that we have toiled to meet. The contributions of Judith Slein were also invaluable; by clarifying the requirements and in patiently reviewing version after version, she both improved this specification and expanded our minds on document management. We would also like to thank John Turner for developing the XML DTD. The authors of RFC 2518 were Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter, and D. Jensen. Although their names had to be removed due to IETF author count restrictions, they can take credit for the majority of the design of WebDAV. Additional Acknowledgements for This Specification Significant contributors of text for this specification are listed as contributors in the section below. We must also gratefully acknowledge Geoff Clemm, Joel Soderberg, and Dan Brotsky for hashing out specific text on the list or in meetings. Joe Hildebrand and Cullen Jennings helped close many issues. Barry Lind described an additional security consideration and Cullen Jennings provided text
Top   ToC   RFC4918 - Page 113
   for that consideration.  Jason Crawford tracked issue status for this
   document for a period of years, followed by Elias Sinderson.

23. Contributors to This Specification

Julian Reschke <green/>bytes GmbH Hafenweg 16, 48155 Muenster, Germany EMail: Elias Sinderson University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: Jim Whitehead University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail:

24. Authors of RFC 2518

Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 EMail: A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043 EMail:
Top   ToC   RFC4918 - Page 114
   S. R. Carter
   1555 N. Technology Way
   M/S ORM F111
   Orem, UT 84097-2399

   D. Jensen
   1555 N. Technology Way
   M/S ORM F111
   Orem, UT 84097-2399

25. References

25.1. Normative References

[REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C REC-xml-20060816, August 2006, <>. [REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C REC-xml-infoset-20040204, February 2004, < REC-xml-infoset-20040204/>. [REC-XML-NAMES] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML 1.0 (Second Edition)", W3C REC- xml-names-20060816, August 2006, <http://>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
Top   ToC   RFC4918 - Page 115
   [RFC2617]          Franks, J., Hallam-Baker, P., Hostetler, J.,
                      Lawrence, S., Leach, P., Luotonen, A., and L.
                      Stewart, "HTTP Authentication: Basic and Digest
                      Access Authentication", RFC 2617, June 1999.

   [RFC3339]          Klyne, G., Ed. and C. Newman, "Date and Time on
                      the Internet: Timestamps", RFC 3339, July 2002.

   [RFC3629]          Yergeau, F., "UTF-8, a transformation format of
                      ISO 10646", STD 63, RFC 3629, November 2003.

   [RFC3986]          Berners-Lee, T., Fielding, R., and L. Masinter,
                      "Uniform Resource Identifier (URI): Generic
                      Syntax", STD 66, RFC 3986, January 2005.

   [RFC4122]          Leach, P., Mealling, M., and R. Salz, "A
                      Universally Unique IDentifier (UUID) URN
                      Namespace", RFC 4122, July 2005.

25.2. Informative References

[RFC2291] Slein, J., Vitali, F., Whitehead, E., and D. Durand, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web", RFC 2291, February 1998. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002. [RFC3648] Whitehead, J. and J. Reschke, Ed., "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol", RFC 3648, December 2003.
Top   ToC   RFC4918 - Page 116
   [RFC3744]          Clemm, G., Reschke, J., Sedlar, E., and J.
                      Whitehead, "Web Distributed Authoring and
                      Versioning (WebDAV) Access Control Protocol",
                      RFC 3744, May 2004.

   [RFC3864]          Klyne, G., Nottingham, M., and J. Mogul,
                      "Registration Procedures for Message Header
                      Fields", BCP 90, RFC 3864, September 2004.
Top   ToC   RFC4918 - Page 117

Appendix A. Notes on Processing XML Elements

A.1. Notes on Empty XML Elements

XML supports two mechanisms for indicating that an XML element does not have any content. The first is to declare an XML element of the form <A></A>. The second is to declare an XML element of the form <A/>. The two XML elements are semantically identical.

A.2. Notes on Illegal XML Processing

XML is a flexible data format that makes it easy to submit data that appears legal but in fact is not. The philosophy of "Be flexible in what you accept and strict in what you send" still applies, but it must not be applied inappropriately. XML is extremely flexible in dealing with issues of whitespace, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements. There is no kindness in accepting illegal combinations of XML elements. At best, it will cause an unwanted result and at worst it can cause real damage.

A.3. Example - XML Syntax Error

The following request body for a PROPFIND method is illegal. <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:allprop/> <D:propname/> </D:propfind> The definition of the propfind element only allows for the allprop or the propname element, not both. Thus, the above is an error and must be responded to with a 400 (Bad Request). Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute a propname would be in for a big surprise if the server treated the command as an allprop. Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it.
Top   ToC   RFC4918 - Page 118

A.4. Example - Unexpected XML Element

The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element. <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E=""> <E:expired-props/> </D:propfind> To understand why a 400 (Bad Request) is returned, let us look at the request body as the server unfamiliar with expired-props sees it. <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E=""> </D:propfind> As the server does not understand the 'expired-props' element, according to the WebDAV-specific XML processing rules specified in Section 17, it must process the request as if the element were not there. Thus, the server sees an empty propfind, which by the definition of the propfind element is illegal. Please note that had the extension been additive, it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND: <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E=""> <D:propname/> <E:leave-out>*boss*</E:leave-out> </D:propfind> The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with 'leave-out', the only result would be that the 'leave-out' element would be ignored and a propname would be executed.
Top   ToC   RFC4918 - Page 119

Appendix B. Notes on HTTP Client Compatibility

WebDAV was designed to be, and has been found to be, backward- compatible with HTTP 1.1. The PUT and DELETE methods are defined in HTTP and thus may be used by HTTP clients as well as WebDAV-aware clients, but the responses to PUT and DELETE have been extended in this specification in ways that only a WebDAV client would be entirely prepared for. Some theoretical concerns were raised about whether those responses would cause interoperability problems with HTTP-only clients, and this section addresses those concerns. Since any HTTP client ought to handle unrecognized 400-level and 500- level status codes as errors, the following new status codes should not present any issues: 422, 423, and 507 (424 is also a new status code but it appears only in the body of a Multistatus response.) So, for example, if an HTTP client attempted to PUT or DELETE a locked resource, the 423 Locked response ought to result in a generic error presented to the user. The 207 Multistatus response is interesting because an HTTP client issuing a DELETE request to a collection might interpret a 207 response as a success, even though it does not realize the resource is a collection and cannot understand that the DELETE operation might have been a complete or partial failure. That interpretation isn't entirely justified, because a 200-level response indicates that the server "received, understood, and accepted" the request, not that the request resulted in complete success. One option is that a server could treat a DELETE of a collection as an atomic operation, and use either 204 No Content in case of success, or some appropriate error response (400 or 500 level) for an error. This approach would indeed maximize backward compatibility. However, since interoperability tests and working group discussions have not turned up any instances of HTTP clients issuing a DELETE request against a WebDAV collection, this concern is more theoretical than practical. Thus, servers are likely to be completely successful at interoperating with HTTP clients even if they treat any collection DELETE request as a WebDAV request and send a 207 Multi-Status response. In general, server implementations are encouraged to use the detailed responses and other mechanisms defined in this document rather than make changes for theoretical interoperability concerns.
Top   ToC   RFC4918 - Page 120

Appendix C. The 'opaquelocktoken' Scheme and URIs

The 'opaquelocktoken' URI scheme was defined in [RFC2518] (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time. An opaquelocktoken URI is constructed by concatenating the 'opaquelocktoken' scheme with a UUID, along with an optional extension. Servers can create new UUIDs for each new lock token. If a server wishes to reuse UUIDs, the server MUST add an extension, and the algorithm generating the extension MUST guarantee that the same extension will never be used twice with the associated UUID. OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; UUID is defined in Section 3 of [RFC4122]. Note that LWS ; is not allowed between elements of ; this production. Extension = path ; path is defined in Section 3.3 of [RFC3986]

Appendix D. Lock-null Resources

The original WebDAV model for locking unmapped URLs created "lock- null resources". This model was over-complicated and some interoperability and implementation problems were discovered. The new WebDAV model for locking unmapped URLs (see Section 7.3) creates "locked empty resources". Lock-null resources are deprecated. This section discusses the original model briefly because clients MUST be able to handle either model. In the original "lock-null resource" model, which is no longer recommended for implementation: o A lock-null resource sometimes appeared as "Not Found". The server responds with a 404 or 405 to any method except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK. o A lock-null resource does however show up as a member of its parent collection. o The server removes the lock-null resource entirely (its URI becomes unmapped) if its lock goes away before it is converted to a regular resource. Recall that locks go away not only when they expire or are unlocked, but are also removed if a resource is renamed or moved, or if any parent collection is renamed or moved.
Top   ToC   RFC4918 - Page 121
   o  The server converts the lock-null resource into a regular resource
      if a PUT request to the URL is successful.

   o  The server converts the lock-null resource into a collection if a
      MKCOL request to the URL is successful (though interoperability
      experience showed that not all servers followed this requirement).

   o  Property values were defined for DAV:lockdiscovery and DAV:
      supportedlock properties but not necessarily for other properties
      like DAV:getcontenttype.

   Clients can easily interoperate both with servers that support the
   old model "lock-null resources" and the recommended model of "locked
   empty resources" by only attempting PUT after a LOCK to an unmapped
   URL, not MKCOL or GET.

D.1. Guidance for Clients Using LOCK to Create Resources

A WebDAV client implemented to this specification might find servers that create lock-null resources (implemented before this specification using [RFC2518]) as well as servers that create locked empty resources. The response to the LOCK request will not indicate what kind of resource was created. There are a few techniques that help the client deal with either type. If the client wishes to avoid accidentally creating either lock- null or empty locked resources, an "If-Match: *" header can be included with LOCK requests to prevent the server from creating a new resource. If a LOCK request creates a resource and the client subsequently wants to overwrite that resource using a COPY or MOVE request, the client should include an "Overwrite: T" header. If a LOCK request creates a resource and the client then decides to get rid of that resource, a DELETE request is supposed to fail on a lock-null resource and UNLOCK should be used instead. But with a locked empty resource, UNLOCK doesn't make the resource disappear. Therefore, the client might have to try both requests and ignore an error in one of the two requests.

Appendix E. Guidance for Clients Desiring to Authenticate

Many WebDAV clients that have already been implemented have account settings (similar to the way email clients store IMAP account settings). Thus, the WebDAV client would be able to authenticate with its first couple requests to the server, provided it had a way to get the authentication challenge from the server with realm name,
Top   ToC   RFC4918 - Page 122
   nonce, and other challenge information.  Note that the results of
   some requests might vary according to whether or not the client is
   authenticated -- a PROPFIND might return more visible resources if
   the client is authenticated, yet not fail if the client is anonymous.

   There are a number of ways the client might be able to trigger the
   server to provide an authentication challenge.  This appendix
   describes a couple approaches that seem particularly likely to work.

   The first approach is to perform a request that ought to require
   authentication.  However, it's possible that a server might handle
   any request even without authentication, so to be entirely safe, the
   client could add a conditional header to ensure that even if the
   request passes permissions checks, it's not actually handled by the
   server.  An example of following this approach would be to use a PUT
   request with an "If-Match" header with a made-up ETag value.  This
   approach might fail to result in an authentication challenge if the
   server does not test authorization before testing conditionals as is
   required (see Section 8.5), or if the server does not need to test

   Example - forcing auth challenge with write request


     PUT /forceauth.txt HTTP/1.1
     If-Match: "xxx"
     Content-Type: text/plain
     Content-Length: 0

   The second approach is to use an Authorization header (defined in
   [RFC2617]), which is likely to be rejected by the server but which
   will then prompt a proper authentication challenge.  For example, the
   client could start with a PROPFIND request containing an
   Authorization header containing a made-up Basic userid:password
   string or with actual plausible credentials.  This approach relies on
   the server responding with a "401 Unauthorized" along with a
   challenge if it receives an Authorization header with an unrecognized
   username, invalid password, or if it doesn't even handle Basic
   authentication.  This seems likely to work because of the
   requirements of RFC 2617:
Top   ToC   RFC4918 - Page 123
   "If the origin server does not wish to accept the credentials sent
   with a request, it SHOULD return a 401 (Unauthorized) response.  The
   response MUST include a WWW-Authenticate header field containing at
   least one (possibly new) challenge applicable to the requested

   There's a slight problem with implementing that recommendation in
   some cases, because some servers do not even have challenge
   information for certain resources.  Thus, when there's no way to
   authenticate to a resource or the resource is entirely publicly
   available over all accepted methods, the server MAY ignore the
   Authorization header, and the client will presumably try again later.

   Example - forcing auth challenge with Authorization header


     PROPFIND /docs/ HTTP/1.1
     Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
     Content-type: application/xml; charset="utf-8"
     Content-Length: xxxx

     [body omitted]

Appendix F. Summary of Changes from RFC 2518

This section lists major changes between this document and RFC 2518, starting with those that are likely to result in implementation changes. Servers will advertise support for all changes in this specification by returning the compliance class "3" in the DAV response header (see Sections 10.1 and 18.3).

F.1. Changes for Both Client and Server Implementations

Collections and Namespace Operations o The semantics of PROPFIND 'allprop' (Section 9.1) have been relaxed so that servers return results including, at a minimum, the live properties defined in this specification, but not necessarily return other live properties. The 'allprop' directive therefore means something more like "return all properties that are supposed to be returned when 'allprop' is requested" -- a set of properties that may include custom properties and properties defined in other specifications if those other specifications so require. Related to this, 'allprop' requests can now be extended with the 'include' syntax to include specific named properties,
Top   ToC   RFC4918 - Page 124
      thereby avoiding additional requests due to changed 'allprop'

   o  Servers are now allowed to reject PROPFIND requests with Depth:
      Infinity.  Clients that used this will need to be able to do a
      series of Depth:1 requests instead.

   o  Multi-Status response bodies now can transport the value of HTTP's
      Location response header in the new 'location' element.  Clients
      may use this to avoid additional roundtrips to the server when
      there is a 'response' element with a 3xx status (see
      Section 14.24).

   o  The definition of COPY has been relaxed so that it doesn't require
      servers to first delete the target resources anymore (this was a
      known incompatibility with [RFC3253]).  See Section 9.8.

   Headers and Marshalling

   o  The Destination and If request headers now allow absolute paths in
      addition to full URIs (see Section 8.3).  This may be useful for
      clients operating through a reverse proxy that does rewrite the
      Host request header, but not WebDAV-specific headers.

   o  This specification adopts the error marshalling extensions and the
      "precondition/postcondition" terminology defined in [RFC3253] (see
      Section 16).  Related to that, it adds the "error" XML element
      inside multistatus response bodies (see Section 14.5, however note
      that it uses a format different from the one recommended in RFC

   o  Senders and recipients are now required to support the UTF-16
      character encoding in XML message bodies (see Section 19).

   o  Clients are now required to send the Depth header on PROPFIND
      requests, although servers are still encouraged to support clients
      that don't.


   o  RFC 2518's concept of "lock-null resources" (LNRs) has been
      replaced by a simplified approach, the "locked empty resources"
      (see Section 7.3).  There are some aspects of lock-null resources
      clients cannot rely on anymore, namely, the ability to use them to
      create a locked collection or the fact that they disappear upon
      UNLOCK when no PUT or MKCOL request was issued.  Note that servers
      are still allowed to implement LNRs as per RFC 2518.
Top   ToC   RFC4918 - Page 125
   o  There is no implicit refresh of locks anymore.  Locks are only
      refreshed upon explicit request (see Section 9.10.2).

   o  Clarified that the DAV:owner value supplied in the LOCK request
      must be preserved by the server just like a dead property
      (Section 14.17).  Also added the DAV:lockroot element
      (Section 14.12), which allows clients to discover the root of

F.2. Changes for Server Implementations

Collections and Namespace Operations o Due to interoperability problems, allowable formats for contents of 'href' elements in multistatus responses have been limited (see Section 8.3). o Due to lack of implementation, support for the 'propertybehavior' request body for COPY and MOVE has been removed. Instead, requirements for property preservation have been clarified (see Sections 9.8 and 9.9). Properties o Strengthened server requirements for storage of property values, in particular persistence of language information (xml:lang), whitespace, and XML namespace information (see Section 4.3). o Clarified requirements on which properties should be writable by the client; in particular, setting "DAV:displayname" should be supported by servers (see Section 15). o Only 'rfc1123-date' productions are legal as values for DAV: getlastmodified (see Section 15.7). Headers and Marshalling o Servers are now required to do authorization checks before processing conditional headers (see Section 8.5). Locking o Strengthened requirement to check identity of lock creator when accessing locked resources (see Section 6.4). Clients should be aware that lock tokens returned to other principals can only be used to break a lock, if at all.
Top   ToC   RFC4918 - Page 126
   o  Section 8.10.4 of [RFC2518] incorrectly required servers to return
      a 409 status where a 207 status was really appropriate.  This has
      been corrected (Section 9.10).

F.3. Other Changes

The definition of collection state has been fixed so it doesn't vary anymore depending on the Request-URI (see Section 5.2). The DAV:source property introduced in Section 4.6 of [RFC2518] was removed due to lack of implementation experience. The DAV header now allows non-IETF extensions through URIs in addition to compliance class tokens. It also can now be used in requests, although this specification does not define any associated semantics for the compliance classes defined in here (see Section 10.1). In RFC 2518, the definition of the Depth header (Section 9.2) required that, by default, request headers would be applied to each resource in scope. Based on implementation experience, the default has now been reversed (see Section 10.2). The definitions of HTTP status code 102 ([RFC2518], Section 10.1) and the Status-URI response header (Section 9.7) have been removed due to lack of implementation. The TimeType format used in the Timeout request header and the "timeout" XML element used to be extensible. Now, only the two formats defined by this specification are allowed (see Section 10.7).

Author's Address

Lisa Dusseault (editor) CommerceNet 2064 Edgewood Dr. Palo Alto, CA 94303 US EMail:
Top   ToC   RFC4918 - Page 127
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is currently provided by the
   Internet Society.