RFC 4918
HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
Pages: 127
Proposed Standard
→ Errata
Obsoletes: 2518
Updated by: 5689
Proposed Standard
→ Errata
Obsoletes: 2518
Updated by: 5689
Part 5 of 5 – Pages 103 to 127
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.
Example:
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
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.
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
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
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
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
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
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 <http://www.iana.org/assignments/http-status-codes>. Note: the HTTP status code 102 (Processing) has been removed in this specification; its IANA registration should continue to reference RFC 2518.
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
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: julian.reschke@greenbytes.de Elias Sinderson University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: elias@cse.ucsc.edu Jim Whitehead University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: ejw@soe.ucsc.edu24. Authors of RFC 2518
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: yarong@microsoft.com E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 EMail: ejw@ics.uci.edu A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043 EMail: asad@netscape.com
S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: srcarter@novell.com D. Jensen Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: dcjensen@novell.com25. 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, <http://www.w3.org/TR/2006/REC-xml-20060816/>. [REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/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:// www.w3.org/TR/2006/REC-xml-names-20060816/>. [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.
[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.
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.
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="http://www.example.com/standards/props/"> <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="http://www.example.com/standards/props/"> </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="http://www.example.com/standards/props/"> <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.
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.
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.
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,
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 authorization. Example - forcing auth challenge with write request >>Request PUT /forceauth.txt HTTP/1.1 Host: www.example.com 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:
"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
resource."
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
>>Request
PROPFIND /docs/ HTTP/1.1
Host: www.example.com
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,
thereby avoiding additional requests due to changed 'allprop'
semantics.
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
3253).
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.
Locking
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.
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
lock.
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.
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: ldusseault@commerce.net
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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.