Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   None  Group: WEBDAV

RFC 4918

HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)

Pages: 127
Proposed STD
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

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

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

   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

   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

   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

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

   Elias Sinderson
   University of California, Santa Cruz
   1156 High Street, Santa Cruz, CA 95064

   Jim Whitehead
   University of California, Santa Cruz
   1156 High Street, Santa Cruz, CA 95064

24.  Authors of RFC 2518

   Y. Y. Goland
   Microsoft Corporation
   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

   A. Faizi
   685 East Middlefield Road
   Mountain View, CA 94043
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-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:">

   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:"

   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:"

   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:"

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

   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,

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


   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.
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)
   2064 Edgewood Dr.
   Palo Alto, CA  94303

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.