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
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.
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
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
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
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
o The underlying storage can be attacked by PUTting extremely large
o Asking for recursive operations on large collections can attack
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
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
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
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]).
Header field name: DAV
Applicable protocol: http
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
Hafenweg 16, 48155 Muenster, Germany
University of California, Santa Cruz
1156 High Street, Santa Cruz, CA 95064
University of California, Santa Cruz
1156 High Street, Santa Cruz, CA 95064
24. Authors of RFC 2518
Y. Y. Goland
One Microsoft Way
Redmond, WA 98052-6399
E. J. Whitehead, Jr.
Dept. Of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425
685 East Middlefield Road
Mountain View, CA 94043
[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,
[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.
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" ?>
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
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" ?>
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" ?>
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" ?>
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
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
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
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
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
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
Example - forcing auth challenge with write request
PUT /forceauth.txt HTTP/1.1
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
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"
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'
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
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
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
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
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).
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).
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
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).
Lisa Dusseault (editor)
2064 Edgewood Dr.
Palo Alto, CA 94303
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.
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