7 Network Working Group Y. Goland
8 Request for Comments: 2518 Microsoft
9 Category: Standards Track E. Whitehead
20 HTTP Extensions for Distributed Authoring -- WEBDAV
24 This document specifies an Internet standards track protocol for the
25 Internet community, and requests discussion and suggestions for
26 improvements. Please refer to the current edition of the "Internet
27 Official Protocol Standards" (STD 1) for the standardization state
28 and status of this protocol. Distribution of this memo is unlimited.
32 Copyright (C) The Internet Society (1999). All Rights Reserved.
36 This document specifies a set of methods, headers, and content-types
37 ancillary to HTTP/1.1 for the management of resource properties,
38 creation and management of resource collections, namespace
39 manipulation, and resource locking (collision avoidance).
43 ABSTRACT............................................................1
44 1 INTRODUCTION .....................................................5
45 2 NOTATIONAL CONVENTIONS ...........................................7
46 3 TERMINOLOGY ......................................................7
47 4 DATA MODEL FOR RESOURCE PROPERTIES ...............................8
48 4.1 The Resource Property Model ...................................8
49 4.2 Existing Metadata Proposals ...................................8
50 4.3 Properties and HTTP Headers ...................................9
51 4.4 Property Values ...............................................9
52 4.5 Property Names ...............................................10
53 4.6 Media Independent Links ......................................10
54 5 COLLECTIONS OF WEB RESOURCES ....................................11
58 Goland, et al. Standards Track [Page 1]
60 RFC 2518 WEBDAV February 1999
63 5.1 HTTP URL Namespace Model .....................................11
64 5.2 Collection Resources .........................................11
65 5.3 Creation and Retrieval of Collection Resources ...............12
66 5.4 Source Resources and Output Resources ........................13
67 6 LOCKING .........................................................14
68 6.1 Exclusive Vs. Shared Locks ...................................14
69 6.2 Required Support .............................................16
70 6.3 Lock Tokens ..................................................16
71 6.4 opaquelocktoken Lock Token URI Scheme ........................16
72 6.4.1 Node Field Generation Without the IEEE 802 Address ........17
73 6.5 Lock Capability Discovery ....................................19
74 6.6 Active Lock Discovery ........................................19
75 6.7 Usage Considerations .........................................19
76 7 WRITE LOCK ......................................................20
77 7.1 Methods Restricted by Write Locks ............................20
78 7.2 Write Locks and Lock Tokens ..................................20
79 7.3 Write Locks and Properties ...................................20
80 7.4 Write Locks and Null Resources ...............................21
81 7.5 Write Locks and Collections ..................................21
82 7.6 Write Locks and the If Request Header ........................22
83 7.6.1 Example - Write Lock ......................................22
84 7.7 Write Locks and COPY/MOVE ....................................23
85 7.8 Refreshing Write Locks .......................................23
86 8 HTTP METHODS FOR DISTRIBUTED AUTHORING ..........................23
87 8.1 PROPFIND .....................................................24
88 8.1.1 Example - Retrieving Named Properties .....................25
89 8.1.2 Example - Using allprop to Retrieve All Properties ........26
90 8.1.3 Example - Using propname to Retrieve all Property Names ...29
91 8.2 PROPPATCH ....................................................31
92 8.2.1 Status Codes for use with 207 (Multi-Status) ..............31
93 8.2.2 Example - PROPPATCH .......................................32
94 8.3 MKCOL Method .................................................33
95 8.3.1 Request ...................................................33
96 8.3.2 Status Codes ..............................................33
97 8.3.3 Example - MKCOL ...........................................34
98 8.4 GET, HEAD for Collections ....................................34
99 8.5 POST for Collections .........................................35
100 8.6 DELETE .......................................................35
101 8.6.1 DELETE for Non-Collection Resources .......................35
102 8.6.2 DELETE for Collections ....................................36
103 8.7 PUT ..........................................................36
104 8.7.1 PUT for Non-Collection Resources ..........................36
105 8.7.2 PUT for Collections .......................................37
106 8.8 COPY Method ..................................................37
107 8.8.1 COPY for HTTP/1.1 resources ...............................37
108 8.8.2 COPY for Properties .......................................38
109 8.8.3 COPY for Collections ......................................38
110 8.8.4 COPY and the Overwrite Header .............................39
114 Goland, et al. Standards Track [Page 2]
116 RFC 2518 WEBDAV February 1999
119 8.8.5 Status Codes ..............................................39
120 8.8.6 Example - COPY with Overwrite .............................40
121 8.8.7 Example - COPY with No Overwrite ..........................40
122 8.8.8 Example - COPY of a Collection ............................41
123 8.9 MOVE Method ..................................................42
124 8.9.1 MOVE for Properties .......................................42
125 8.9.2 MOVE for Collections ......................................42
126 8.9.3 MOVE and the Overwrite Header .............................43
127 8.9.4 Status Codes ..............................................43
128 8.9.5 Example - MOVE of a Non-Collection ........................44
129 8.9.6 Example - MOVE of a Collection ............................44
130 8.10 LOCK Method ..................................................45
131 8.10.1 Operation .................................................46
132 8.10.2 The Effect of Locks on Properties and Collections .........46
133 8.10.3 Locking Replicated Resources ..............................46
134 8.10.4 Depth and Locking .........................................46
135 8.10.5 Interaction with other Methods ............................47
136 8.10.6 Lock Compatibility Table ..................................47
137 8.10.7 Status Codes ..............................................48
138 8.10.8 Example - Simple Lock Request .............................48
139 8.10.9 Example - Refreshing a Write Lock .........................49
140 8.10.10 Example - Multi-Resource Lock Request ....................50
141 8.11 UNLOCK Method ................................................51
142 8.11.1 Example - UNLOCK ..........................................52
143 9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ..........................52
144 9.1 DAV Header ...................................................52
145 9.2 Depth Header .................................................52
146 9.3 Destination Header ...........................................54
147 9.4 If Header ....................................................54
148 9.4.1 No-tag-list Production ....................................55
149 9.4.2 Tagged-list Production ....................................55
150 9.4.3 not Production ............................................56
151 9.4.4 Matching Function .........................................56
152 9.4.5 If Header and Non-DAV Compliant Proxies ...................57
153 9.5 Lock-Token Header ............................................57
154 9.6 Overwrite Header .............................................57
155 9.7 Status-URI Response Header ...................................57
156 9.8 Timeout Request Header .......................................58
157 10 STATUS CODE EXTENSIONS TO HTTP/1.1 ............................59
158 10.1 102 Processing ...............................................59
159 10.2 207 Multi-Status .............................................59
160 10.3 422 Unprocessable Entity .....................................60
161 10.4 423 Locked ...................................................60
162 10.5 424 Failed Dependency ........................................60
163 10.6 507 Insufficient Storage .....................................60
164 11 MULTI-STATUS RESPONSE .........................................60
165 12 XML ELEMENT DEFINITIONS .......................................61
166 12.1 activelock XML Element .......................................61
170 Goland, et al. Standards Track [Page 3]
172 RFC 2518 WEBDAV February 1999
175 12.1.1 depth XML Element .........................................61
176 12.1.2 locktoken XML Element .....................................61
177 12.1.3 timeout XML Element .......................................61
178 12.2 collection XML Element .......................................62
179 12.3 href XML Element .............................................62
180 12.4 link XML Element .............................................62
181 12.4.1 dst XML Element ...........................................62
182 12.4.2 src XML Element ...........................................62
183 12.5 lockentry XML Element ........................................63
184 12.6 lockinfo XML Element .........................................63
185 12.7 lockscope XML Element ........................................63
186 12.7.1 exclusive XML Element .....................................63
187 12.7.2 shared XML Element ........................................63
188 12.8 locktype XML Element .........................................64
189 12.8.1 write XML Element .........................................64
190 12.9 multistatus XML Element ......................................64
191 12.9.1 response XML Element ......................................64
192 12.9.2 responsedescription XML Element ...........................65
193 12.10 owner XML Element ...........................................65
194 12.11 prop XML element ............................................66
195 12.12 propertybehavior XML element ................................66
196 12.12.1 keepalive XML element ....................................66
197 12.12.2 omit XML element .........................................67
198 12.13 propertyupdate XML element ..................................67
199 12.13.1 remove XML element .......................................67
200 12.13.2 set XML element ..........................................67
201 12.14 propfind XML Element ........................................68
202 12.14.1 allprop XML Element ......................................68
203 12.14.2 propname XML Element .....................................68
204 13 DAV PROPERTIES ................................................68
205 13.1 creationdate Property ........................................69
206 13.2 displayname Property .........................................69
207 13.3 getcontentlanguage Property ..................................69
208 13.4 getcontentlength Property ....................................69
209 13.5 getcontenttype Property ......................................70
210 13.6 getetag Property .............................................70
211 13.7 getlastmodified Property .....................................70
212 13.8 lockdiscovery Property .......................................71
213 13.8.1 Example - Retrieving the lockdiscovery Property ...........71
214 13.9 resourcetype Property ........................................72
215 13.10 source Property .............................................72
216 13.10.1 Example - A source Property ..............................72
217 13.11 supportedlock Property ......................................73
218 13.11.1 Example - Retrieving the supportedlock Property ..........73
219 14 INSTRUCTIONS FOR PROCESSING XML IN DAV ........................74
220 15 DAV COMPLIANCE CLASSES ........................................75
221 15.1 Class 1 ......................................................75
222 15.2 Class 2 ......................................................75
226 Goland, et al. Standards Track [Page 4]
228 RFC 2518 WEBDAV February 1999
231 16 INTERNATIONALIZATION CONSIDERATIONS ...........................76
232 17 SECURITY CONSIDERATIONS .......................................77
233 17.1 Authentication of Clients ....................................77
234 17.2 Denial of Service ............................................78
235 17.3 Security through Obscurity ...................................78
236 17.4 Privacy Issues Connected to Locks ............................78
237 17.5 Privacy Issues Connected to Properties .......................79
238 17.6 Reduction of Security due to Source Link .....................79
239 17.7 Implications of XML External Entities ........................79
240 17.8 Risks Connected with Lock Tokens .............................80
241 18 IANA CONSIDERATIONS ...........................................80
242 19 INTELLECTUAL PROPERTY .........................................81
243 20 ACKNOWLEDGEMENTS ..............................................82
244 21 REFERENCES ....................................................82
245 21.1 Normative References .........................................82
246 21.2 Informational References .....................................83
247 22 AUTHORS' ADDRESSES ............................................84
248 23 APPENDICES ....................................................86
249 23.1 Appendix 1 - WebDAV Document Type Definition .................86
250 23.2 Appendix 2 - ISO 8601 Date and Time Profile ..................88
251 23.3 Appendix 3 - Notes on Processing XML Elements ................89
252 23.3.1 Notes on Empty XML Elements ...............................89
253 23.3.2 Notes on Illegal XML Processing ...........................89
254 23.4 Appendix 4 -- XML Namespaces for WebDAV ......................92
255 23.4.1 Introduction ..............................................92
256 23.4.2 Meaning of Qualified Names ................................92
257 24 FULL COPYRIGHT STATEMENT ......................................94
263 This document describes an extension to the HTTP/1.1 protocol that
264 allows clients to perform remote web content authoring operations.
265 This extension provides a coherent set of methods, headers, request
266 entity body formats, and response entity body formats that provide
269 Properties: The ability to create, remove, and query information
270 about Web pages, such as their authors, creation dates, etc. Also,
271 the ability to link pages of any media type to related pages.
273 Collections: The ability to create sets of documents and to retrieve
274 a hierarchical membership listing (like a directory listing in a file
282 Goland, et al. Standards Track [Page 5]
284 RFC 2518 WEBDAV February 1999
287 Locking: The ability to keep more than one person from working on a
288 document at the same time. This prevents the "lost update problem,"
289 in which modifications are lost as first one author then another
290 writes changes without merging the other author's changes.
292 Namespace Operations: The ability to instruct the server to copy and
295 Requirements and rationale for these operations are described in a
296 companion document, "Requirements for a Distributed Authoring and
297 Versioning Protocol for the World Wide Web" [RFC2291].
299 The sections below provide a detailed introduction to resource
300 properties (section 4), collections of resources (section 5), and
301 locking operations (section 6). These sections introduce the
302 abstractions manipulated by the WebDAV-specific HTTP methods
303 described in section 8, "HTTP Methods for Distributed Authoring".
305 In HTTP/1.1, method parameter information was exclusively encoded in
306 HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter
307 information either in an Extensible Markup Language (XML) [REC-XML]
308 request entity body, or in an HTTP header. The use of XML to encode
309 method parameters was motivated by the ability to add extra XML
310 elements to existing structures, providing extensibility; and by
311 XML's ability to encode information in ISO 10646 character sets,
312 providing internationalization support. As a rule of thumb,
313 parameters are encoded in XML entity bodies when they have unbounded
314 length, or when they may be shown to a human user and hence require
315 encoding in an ISO 10646 character set. Otherwise, parameters are
316 encoded within HTTP headers. Section 9 describes the new HTTP
317 headers used with WebDAV methods.
319 In addition to encoding method parameters, XML is used in WebDAV to
320 encode the responses from methods, providing the extensibility and
321 internationalization advantages of XML for method output, as well as
324 XML elements used in this specification are defined in section 12.
326 The XML namespace extension (Appendix 4) is also used in this
327 specification in order to allow for new XML elements to be added
328 without fear of colliding with other element names.
330 While the status codes provided by HTTP/1.1 are sufficient to
331 describe most error conditions encountered by WebDAV methods, there
332 are some errors that do not fall neatly into the existing categories.
333 New status codes developed for the WebDAV methods are defined in
334 section 10. Since some WebDAV methods may operate over many
338 Goland, et al. Standards Track [Page 6]
340 RFC 2518 WEBDAV February 1999
343 resources, the Multi-Status response has been introduced to return
344 status information for multiple resources. The Multi-Status response
345 is described in section 11.
347 WebDAV employs the property mechanism to store information about the
348 current state of the resource. For example, when a lock is taken out
349 on a resource, a lock information property describes the current
350 state of the lock. Section 13 defines the properties used within the
351 WebDAV specification.
353 Finishing off the specification are sections on what it means to be
354 compliant with this specification (section 15), on
355 internationalization support (section 16), and on security (section
358 2 Notational Conventions
360 Since this document describes a set of extensions to the HTTP/1.1
361 protocol, the augmented BNF used herein to describe protocol elements
362 is exactly the same as described in section 2.1 of [RFC2068]. Since
363 this augmented BNF uses the basic production rules provided in
364 section 2.2 of [RFC2068], these rules apply to this document as well.
366 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
367 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
368 document are to be interpreted as described in RFC 2119 [RFC2119].
372 URI/URL - A Uniform Resource Identifier and Uniform Resource Locator,
373 respectively. These terms (and the distinction between them) are
374 defined in [RFC2396].
376 Collection - A resource that contains a set of URIs, termed member
377 URIs, which identify member resources and meets the requirements in
378 section 5 of this specification.
380 Member URI - A URI which is a member of the set of URIs contained by
383 Internal Member URI - A Member URI that is immediately relative to
384 the URI of the collection (the definition of immediately relative is
385 given in section 5.2).
387 Property - A name/value pair that contains descriptive information
394 Goland, et al. Standards Track [Page 7]
396 RFC 2518 WEBDAV February 1999
399 Live Property - A property whose semantics and syntax are enforced by
400 the server. For example, the live "getcontentlength" property has
401 its value, the length of the entity returned by a GET request,
402 automatically calculated by the server.
404 Dead Property - A property whose semantics and syntax are not
405 enforced by the server. The server only records the value of a dead
406 property; the client is responsible for maintaining the consistency
407 of the syntax and semantics of a dead property.
409 Null Resource - A resource which responds with a 404 (Not Found) to
410 any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK.
411 A NULL resource MUST NOT appear as a member of its parent collection.
413 4 Data Model for Resource Properties
415 4.1 The Resource Property Model
417 Properties are pieces of data that describe the state of a resource.
418 Properties are data about data.
420 Properties are used in distributed authoring environments to provide
421 for efficient discovery and management of resources. For example, a
422 'subject' property might allow for the indexing of all resources by
423 their subject, and an 'author' property might allow for the discovery
424 of what authors have written which documents.
426 The DAV property model consists of name/value pairs. The name of a
427 property identifies the property's syntax and semantics, and provides
428 an address by which to refer to its syntax and semantics.
430 There are two categories of properties: "live" and "dead". A live
431 property has its syntax and semantics enforced by the server. Live
432 properties include cases where a) the value of a property is read-
433 only, maintained by the server, and b) the value of the property is
434 maintained by the client, but the server performs syntax checking on
435 submitted values. All instances of a given live property MUST comply
436 with the definition associated with that property name. A dead
437 property has its syntax and semantics enforced by the client; the
438 server merely records the value of the property verbatim.
440 4.2 Existing Metadata Proposals
442 Properties have long played an essential role in the maintenance of
443 large document repositories, and many current proposals contain some
444 notion of a property, or discuss web metadata more generally. These
445 include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several
446 proposals on representing relationships within HTML. Work on PICS-NG
450 Goland, et al. Standards Track [Page 8]
452 RFC 2518 WEBDAV February 1999
455 and Web Collections has been subsumed by the Resource Description
456 Framework (RDF) metadata activity of the World Wide Web Consortium.
457 RDF consists of a network-based data model and an XML representation
460 Some proposals come from a digital library perspective. These
461 include the Dublin Core [RFC2413] metadata set and the Warwick
462 Framework [WF], a container architecture for different metadata
463 schemas. The literature includes many examples of metadata,
464 including MARC [USMARC], a bibliographic metadata format, and a
465 technical report bibliographic format employed by the Dienst system
466 [RFC1807]. Additionally, the proceedings from the first IEEE Metadata
467 conference describe many community-specific metadata sets.
469 Participants of the 1996 Metadata II Workshop in Warwick, UK [WF],
470 noted that "new metadata sets will develop as the networked
471 infrastructure matures" and "different communities will propose,
472 design, and be responsible for different types of metadata." These
473 observations can be corroborated by noting that many community-
474 specific sets of metadata already exist, and there is significant
475 motivation for the development of new forms of metadata as many
476 communities increasingly make their data available in digital form,
477 requiring a metadata format to assist data location and cataloging.
479 4.3 Properties and HTTP Headers
481 Properties already exist, in a limited sense, in HTTP message
482 headers. However, in distributed authoring environments a relatively
483 large number of properties are needed to describe the state of a
484 resource, and setting/returning them all through HTTP headers is
485 inefficient. Thus a mechanism is needed which allows a principal to
486 identify a set of properties in which the principal is interested and
487 to set or retrieve just those properties.
491 The value of a property when expressed in XML MUST be well formed.
493 XML has been chosen because it is a flexible, self-describing,
494 structured data format that supports rich schema definitions, and
495 because of its support for multiple character sets. XML's self-
496 describing nature allows any property's value to be extended by
497 adding new elements. Older clients will not break when they
498 encounter extensions because they will still have the data specified
499 in the original schema and will ignore elements they do not
500 understand. XML's support for multiple character sets allows any
501 human-readable property to be encoded and read in a character set
502 familiar to the user. XML's support for multiple human languages,
506 Goland, et al. Standards Track [Page 9]
508 RFC 2518 WEBDAV February 1999
511 using the "xml:lang" attribute, handles cases where the same
512 character set is employed by multiple human languages.
516 A property name is a universally unique identifier that is associated
517 with a schema that provides information about the syntax and
518 semantics of the property.
520 Because a property's name is universally unique, clients can depend
521 upon consistent behavior for a particular property across multiple
522 resources, on the same and across different servers, so long as that
523 property is "live" on the resources in question, and the
524 implementation of the live property is faithful to its definition.
526 The XML namespace mechanism, which is based on URIs [RFC2396], is
527 used to name properties because it prevents namespace collisions and
528 provides for varying degrees of administrative control.
530 The property namespace is flat; that is, no hierarchy of properties
531 is explicitly recognized. Thus, if a property A and a property A/B
532 exist on a resource, there is no recognition of any relationship
533 between the two properties. It is expected that a separate
534 specification will eventually be produced which will address issues
535 relating to hierarchical properties.
537 Finally, it is not possible to define the same property twice on a
538 single resource, as this would cause a collision in the resource's
541 4.6 Media Independent Links
543 Although HTML resources support links to other resources, the Web
544 needs more general support for links between resources of any media
545 type (media types are also known as MIME types, or content types).
546 WebDAV provides such links. A WebDAV link is a special type of
547 property value, formally defined in section 12.4, that allows typed
548 connections to be established between resources of any media type.
549 The property value consists of source and destination Uniform
550 Resource Identifiers (URIs); the property name identifies the link
562 Goland, et al. Standards Track [Page 10]
564 RFC 2518 WEBDAV February 1999
567 5 Collections of Web Resources
569 This section provides a description of a new type of Web resource,
570 the collection, and discusses its interactions with the HTTP URL
571 namespace. The purpose of a collection resource is to model
572 collection-like objects (e.g., file system directories) within a
575 All DAV compliant resources MUST support the HTTP URL namespace model
578 5.1 HTTP URL Namespace Model
580 The HTTP URL namespace is a hierarchical namespace where the
581 hierarchy is delimited with the "/" character.
583 An HTTP URL namespace is said to be consistent if it meets the
584 following conditions: for every URL in the HTTP hierarchy there
585 exists a collection that contains that URL as an internal member.
586 The root, or top-level collection of the namespace under
587 consideration is exempt from the previous rule.
589 Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL
590 namespace be consistent. However, certain WebDAV methods are
591 prohibited from producing results that cause namespace
594 Although implicit in [RFC2068] and [RFC2396], any resource, including
595 collection resources, MAY be identified by more than one URI. For
596 example, a resource could be identified by multiple HTTP URLs.
598 5.2 Collection Resources
600 A collection is a resource whose state consists of at least a list of
601 internal member URIs and a set of properties, but which may have
602 additional state such as entity bodies returned by GET. An internal
603 member URI MUST be immediately relative to a base URI of the
604 collection. That is, the internal member URI is equal to a
605 containing collection's URI plus an additional segment for non-
606 collection resources, or additional segment plus trailing slash "/"
607 for collection resources, where segment is defined in section 3.3 of
610 Any given internal member URI MUST only belong to the collection
611 once, i.e., it is illegal to have multiple instances of the same URI
612 in a collection. Properties defined on collections behave exactly as
613 do properties on non-collection resources.
618 Goland, et al. Standards Track [Page 11]
620 RFC 2518 WEBDAV February 1999
623 For all WebDAV compliant resources A and B, identified by URIs U and
624 V, for which U is immediately relative to V, B MUST be a collection
625 that has U as an internal member URI. So, if the resource with URL
626 http://foo.com/bar/blah is WebDAV compliant and if the resource with
627 URL http://foo.com/bar/ is WebDAV compliant then the resource with
628 URL http://foo.com/bar/ must be a collection and must contain URL
629 http://foo.com/bar/blah as an internal member.
631 Collection resources MAY list the URLs of non-WebDAV compliant
632 children in the HTTP URL namespace hierarchy as internal members but
633 are not required to do so. For example, if the resource with URL
634 http://foo.com/bar/blah is not WebDAV compliant and the URL
635 http://foo.com/bar/ identifies a collection then URL
636 http://foo.com/bar/blah may or may not be an internal member of the
637 collection with URL http://foo.com/bar/.
639 If a WebDAV compliant resource has no WebDAV compliant children in
640 the HTTP URL namespace hierarchy then the WebDAV compliant resource
641 is not required to be a collection.
643 There is a standing convention that when a collection is referred to
644 by its name without a trailing slash, the trailing slash is
645 automatically appended. Due to this, a resource may accept a URI
646 without a trailing "/" to point to a collection. In this case it
647 SHOULD return a content-location header in the response pointing to
648 the URI ending with the "/". For example, if a client invokes a
649 method on http://foo.bar/blah (no trailing slash), the resource
650 http://foo.bar/blah/ (trailing slash) may respond as if the operation
651 were invoked on it, and should return a content-location header with
652 http://foo.bar/blah/ in it. In general clients SHOULD use the "/"
653 form of collection names.
655 A resource MAY be a collection but not be WebDAV compliant. That is,
656 the resource may comply with all the rules set out in this
657 specification regarding how a collection is to behave without
658 necessarily supporting all methods that a WebDAV compliant resource
659 is required to support. In such a case the resource may return the
660 DAV:resourcetype property with the value DAV:collection but MUST NOT
661 return a DAV header containing the value "1" on an OPTIONS response.
663 5.3 Creation and Retrieval of Collection Resources
665 This document specifies the MKCOL method to create new collection
666 resources, rather than using the existing HTTP/1.1 PUT or POST
667 method, for the following reasons:
674 Goland, et al. Standards Track [Page 12]
676 RFC 2518 WEBDAV February 1999
679 In HTTP/1.1, the PUT method is defined to store the request body at
680 the location specified by the Request-URI. While a description
681 format for a collection can readily be constructed for use with PUT,
682 the implications of sending such a description to the server are
683 undesirable. For example, if a description of a collection that
684 omitted some existing resources were PUT to a server, this might be
685 interpreted as a command to remove those members. This would extend
686 PUT to perform DELETE functionality, which is undesirable since it
687 changes the semantics of PUT, and makes it difficult to control
688 DELETE functionality with an access control scheme based on methods.
690 While the POST method is sufficiently open-ended that a "create a
691 collection" POST command could be constructed, this is undesirable
692 because it would be difficult to separate access control for
693 collection creation from other uses of POST.
695 The exact definition of the behavior of GET and PUT on collections is
696 defined later in this document.
698 5.4 Source Resources and Output Resources
700 For many resources, the entity returned by a GET method exactly
701 matches the persistent state of the resource, for example, a GIF file
702 stored on a disk. For this simple case, the URI at which a resource
703 is accessed is identical to the URI at which the source (the
704 persistent state) of the resource is accessed. This is also the case
705 for HTML source files that are not processed by the server prior to
708 However, the server can sometimes process HTML resources before they
709 are transmitted as a return entity body. For example, a server-
710 side-include directive within an HTML file might instruct a server to
711 replace the directive with another value, such as the current date.
712 In this case, what is returned by GET (HTML plus date) differs from
713 the persistent state of the resource (HTML plus directive).
714 Typically there is no way to access the HTML resource containing the
715 unprocessed directive.
717 Sometimes the entity returned by GET is the output of a data-
718 producing process that is described by one or more source resources
719 (that may not even have a location in the URI namespace). A single
720 data-producing process may dynamically generate the state of a
721 potentially large number of output resources. An example of this is
722 a CGI script that describes a "finger" gateway process that maps part
723 of the namespace of a server into finger requests, such as
724 http://www.foo.bar.org/finger_gateway/user@host.
730 Goland, et al. Standards Track [Page 13]
732 RFC 2518 WEBDAV February 1999
735 In the absence of distributed authoring capabilities, it is
736 acceptable to have no mapping of source resource(s) to the URI
737 namespace. In fact, preventing access to the source resource(s) has
738 desirable security benefits. However, if remote editing of the
739 source resource(s) is desired, the source resource(s) should be given
740 a location in the URI namespace. This source location should not be
741 one of the locations at which the generated output is retrievable,
742 since in general it is impossible for the server to differentiate
743 requests for source resources from requests for process output
744 resources. There is often a many-to-many relationship between source
745 resources and output resources.
747 On WebDAV compliant servers the URI of the source resource(s) may be
748 stored in a link on the output resource with type DAV:source (see
749 section 13.10 for a description of the source link property).
750 Storing the source URIs in links on the output resources places the
751 burden of discovering the source on the authoring client. Note that
752 the value of a source link is not guaranteed to point to the correct
753 source. Source links may break or incorrect values may be entered.
754 Also note that not all servers will allow the client to set the
755 source link value. For example a server which generates source links
756 on the fly for its CGI files will most likely not allow a client to
757 set the source link value.
761 The ability to lock a resource provides a mechanism for serializing
762 access to that resource. Using a lock, an authoring client can
763 provide a reasonable guarantee that another principal will not modify
764 a resource while it is being edited. In this way, a client can
765 prevent the "lost update" problem.
767 This specification allows locks to vary over two client-specified
768 parameters, the number of principals involved (exclusive vs. shared)
769 and the type of access to be granted. This document defines locking
770 for only one access type, write. However, the syntax is extensible,
771 and permits the eventual specification of locking for other access
774 6.1 Exclusive Vs. Shared Locks
776 The most basic form of lock is an exclusive lock. This is a lock
777 where the access right in question is only granted to a single
778 principal. The need for this arbitration results from a desire to
779 avoid having to merge results.
786 Goland, et al. Standards Track [Page 14]
788 RFC 2518 WEBDAV February 1999
791 However, there are times when the goal of a lock is not to exclude
792 others from exercising an access right but rather to provide a
793 mechanism for principals to indicate that they intend to exercise
794 their access rights. Shared locks are provided for this case. A
795 shared lock allows multiple principals to receive a lock. Hence any
796 principal with appropriate access can get the lock.
798 With shared locks there are two trust sets that affect a resource.
799 The first trust set is created by access permissions. Principals who
800 are trusted, for example, may have permission to write to the
801 resource. Among those who have access permission to write to the
802 resource, the set of principals who have taken out a shared lock also
803 must trust each other, creating a (typically) smaller trust set
804 within the access permission write set.
806 Starting with every possible principal on the Internet, in most
807 situations the vast majority of these principals will not have write
808 access to a given resource. Of the small number who do have write
809 access, some principals may decide to guarantee their edits are free
810 from overwrite conflicts by using exclusive write locks. Others may
811 decide they trust their collaborators will not overwrite their work
812 (the potential set of collaborators being the set of principals who
813 have write permission) and use a shared lock, which informs their
814 collaborators that a principal may be working on the resource.
816 The WebDAV extensions to HTTP do not need to provide all of the
817 communications paths necessary for principals to coordinate their
818 activities. When using shared locks, principals may use any out of
819 band communication channel to coordinate their work (e.g., face-to-
820 face interaction, written notes, post-it notes on the screen,
821 telephone conversation, Email, etc.) The intent of a shared lock is
822 to let collaborators know who else may be working on a resource.
824 Shared locks are included because experience from web distributed
825 authoring systems has indicated that exclusive locks are often too
826 rigid. An exclusive lock is used to enforce a particular editing
827 process: take out an exclusive lock, read the resource, perform
828 edits, write the resource, release the lock. This editing process
829 has the problem that locks are not always properly released, for
830 example when a program crashes, or when a lock owner leaves without
831 unlocking a resource. While both timeouts and administrative action
832 can be used to remove an offending lock, neither mechanism may be
833 available when needed; the timeout may be long or the administrator
834 may not be available.
842 Goland, et al. Standards Track [Page 15]
844 RFC 2518 WEBDAV February 1999
849 A WebDAV compliant server is not required to support locking in any
850 form. If the server does support locking it may choose to support
851 any combination of exclusive and shared locks for any access types.
853 The reason for this flexibility is that locking policy strikes to the
854 very heart of the resource management and versioning systems employed
855 by various storage repositories. These repositories require control
856 over what sort of locking will be made available. For example, some
857 repositories only support shared write locks while others only
858 provide support for exclusive write locks while yet others use no
859 locking at all. As each system is sufficiently different to merit
860 exclusion of certain locking features, this specification leaves
861 locking as the sole axis of negotiation within WebDAV.
865 A lock token is a type of state token, represented as a URI, which
866 identifies a particular lock. A lock token is returned by every
867 successful LOCK operation in the lockdiscovery property in the
868 response body, and can also be found through lock discovery on a
871 Lock token URIs MUST be unique across all resources for all time.
872 This uniqueness constraint allows lock tokens to be submitted across
873 resources and servers without fear of confusion.
875 This specification provides a lock token URI scheme called
876 opaquelocktoken that meets the uniqueness requirements. However
877 resources are free to return any URI scheme so long as it meets the
878 uniqueness requirements.
880 Having a lock token provides no special access rights. Anyone can
881 find out anyone else's lock token by performing lock discovery.
882 Locks MUST be enforced based upon whatever authentication mechanism
883 is used by the server, not based on the secrecy of the token values.
885 6.4 opaquelocktoken Lock Token URI Scheme
887 The opaquelocktoken URI scheme is designed to be unique across all
888 resources for all time. Due to this uniqueness quality, a client may
889 submit an opaque lock token in an If header on a resource other than
890 the one that returned it.
892 All resources MUST recognize the opaquelocktoken scheme and, at
893 minimum, recognize that the lock token does not refer to an
894 outstanding lock on the resource.
898 Goland, et al. Standards Track [Page 16]
900 RFC 2518 WEBDAV February 1999
903 In order to guarantee uniqueness across all resources for all time
904 the opaquelocktoken requires the use of the Universal Unique
905 Identifier (UUID) mechanism, as described in [ISO-11578].
907 Opaquelocktoken generators, however, have a choice of how they create
908 these tokens. They can either generate a new UUID for every lock
909 token they create or they can create a single UUID and then add
910 extension characters. If the second method is selected then the
911 program generating the extensions MUST guarantee that the same
912 extension will never be used twice with the associated UUID.
914 OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID
915 production is the string representation of a UUID, as defined in
916 [ISO-11578]. Note that white space (LWS) is not allowed between
917 elements of this production.
919 Extension = path ; path is defined in section 3.2.1 of RFC 2068
922 6.4.1 Node Field Generation Without the IEEE 802 Address
924 UUIDs, as defined in [ISO-11578], contain a "node" field that
925 contains one of the IEEE 802 addresses for the server machine. As
926 noted in section 17.8, there are several security risks associated
927 with exposing a machine's IEEE 802 address. This section provides an
928 alternate mechanism for generating the "node" field of a UUID which
929 does not employ an IEEE 802 address. WebDAV servers MAY use this
930 algorithm for creating the node field when generating UUIDs. The
931 text in this section is originally from an Internet-Draft by Paul
932 Leach and Rich Salz, who are noted here to properly attribute their
935 The ideal solution is to obtain a 47 bit cryptographic quality random
936 number, and use it as the low 47 bits of the node ID, with the most
937 significant bit of the first octet of the node ID set to 1. This bit
938 is the unicast/multicast bit, which will never be set in IEEE 802
939 addresses obtained from network cards; hence, there can never be a
940 conflict between UUIDs generated by machines with and without network
943 If a system does not have a primitive to generate cryptographic
944 quality random numbers, then in most systems there are usually a
945 fairly large number of sources of randomness available from which one
946 can be generated. Such sources are system specific, but often
954 Goland, et al. Standards Track [Page 17]
956 RFC 2518 WEBDAV February 1999
959 - the percent of memory in use
960 - the size of main memory in bytes
961 - the amount of free main memory in bytes
962 - the size of the paging or swap file in bytes
963 - free bytes of paging or swap file
964 - the total size of user virtual address space in bytes
965 - the total available user address space bytes
966 - the size of boot disk drive in bytes
967 - the free disk space on boot drive in bytes
969 - the amount of time since the system booted
970 - the individual sizes of files in various system directories
971 - the creation, last read, and modification times of files in
972 various system directories
973 - the utilization factors of various system resources (heap, etc.)
974 - current mouse cursor position
975 - current caret position
976 - current number of running processes, threads
977 - handles or IDs of the desktop window and the active window
978 - the value of stack pointer of the caller
979 - the process and thread ID of caller
980 - various processor architecture specific performance counters
981 (instructions executed, cache misses, TLB misses)
983 (Note that it is precisely the above kinds of sources of randomness
984 that are used to seed cryptographic quality random number generators
985 on systems without special hardware for their construction.)
987 In addition, items such as the computer's name and the name of the
988 operating system, while not strictly speaking random, will help
989 differentiate the results from those obtained by other systems.
991 The exact algorithm to generate a node ID using these data is system
992 specific, because both the data available and the functions to obtain
993 them are often very system specific. However, assuming that one can
994 concatenate all the values from the randomness sources into a buffer,
995 and that a cryptographic hash function such as MD5 is available, then
996 any 6 bytes of the MD5 hash of the buffer, with the multicast bit
997 (the high bit of the first byte) set will be an appropriately random
1000 Other hash functions, such as SHA-1, can also be used. The only
1001 requirement is that the result be suitably random _ in the sense that
1002 the outputs from a set uniformly distributed inputs are themselves
1003 uniformly distributed, and that a single bit change in the input can
1004 be expected to cause half of the output bits to change.
1010 Goland, et al. Standards Track [Page 18]
1012 RFC 2518 WEBDAV February 1999
1015 6.5 Lock Capability Discovery
1017 Since server lock support is optional, a client trying to lock a
1018 resource on a server can either try the lock and hope for the best,
1019 or perform some form of discovery to determine what lock capabilities
1020 the server supports. This is known as lock capability discovery.
1021 Lock capability discovery differs from discovery of supported access
1022 control types, since there may be access control types without
1023 corresponding lock types. A client can determine what lock types the
1024 server supports by retrieving the supportedlock property.
1026 Any DAV compliant resource that supports the LOCK method MUST support
1027 the supportedlock property.
1029 6.6 Active Lock Discovery
1031 If another principal locks a resource that a principal wishes to
1032 access, it is useful for the second principal to be able to find out
1033 who the first principal is. For this purpose the lockdiscovery
1034 property is provided. This property lists all outstanding locks,
1035 describes their type, and where available, provides their lock token.
1037 Any DAV compliant resource that supports the LOCK method MUST support
1038 the lockdiscovery property.
1040 6.7 Usage Considerations
1042 Although the locking mechanisms specified here provide some help in
1043 preventing lost updates, they cannot guarantee that updates will
1044 never be lost. Consider the following scenario:
1046 Two clients A and B are interested in editing the resource '
1047 index.html'. Client A is an HTTP client rather than a WebDAV client,
1048 and so does not know how to perform locking.
1049 Client A doesn't lock the document, but does a GET and begins
1051 Client B does LOCK, performs a GET and begins editing.
1052 Client B finishes editing, performs a PUT, then an UNLOCK.
1053 Client A performs a PUT, overwriting and losing all of B's changes.
1055 There are several reasons why the WebDAV protocol itself cannot
1056 prevent this situation. First, it cannot force all clients to use
1057 locking because it must be compatible with HTTP clients that do not
1058 comprehend locking. Second, it cannot require servers to support
1059 locking because of the variety of repository implementations, some of
1060 which rely on reservations and merging rather than on locking.
1061 Finally, being stateless, it cannot enforce a sequence of operations
1062 like LOCK / GET / PUT / UNLOCK.
1066 Goland, et al. Standards Track [Page 19]
1068 RFC 2518 WEBDAV February 1999
1071 WebDAV servers that support locking can reduce the likelihood that
1072 clients will accidentally overwrite each other's changes by requiring
1073 clients to lock resources before modifying them. Such servers would
1074 effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying
1077 WebDAV clients can be good citizens by using a lock / retrieve /
1078 write /unlock sequence of operations (at least by default) whenever
1079 they interact with a WebDAV server that supports locking.
1081 HTTP 1.1 clients can be good citizens, avoiding overwriting other
1082 clients' changes, by using entity tags in If-Match headers with any
1083 requests that would modify resources.
1085 Information managers may attempt to prevent overwrites by
1086 implementing client-side procedures requiring locking before
1087 modifying WebDAV resources.
1091 This section describes the semantics specific to the write lock type.
1092 The write lock is a specific instance of a lock type, and is the only
1093 lock type described in this specification.
1095 7.1 Methods Restricted by Write Locks
1097 A write lock MUST prevent a principal without the lock from
1098 successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE,
1099 DELETE, or MKCOL on the locked resource. All other current methods,
1100 GET in particular, function independently of the lock.
1102 Note, however, that as new methods are created it will be necessary
1103 to specify how they interact with a write lock.
1105 7.2 Write Locks and Lock Tokens
1107 A successful request for an exclusive or shared write lock MUST
1108 result in the generation of a unique lock token associated with the
1109 requesting principal. Thus if five principals have a shared write
1110 lock on the same resource there will be five lock tokens, one for
1113 7.3 Write Locks and Properties
1115 While those without a write lock may not alter a property on a
1116 resource it is still possible for the values of live properties to
1117 change, even while locked, due to the requirements of their schemas.
1122 Goland, et al. Standards Track [Page 20]
1124 RFC 2518 WEBDAV February 1999
1127 Only dead properties and live properties defined to respect locks are
1128 guaranteed not to change while write locked.
1130 7.4 Write Locks and Null Resources
1132 It is possible to assert a write lock on a null resource in order to
1135 A write locked null resource, referred to as a lock-null resource,
1136 MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to
1137 any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND,
1138 LOCK, and UNLOCK. A lock-null resource MUST appear as a member of
1139 its parent collection. Additionally the lock-null resource MUST have
1140 defined on it all mandatory DAV properties. Most of these
1141 properties, such as all the get* properties, will have no value as a
1142 lock-null resource does not support the GET method. Lock-Null
1143 resources MUST have defined values for lockdiscovery and
1144 supportedlock properties.
1146 Until a method such as PUT or MKCOL is successfully executed on the
1147 lock-null resource the resource MUST stay in the lock-null state.
1148 However, once a PUT or MKCOL is successfully executed on a lock-null
1149 resource the resource ceases to be in the lock-null state.
1151 If the resource is unlocked, for any reason, without a PUT, MKCOL, or
1152 similar method having been successfully executed upon it then the
1153 resource MUST return to the null state.
1155 7.5 Write Locks and Collections
1157 A write lock on a collection, whether created by a "Depth: 0" or
1158 "Depth: infinity" lock request, prevents the addition or removal of
1159 member URIs of the collection by non-lock owners. As a consequence,
1160 when a principal issues a PUT or POST request to create a new
1161 resource under a URI which needs to be an internal member of a write
1162 locked collection to maintain HTTP namespace consistency, or issues a
1163 DELETE to remove a resource which has a URI which is an existing
1164 internal member URI of a write locked collection, this request MUST
1165 fail if the principal does not have a write lock on the collection.
1167 However, if a write lock request is issued to a collection containing
1168 member URIs identifying resources that are currently locked in a
1169 manner which conflicts with the write lock, the request MUST fail
1170 with a 423 (Locked) status code.
1172 If a lock owner causes the URI of a resource to be added as an
1173 internal member URI of a locked collection then the new resource MUST
1174 be automatically added to the lock. This is the only mechanism that
1178 Goland, et al. Standards Track [Page 21]
1180 RFC 2518 WEBDAV February 1999
1183 allows a resource to be added to a write lock. Thus, for example, if
1184 the collection /a/b/ is write locked and the resource /c is moved to
1185 /a/b/c then resource /a/b/c will be added to the write lock.
1187 7.6 Write Locks and the If Request Header
1189 If a user agent is not required to have knowledge about a lock when
1190 requesting an operation on a locked resource, the following scenario
1191 might occur. Program A, run by User A, takes out a write lock on a
1192 resource. Program B, also run by User A, has no knowledge of the
1193 lock taken out by Program A, yet performs a PUT to the locked
1194 resource. In this scenario, the PUT succeeds because locks are
1195 associated with a principal, not a program, and thus program B,
1196 because it is acting with principal A's credential, is allowed to
1197 perform the PUT. However, had program B known about the lock, it
1198 would not have overwritten the resource, preferring instead to
1199 present a dialog box describing the conflict to the user. Due to
1200 this scenario, a mechanism is needed to prevent different programs
1201 from accidentally ignoring locks taken out by other programs with the
1204 In order to prevent these collisions a lock token MUST be submitted
1205 by an authorized principal in the If header for all locked resources
1206 that a method may interact with or the method MUST fail. For
1207 example, if a resource is to be moved and both the source and
1208 destination are locked then two lock tokens must be submitted, one
1209 for the source and the other for the destination.
1211 7.6.1 Example - Write Lock
1215 COPY /~fielding/index.html HTTP/1.1
1216 Host: www.ics.uci.edu
1217 Destination: http://www.ics.uci.edu/users/f/fielding/index.html
1218 If: <http://www.ics.uci.edu/users/f/fielding/index.html>
1219 (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
1223 HTTP/1.1 204 No Content
1225 In this example, even though both the source and destination are
1226 locked, only one lock token must be submitted, for the lock on the
1227 destination. This is because the source resource is not modified by
1228 a COPY, and hence unaffected by the write lock. In this example, user
1229 agent authentication has previously occurred via a mechanism outside
1230 the scope of the HTTP protocol, in the underlying transport layer.
1234 Goland, et al. Standards Track [Page 22]
1236 RFC 2518 WEBDAV February 1999
1239 7.7 Write Locks and COPY/MOVE
1241 A COPY method invocation MUST NOT duplicate any write locks active on
1242 the source. However, as previously noted, if the COPY copies the
1243 resource into a collection that is locked with "Depth: infinity",
1244 then the resource will be added to the lock.
1246 A successful MOVE request on a write locked resource MUST NOT move
1247 the write lock with the resource. However, the resource is subject to
1248 being added to an existing lock at the destination, as specified in
1249 section 7.5. For example, if the MOVE makes the resource a child of a
1250 collection that is locked with "Depth: infinity", then the resource
1251 will be added to that collection's lock. Additionally, if a resource
1252 locked with "Depth: infinity" is moved to a destination that is
1253 within the scope of the same lock (e.g., within the namespace tree
1254 covered by the lock), the moved resource will again be a added to the
1255 lock. In both these examples, as specified in section 7.6, an If
1256 header must be submitted containing a lock token for both the source
1259 7.8 Refreshing Write Locks
1261 A client MUST NOT submit the same write lock request twice. Note
1262 that a client is always aware it is resubmitting the same lock
1263 request because it must include the lock token in the If header in
1264 order to make the request for a resource that is already locked.
1266 However, a client may submit a LOCK method with an If header but
1267 without a body. This form of LOCK MUST only be used to "refresh" a
1268 lock. Meaning, at minimum, that any timers associated with the lock
1271 A server may return a Timeout header with a lock refresh that is
1272 different than the Timeout header returned when the lock was
1273 originally requested. Additionally clients may submit Timeout
1274 headers of arbitrary value with their lock refresh requests.
1275 Servers, as always, may ignore Timeout headers submitted by the
1278 If an error is received in response to a refresh LOCK request the
1279 client SHOULD assume that the lock was not refreshed.
1281 8 HTTP Methods for Distributed Authoring
1283 The following new HTTP methods use XML as a request and response
1284 format. All DAV compliant clients and resources MUST use XML parsers
1285 that are compliant with [REC-XML]. All XML used in either requests
1286 or responses MUST be, at minimum, well formed. If a server receives
1290 Goland, et al. Standards Track [Page 23]
1292 RFC 2518 WEBDAV February 1999
1295 ill-formed XML in a request it MUST reject the entire request with a
1296 400 (Bad Request). If a client receives ill-formed XML in a response
1297 then it MUST NOT assume anything about the outcome of the executed
1298 method and SHOULD treat the server as malfunctioning.
1302 The PROPFIND method retrieves properties defined on the resource
1303 identified by the Request-URI, if the resource does not have any
1304 internal members, or on the resource identified by the Request-URI
1305 and potentially its member resources, if the resource is a collection
1306 that has internal member URIs. All DAV compliant resources MUST
1307 support the PROPFIND method and the propfind XML element (section
1308 12.14) along with all XML elements defined for use with that element.
1310 A client may submit a Depth header with a value of "0", "1", or
1311 "infinity" with a PROPFIND on a collection resource with internal
1312 member URIs. DAV compliant servers MUST support the "0", "1" and
1313 "infinity" behaviors. By default, the PROPFIND method without a Depth
1314 header MUST act as if a "Depth: infinity" header was included.
1316 A client may submit a propfind XML element in the body of the request
1317 method describing what information is being requested. It is
1318 possible to request particular property values, all property values,
1319 or a list of the names of the resource's properties. A client may
1320 choose not to submit a request body. An empty PROPFIND request body
1321 MUST be treated as a request for the names and values of all
1324 All servers MUST support returning a response of content type
1325 text/xml or application/xml that contains a multistatus XML element
1326 that describes the results of the attempts to retrieve the various
1329 If there is an error retrieving a property then a proper error result
1330 MUST be included in the response. A request to retrieve the value of
1331 a property which does not exist is an error and MUST be noted, if the
1332 response uses a multistatus XML element, with a response XML element
1333 which contains a 404 (Not Found) status value.
1335 Consequently, the multistatus XML element for a collection resource
1336 with member URIs MUST include a response XML element for each member
1337 URI of the collection, to whatever depth was requested. Each response
1338 XML element MUST contain an href XML element that gives the URI of
1339 the resource on which the properties in the prop XML element are
1340 defined. Results for a PROPFIND on a collection resource with
1341 internal member URIs are returned as a flat list whose order of
1342 entries is not significant.
1346 Goland, et al. Standards Track [Page 24]
1348 RFC 2518 WEBDAV February 1999
1351 In the case of allprop and propname, if a principal does not have the
1352 right to know whether a particular property exists then the property
1353 should be silently excluded from the response.
1355 The results of this method SHOULD NOT be cached.
1357 8.1.1 Example - Retrieving Named Properties
1361 PROPFIND /file HTTP/1.1
1363 Content-type: text/xml; charset="utf-8"
1364 Content-Length: xxxx
1366 <?xml version="1.0" encoding="utf-8" ?>
1367 <D:propfind xmlns:D="DAV:">
1368 <D:prop xmlns:R="http://www.foo.bar/boxschema/">
1378 HTTP/1.1 207 Multi-Status
1379 Content-Type: text/xml; charset="utf-8"
1380 Content-Length: xxxx
1382 <?xml version="1.0" encoding="utf-8" ?>
1383 <D:multistatus xmlns:D="DAV:">
1385 <D:href>http://www.foo.bar/file</D:href>
1387 <D:prop xmlns:R="http://www.foo.bar/boxschema/">
1389 <R:BoxType>Box type A</R:BoxType>
1392 <R:Name>J.J. Johnson</R:Name>
1395 <D:status>HTTP/1.1 200 OK</D:status>
1398 <D:prop><R:DingALing/><R:Random/></D:prop>
1402 Goland, et al. Standards Track [Page 25]
1404 RFC 2518 WEBDAV February 1999
1407 <D:status>HTTP/1.1 403 Forbidden</D:status>
1408 <D:responsedescription> The user does not have access to
1409 the DingALing property.
1410 </D:responsedescription>
1413 <D:responsedescription> There has been an access violation error.
1414 </D:responsedescription>
1417 In this example, PROPFIND is executed on a non-collection resource
1418 http://www.foo.bar/file. The propfind XML element specifies the name
1419 of four properties whose values are being requested. In this case
1420 only two properties were returned, since the principal issuing the
1421 request did not have sufficient access rights to see the third and
1424 8.1.2 Example - Using allprop to Retrieve All Properties
1428 PROPFIND /container/ HTTP/1.1
1431 Content-Type: text/xml; charset="utf-8"
1432 Content-Length: xxxx
1434 <?xml version="1.0" encoding="utf-8" ?>
1435 <D:propfind xmlns:D="DAV:">
1441 HTTP/1.1 207 Multi-Status
1442 Content-Type: text/xml; charset="utf-8"
1443 Content-Length: xxxx
1445 <?xml version="1.0" encoding="utf-8" ?>
1446 <D:multistatus xmlns:D="DAV:">
1448 <D:href>http://www.foo.bar/container/</D:href>
1450 <D:prop xmlns:R="http://www.foo.bar/boxschema/">
1452 <R:BoxType>Box type A</R:BoxType>
1458 Goland, et al. Standards Track [Page 26]
1460 RFC 2518 WEBDAV February 1999
1463 <R:Name>Hadrian</R:Name>
1466 1997-12-01T17:42:21-08:00
1471 <D:resourcetype><D:collection/></D:resourcetype>
1474 <D:lockscope><D:exclusive/></D:lockscope>
1475 <D:locktype><D:write/></D:locktype>
1478 <D:lockscope><D:shared/></D:lockscope>
1479 <D:locktype><D:write/></D:locktype>
1483 <D:status>HTTP/1.1 200 OK</D:status>
1487 <D:href>http://www.foo.bar/container/front.html</D:href>
1489 <D:prop xmlns:R="http://www.foo.bar/boxschema/">
1491 <R:BoxType>Box type B</R:BoxType>
1494 1997-12-01T18:27:21-08:00
1497 Example HTML resource
1499 <D:getcontentlength>
1501 </D:getcontentlength>
1509 Monday, 12-Jan-98 09:25:56 GMT
1510 </D:getlastmodified>
1514 Goland, et al. Standards Track [Page 27]
1516 RFC 2518 WEBDAV February 1999
1522 <D:lockscope><D:exclusive/></D:lockscope>
1523 <D:locktype><D:write/></D:locktype>
1526 <D:lockscope><D:shared/></D:lockscope>
1527 <D:locktype><D:write/></D:locktype>
1531 <D:status>HTTP/1.1 200 OK</D:status>
1536 In this example, PROPFIND was invoked on the resource
1537 http://www.foo.bar/container/ with a Depth header of 1, meaning the
1538 request applies to the resource and its children, and a propfind XML
1539 element containing the allprop XML element, meaning the request
1540 should return the name and value of all properties defined on each
1543 The resource http://www.foo.bar/container/ has six properties defined
1546 http://www.foo.bar/boxschema/bigbox,
1547 http://www.foo.bar/boxschema/author, DAV:creationdate,
1548 DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
1550 The last four properties are WebDAV-specific, defined in section 13.
1551 Since GET is not supported on this resource, the get* properties
1552 (e.g., getcontentlength) are not defined on this resource. The DAV-
1553 specific properties assert that "container" was created on December
1554 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT
1555 (creationdate), has a name of "Example collection" (displayname), a
1556 collection resource type (resourcetype), and supports exclusive write
1557 and shared write locks (supportedlock).
1559 The resource http://www.foo.bar/container/front.html has nine
1560 properties defined on it:
1562 http://www.foo.bar/boxschema/bigbox (another instance of the "bigbox"
1563 property type), DAV:creationdate, DAV:displayname,
1564 DAV:getcontentlength, DAV:getcontenttype, DAV:getetag,
1565 DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
1570 Goland, et al. Standards Track [Page 28]
1572 RFC 2518 WEBDAV February 1999
1575 The DAV-specific properties assert that "front.html" was created on
1576 December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT
1577 (creationdate), has a name of "Example HTML resource" (displayname),
1578 a content length of 4525 bytes (getcontentlength), a MIME type of
1579 "text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was
1580 last modified on Monday, January 12, 1998, at 09:25:56 GMT
1581 (getlastmodified), has an empty resource type, meaning that it is not
1582 a collection (resourcetype), and supports both exclusive write and
1583 shared write locks (supportedlock).
1585 8.1.3 Example - Using propname to Retrieve all Property Names
1589 PROPFIND /container/ HTTP/1.1
1591 Content-Type: text/xml; charset="utf-8"
1592 Content-Length: xxxx
1594 <?xml version="1.0" encoding="utf-8" ?>
1595 <propfind xmlns="DAV:">
1601 HTTP/1.1 207 Multi-Status
1602 Content-Type: text/xml; charset="utf-8"
1603 Content-Length: xxxx
1605 <?xml version="1.0" encoding="utf-8" ?>
1606 <multistatus xmlns="DAV:">
1608 <href>http://www.foo.bar/container/</href>
1610 <prop xmlns:R="http://www.foo.bar/boxschema/">
1618 <status>HTTP/1.1 200 OK</status>
1622 <href>http://www.foo.bar/container/front.html</href>
1626 Goland, et al. Standards Track [Page 29]
1628 RFC 2518 WEBDAV February 1999
1632 <prop xmlns:R="http://www.foo.bar/boxschema/">
1643 <status>HTTP/1.1 200 OK</status>
1649 In this example, PROPFIND is invoked on the collection resource
1650 http://www.foo.bar/container/, with a propfind XML element containing
1651 the propname XML element, meaning the name of all properties should
1652 be returned. Since no Depth header is present, it assumes its
1653 default value of "infinity", meaning the name of the properties on
1654 the collection and all its progeny should be returned.
1656 Consistent with the previous example, resource
1657 http://www.foo.bar/container/ has six properties defined on it,
1658 http://www.foo.bar/boxschema/bigbox,
1659 http://www.foo.bar/boxschema/author, DAV:creationdate,
1660 DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
1662 The resource http://www.foo.bar/container/index.html, a member of the
1663 "container" collection, has nine properties defined on it,
1664 http://www.foo.bar/boxschema/bigbox, DAV:creationdate,
1665 DAV:displayname, DAV:getcontentlength, DAV:getcontenttype,
1666 DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and
1669 This example also demonstrates the use of XML namespace scoping, and
1670 the default namespace. Since the "xmlns" attribute does not contain
1671 an explicit "shorthand name" (prefix) letter, the namespace applies
1672 by default to all enclosed elements. Hence, all elements which do
1673 not explicitly state the namespace to which they belong are members
1674 of the "DAV:" namespace schema.
1682 Goland, et al. Standards Track [Page 30]
1684 RFC 2518 WEBDAV February 1999
1689 The PROPPATCH method processes instructions specified in the request
1690 body to set and/or remove properties defined on the resource
1691 identified by the Request-URI.
1693 All DAV compliant resources MUST support the PROPPATCH method and
1694 MUST process instructions that are specified using the
1695 propertyupdate, set, and remove XML elements of the DAV schema.
1696 Execution of the directives in this method is, of course, subject to
1697 access control constraints. DAV compliant resources SHOULD support
1698 the setting of arbitrary dead properties.
1700 The request message body of a PROPPATCH method MUST contain the
1701 propertyupdate XML element. Instruction processing MUST occur in the
1702 order instructions are received (i.e., from top to bottom).
1703 Instructions MUST either all be executed or none executed. Thus if
1704 any error occurs during processing all executed instructions MUST be
1705 undone and a proper error result returned. Instruction processing
1706 details can be found in the definition of the set and remove
1707 instructions in section 12.13.
1709 8.2.1 Status Codes for use with 207 (Multi-Status)
1711 The following are examples of response codes one would expect to be
1712 used in a 207 (Multi-Status) response for this method. Note,
1713 however, that unless explicitly prohibited any 2/3/4/5xx series
1714 response code may be used in a 207 (Multi-Status) response.
1716 200 (OK) - The command succeeded. As there can be a mixture of sets
1717 and removes in a body, a 201 (Created) seems inappropriate.
1719 403 (Forbidden) - The client, for reasons the server chooses not to
1720 specify, cannot alter one of the properties.
1722 409 (Conflict) - The client has provided a value whose semantics are
1723 not appropriate for the property. This includes trying to set read-
1726 423 (Locked) - The specified resource is locked and the client either
1727 is not a lock owner or the lock type requires a lock token to be
1728 submitted and the client did not submit it.
1730 507 (Insufficient Storage) - The server did not have sufficient space
1731 to record the property.
1738 Goland, et al. Standards Track [Page 31]
1740 RFC 2518 WEBDAV February 1999
1743 8.2.2 Example - PROPPATCH
1747 PROPPATCH /bar.html HTTP/1.1
1749 Content-Type: text/xml; charset="utf-8"
1750 Content-Length: xxxx
1752 <?xml version="1.0" encoding="utf-8" ?>
1753 <D:propertyupdate xmlns:D="DAV:"
1754 xmlns:Z="http://www.w3.com/standards/z39.50/">
1758 <Z:Author>Jim Whitehead</Z:Author>
1759 <Z:Author>Roy Fielding</Z:Author>
1764 <D:prop><Z:Copyright-Owner/></D:prop>
1770 HTTP/1.1 207 Multi-Status
1771 Content-Type: text/xml; charset="utf-8"
1772 Content-Length: xxxx
1774 <?xml version="1.0" encoding="utf-8" ?>
1775 <D:multistatus xmlns:D="DAV:"
1776 xmlns:Z="http://www.w3.com/standards/z39.50">
1778 <D:href>http://www.foo.com/bar.html</D:href>
1780 <D:prop><Z:Authors/></D:prop>
1781 <D:status>HTTP/1.1 424 Failed Dependency</D:status>
1784 <D:prop><Z:Copyright-Owner/></D:prop>
1785 <D:status>HTTP/1.1 409 Conflict</D:status>
1787 <D:responsedescription> Copyright Owner can not be deleted or
1788 altered.</D:responsedescription>
1794 Goland, et al. Standards Track [Page 32]
1796 RFC 2518 WEBDAV February 1999
1799 In this example, the client requests the server to set the value of
1800 the http://www.w3.com/standards/z39.50/Authors property, and to
1801 remove the property http://www.w3.com/standards/z39.50/Copyright-
1802 Owner. Since the Copyright-Owner property could not be removed, no
1803 property modifications occur. The 424 (Failed Dependency) status
1804 code for the Authors property indicates this action would have
1805 succeeded if it were not for the conflict with removing the
1806 Copyright-Owner property.
1810 The MKCOL method is used to create a new collection. All DAV
1811 compliant resources MUST support the MKCOL method.
1815 MKCOL creates a new collection resource at the location specified by
1816 the Request-URI. If the resource identified by the Request-URI is
1817 non-null then the MKCOL MUST fail. During MKCOL processing, a server
1818 MUST make the Request-URI a member of its parent collection, unless
1819 the Request-URI is "/". If no such ancestor exists, the method MUST
1820 fail. When the MKCOL operation creates a new collection resource,
1821 all ancestors MUST already exist, or the method MUST fail with a 409
1822 (Conflict) status code. For example, if a request to create
1823 collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/ exists,
1824 the request must fail.
1826 When MKCOL is invoked without a request body, the newly created
1827 collection SHOULD have no members.
1829 A MKCOL request message may contain a message body. The behavior of
1830 a MKCOL request when the body is present is limited to creating
1831 collections, members of a collection, bodies of members and
1832 properties on the collections or members. If the server receives a
1833 MKCOL request entity type it does not support or understand it MUST
1834 respond with a 415 (Unsupported Media Type) status code. The exact
1835 behavior of MKCOL for various request media types is undefined in
1836 this document, and will be specified in separate documents.
1840 Responses from a MKCOL request MUST NOT be cached as MKCOL has non-
1841 idempotent semantics.
1843 201 (Created) - The collection or structured resource was created in
1850 Goland, et al. Standards Track [Page 33]
1852 RFC 2518 WEBDAV February 1999
1855 403 (Forbidden) - This indicates at least one of two conditions: 1)
1856 the server does not allow the creation of collections at the given
1857 location in its namespace, or 2) the parent collection of the
1858 Request-URI exists but cannot accept members.
1860 405 (Method Not Allowed) - MKCOL can only be executed on a
1861 deleted/non-existent resource.
1863 409 (Conflict) - A collection cannot be made at the Request-URI until
1864 one or more intermediate collections have been created.
1866 415 (Unsupported Media Type)- The server does not support the request
1869 507 (Insufficient Storage) - The resource does not have sufficient
1870 space to record the state of the resource after the execution of this
1873 8.3.3 Example - MKCOL
1875 This example creates a collection called /webdisc/xfiles/ on the
1876 server www.server.org.
1880 MKCOL /webdisc/xfiles/ HTTP/1.1
1881 Host: www.server.org
1885 HTTP/1.1 201 Created
1887 8.4 GET, HEAD for Collections
1889 The semantics of GET are unchanged when applied to a collection,
1890 since GET is defined as, "retrieve whatever information (in the form
1891 of an entity) is identified by the Request-URI" [RFC2068]. GET when
1892 applied to a collection may return the contents of an "index.html"
1893 resource, a human-readable view of the contents of the collection, or
1894 something else altogether. Hence it is possible that the result of a
1895 GET on a collection will bear no correlation to the membership of the
1898 Similarly, since the definition of HEAD is a GET without a response
1899 message body, the semantics of HEAD are unmodified when applied to
1900 collection resources.
1906 Goland, et al. Standards Track [Page 34]
1908 RFC 2518 WEBDAV February 1999
1911 8.5 POST for Collections
1913 Since by definition the actual function performed by POST is
1914 determined by the server and often depends on the particular
1915 resource, the behavior of POST when applied to collections cannot be
1916 meaningfully modified because it is largely undefined. Thus the
1917 semantics of POST are unmodified when applied to a collection.
1921 8.6.1 DELETE for Non-Collection Resources
1923 If the DELETE method is issued to a non-collection resource whose
1924 URIs are an internal member of one or more collections, then during
1925 DELETE processing a server MUST remove any URI for the resource
1926 identified by the Request-URI from collections which contain it as a
1929 8.6.2 DELETE for Collections
1931 The DELETE method on a collection MUST act as if a "Depth: infinity"
1932 header was used on it. A client MUST NOT submit a Depth header with
1933 a DELETE on a collection with any value but infinity.
1935 DELETE instructs that the collection specified in the Request-URI and
1936 all resources identified by its internal member URIs are to be
1939 If any resource identified by a member URI cannot be deleted then all
1940 of the member's ancestors MUST NOT be deleted, so as to maintain
1941 namespace consistency.
1943 Any headers included with DELETE MUST be applied in processing every
1944 resource to be deleted.
1946 When the DELETE method has completed processing it MUST result in a
1947 consistent namespace.
1949 If an error occurs with a resource other than the resource identified
1950 in the Request-URI then the response MUST be a 207 (Multi-Status).
1951 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-
1952 Status). They can be safely left out because the client will know
1953 that the ancestors of a resource could not be deleted when the client
1954 receives an error for the ancestor's progeny. Additionally 204 (No
1955 Content) errors SHOULD NOT be returned in the 207 (Multi-Status).
1956 The reason for this prohibition is that 204 (No Content) is the
1957 default success code.
1962 Goland, et al. Standards Track [Page 35]
1964 RFC 2518 WEBDAV February 1999
1967 8.6.2.1 Example - DELETE
1971 DELETE /container/ HTTP/1.1
1976 HTTP/1.1 207 Multi-Status
1977 Content-Type: text/xml; charset="utf-8"
1978 Content-Length: xxxx
1980 <?xml version="1.0" encoding="utf-8" ?>
1981 <d:multistatus xmlns:d="DAV:">
1983 <d:href>http://www.foo.bar/container/resource3</d:href>
1984 <d:status>HTTP/1.1 423 Locked</d:status>
1988 In this example the attempt to delete
1989 http://www.foo.bar/container/resource3 failed because it is locked,
1990 and no lock token was submitted with the request. Consequently, the
1991 attempt to delete http://www.foo.bar/container/ also failed. Thus the
1992 client knows that the attempt to delete http://www.foo.bar/container/
1993 must have also failed since the parent can not be deleted unless its
1994 child has also been deleted. Even though a Depth header has not been
1995 included, a depth of infinity is assumed because the method is on a
2000 8.7.1 PUT for Non-Collection Resources
2002 A PUT performed on an existing resource replaces the GET response
2003 entity of the resource. Properties defined on the resource may be
2004 recomputed during PUT processing but are not otherwise affected. For
2005 example, if a server recognizes the content type of the request body,
2006 it may be able to automatically extract information that could be
2007 profitably exposed as properties.
2009 A PUT that would result in the creation of a resource without an
2010 appropriately scoped parent collection MUST fail with a 409
2018 Goland, et al. Standards Track [Page 36]
2020 RFC 2518 WEBDAV February 1999
2023 8.7.2 PUT for Collections
2025 As defined in the HTTP/1.1 specification [RFC2068], the "PUT method
2026 requests that the enclosed entity be stored under the supplied
2027 Request-URI." Since submission of an entity representing a
2028 collection would implicitly encode creation and deletion of
2029 resources, this specification intentionally does not define a
2030 transmission format for creating a collection using PUT. Instead,
2031 the MKCOL method is defined to create collections.
2033 When the PUT operation creates a new non-collection resource all
2034 ancestors MUST already exist. If all ancestors do not exist, the
2035 method MUST fail with a 409 (Conflict) status code. For example, if
2036 resource /a/b/c/d.html is to be created and /a/b/c/ does not exist,
2037 then the request must fail.
2041 The COPY method creates a duplicate of the source resource,
2042 identified by the Request-URI, in the destination resource,
2043 identified by the URI in the Destination header. The Destination
2044 header MUST be present. The exact behavior of the COPY method
2045 depends on the type of the source resource.
2047 All WebDAV compliant resources MUST support the COPY method.
2048 However, support for the COPY method does not guarantee the ability
2049 to copy a resource. For example, separate programs may control
2050 resources on the same server. As a result, it may not be possible to
2051 copy a resource to a location that appears to be on the same server.
2053 8.8.1 COPY for HTTP/1.1 resources
2055 When the source resource is not a collection the result of the COPY
2056 method is the creation of a new resource at the destination whose
2057 state and behavior match that of the source resource as closely as
2058 possible. After a successful COPY invocation, all properties on the
2059 source resource MUST be duplicated on the destination resource,
2060 subject to modifying headers and XML elements, following the
2061 definition for copying properties. Since the environment at the
2062 destination may be different than at the source due to factors
2063 outside the scope of control of the server, such as the absence of
2064 resources required for correct operation, it may not be possible to
2065 completely duplicate the behavior of the resource at the destination.
2066 Subsequent alterations to the destination resource will not modify
2067 the source resource. Subsequent alterations to the source resource
2068 will not modify the destination resource.
2074 Goland, et al. Standards Track [Page 37]
2076 RFC 2518 WEBDAV February 1999
2079 8.8.2. COPY for Properties
2081 The following section defines how properties on a resource are
2082 handled during a COPY operation.
2084 Live properties SHOULD be duplicated as identically behaving live
2085 properties at the destination resource. If a property cannot be
2086 copied live, then its value MUST be duplicated, octet-for-octet, in
2087 an identically named, dead property on the destination resource
2088 subject to the effects of the propertybehavior XML element.
2090 The propertybehavior XML element can specify that properties are
2091 copied on best effort, that all live properties must be successfully
2092 copied or the method must fail, or that a specified list of live
2093 properties must be successfully copied or the method must fail. The
2094 propertybehavior XML element is defined in section 12.12.
2096 8.8.3 COPY for Collections
2098 The COPY method on a collection without a Depth header MUST act as if
2099 a Depth header with value "infinity" was included. A client may
2100 submit a Depth header on a COPY on a collection with a value of "0"
2101 or "infinity". DAV compliant servers MUST support the "0" and
2102 "infinity" Depth header behaviors.
2104 A COPY of depth infinity instructs that the collection resource
2105 identified by the Request-URI is to be copied to the location
2106 identified by the URI in the Destination header, and all its internal
2107 member resources are to be copied to a location relative to it,
2108 recursively through all levels of the collection hierarchy.
2110 A COPY of "Depth: 0" only instructs that the collection and its
2111 properties but not resources identified by its internal member URIs,
2114 Any headers included with a COPY MUST be applied in processing every
2115 resource to be copied with the exception of the Destination header.
2117 The Destination header only specifies the destination URI for the
2118 Request-URI. When applied to members of the collection identified by
2119 the Request-URI the value of Destination is to be modified to reflect
2120 the current location in the hierarchy. So, if the Request- URI is
2121 /a/ with Host header value http://fun.com/ and the Destination is
2122 http://fun.com/b/ then when http://fun.com/a/c/d is processed it must
2123 use a Destination of http://fun.com/b/c/d.
2130 Goland, et al. Standards Track [Page 38]
2132 RFC 2518 WEBDAV February 1999
2135 When the COPY method has completed processing it MUST have created a
2136 consistent namespace at the destination (see section 5.1 for the
2137 definition of namespace consistency). However, if an error occurs
2138 while copying an internal collection, the server MUST NOT copy any
2139 resources identified by members of this collection (i.e., the server
2140 must skip this subtree), as this would create an inconsistent
2141 namespace. After detecting an error, the COPY operation SHOULD try to
2142 finish as much of the original copy operation as possible (i.e., the
2143 server should still attempt to copy other subtrees and their members,
2144 that are not descendents of an error-causing collection). So, for
2145 example, if an infinite depth copy operation is performed on
2146 collection /a/, which contains collections /a/b/ and /a/c/, and an
2147 error occurs copying /a/b/, an attempt should still be made to copy
2148 /a/c/. Similarly, after encountering an error copying a non-
2149 collection resource as part of an infinite depth copy, the server
2150 SHOULD try to finish as much of the original copy operation as
2153 If an error in executing the COPY method occurs with a resource other
2154 than the resource identified in the Request-URI then the response
2155 MUST be a 207 (Multi-Status).
2157 The 424 (Failed Dependency) status code SHOULD NOT be returned in the
2158 207 (Multi-Status) response from a COPY method. These responses can
2159 be safely omitted because the client will know that the progeny of a
2160 resource could not be copied when the client receives an error for
2161 the parent. Additionally 201 (Created)/204 (No Content) status codes
2162 SHOULD NOT be returned as values in 207 (Multi-Status) responses from
2163 COPY methods. They, too, can be safely omitted because they are the
2164 default success codes.
2166 8.8.4 COPY and the Overwrite Header
2168 If a resource exists at the destination and the Overwrite header is
2169 "T" then prior to performing the copy the server MUST perform a
2170 DELETE with "Depth: infinity" on the destination resource. If the
2171 Overwrite header is set to "F" then the operation will fail.
2175 201 (Created) - The source resource was successfully copied. The
2176 copy operation resulted in the creation of a new resource.
2178 204 (No Content) - The source resource was successfully copied to a
2179 pre-existing destination resource.
2181 403 (Forbidden) _ The source and destination URIs are the same.
2186 Goland, et al. Standards Track [Page 39]
2188 RFC 2518 WEBDAV February 1999
2191 409 (Conflict) _ A resource cannot be created at the destination
2192 until one or more intermediate collections have been created.
2194 412 (Precondition Failed) - The server was unable to maintain the
2195 liveness of the properties listed in the propertybehavior XML element
2196 or the Overwrite header is "F" and the state of the destination
2197 resource is non-null.
2199 423 (Locked) - The destination resource was locked.
2201 502 (Bad Gateway) - This may occur when the destination is on another
2202 server and the destination server refuses to accept the resource.
2204 507 (Insufficient Storage) - The destination resource does not have
2205 sufficient space to record the state of the resource after the
2206 execution of this method.
2208 8.8.6 Example - COPY with Overwrite
2210 This example shows resource
2211 http://www.ics.uci.edu/~fielding/index.html being copied to the
2212 location http://www.ics.uci.edu/users/f/fielding/index.html. The 204
2213 (No Content) status code indicates the existing resource at the
2214 destination was overwritten.
2218 COPY /~fielding/index.html HTTP/1.1
2219 Host: www.ics.uci.edu
2220 Destination: http://www.ics.uci.edu/users/f/fielding/index.html
2224 HTTP/1.1 204 No Content
2226 8.8.7 Example - COPY with No Overwrite
2228 The following example shows the same copy operation being performed,
2229 but with the Overwrite header set to "F." A response of 412
2230 (Precondition Failed) is returned because the destination resource
2231 has a non-null state.
2235 COPY /~fielding/index.html HTTP/1.1
2236 Host: www.ics.uci.edu
2237 Destination: http://www.ics.uci.edu/users/f/fielding/index.html
2242 Goland, et al. Standards Track [Page 40]
2244 RFC 2518 WEBDAV February 1999
2249 HTTP/1.1 412 Precondition Failed
2251 8.8.8 Example - COPY of a Collection
2255 COPY /container/ HTTP/1.1
2257 Destination: http://www.foo.bar/othercontainer/
2259 Content-Type: text/xml; charset="utf-8"
2260 Content-Length: xxxx
2262 <?xml version="1.0" encoding="utf-8" ?>
2263 <d:propertybehavior xmlns:d="DAV:">
2264 <d:keepalive>*</d:keepalive>
2265 </d:propertybehavior>
2269 HTTP/1.1 207 Multi-Status
2270 Content-Type: text/xml; charset="utf-8"
2271 Content-Length: xxxx
2273 <?xml version="1.0" encoding="utf-8" ?>
2274 <d:multistatus xmlns:d="DAV:">
2276 <d:href>http://www.foo.bar/othercontainer/R2/</d:href>
2277 <d:status>HTTP/1.1 412 Precondition Failed</d:status>
2281 The Depth header is unnecessary as the default behavior of COPY on a
2282 collection is to act as if a "Depth: infinity" header had been
2283 submitted. In this example most of the resources, along with the
2284 collection, were copied successfully. However the collection R2
2285 failed, most likely due to a problem with maintaining the liveness of
2286 properties (this is specified by the propertybehavior XML element).
2287 Because there was an error copying R2, none of R2's members were
2288 copied. However no errors were listed for those members due to the
2289 error minimization rules given in section 8.8.3.
2298 Goland, et al. Standards Track [Page 41]
2300 RFC 2518 WEBDAV February 1999
2305 The MOVE operation on a non-collection resource is the logical
2306 equivalent of a copy (COPY), followed by consistency maintenance
2307 processing, followed by a delete of the source, where all three
2308 actions are performed atomically. The consistency maintenance step
2309 allows the server to perform updates caused by the move, such as
2310 updating all URIs other than the Request-URI which identify the
2311 source resource, to point to the new destination resource.
2312 Consequently, the Destination header MUST be present on all MOVE
2313 methods and MUST follow all COPY requirements for the COPY part of
2314 the MOVE method. All DAV compliant resources MUST support the MOVE
2315 method. However, support for the MOVE method does not guarantee the
2316 ability to move a resource to a particular destination.
2318 For example, separate programs may actually control different sets of
2319 resources on the same server. Therefore, it may not be possible to
2320 move a resource within a namespace that appears to belong to the same
2323 If a resource exists at the destination, the destination resource
2324 will be DELETEd as a side-effect of the MOVE operation, subject to
2325 the restrictions of the Overwrite header.
2327 8.9.1 MOVE for Properties
2329 The behavior of properties on a MOVE, including the effects of the
2330 propertybehavior XML element, MUST be the same as specified in
2333 8.9.2 MOVE for Collections
2335 A MOVE with "Depth: infinity" instructs that the collection
2336 identified by the Request-URI be moved to the URI specified in the
2337 Destination header, and all resources identified by its internal
2338 member URIs are to be moved to locations relative to it, recursively
2339 through all levels of the collection hierarchy.
2341 The MOVE method on a collection MUST act as if a "Depth: infinity"
2342 header was used on it. A client MUST NOT submit a Depth header on a
2343 MOVE on a collection with any value but "infinity".
2345 Any headers included with MOVE MUST be applied in processing every
2346 resource to be moved with the exception of the Destination header.
2348 The behavior of the Destination header is the same as given for COPY
2354 Goland, et al. Standards Track [Page 42]
2356 RFC 2518 WEBDAV February 1999
2359 When the MOVE method has completed processing it MUST have created a
2360 consistent namespace at both the source and destination (see section
2361 5.1 for the definition of namespace consistency). However, if an
2362 error occurs while moving an internal collection, the server MUST NOT
2363 move any resources identified by members of the failed collection
2364 (i.e., the server must skip the error-causing subtree), as this would
2365 create an inconsistent namespace. In this case, after detecting the
2366 error, the move operation SHOULD try to finish as much of the
2367 original move as possible (i.e., the server should still attempt to
2368 move other subtrees and the resources identified by their members,
2369 that are not descendents of an error-causing collection). So, for
2370 example, if an infinite depth move is performed on collection /a/,
2371 which contains collections /a/b/ and /a/c/, and an error occurs
2372 moving /a/b/, an attempt should still be made to try moving /a/c/.
2373 Similarly, after encountering an error moving a non-collection
2374 resource as part of an infinite depth move, the server SHOULD try to
2375 finish as much of the original move operation as possible.
2377 If an error occurs with a resource other than the resource identified
2378 in the Request-URI then the response MUST be a 207 (Multi-Status).
2380 The 424 (Failed Dependency) status code SHOULD NOT be returned in the
2381 207 (Multi-Status) response from a MOVE method. These errors can be
2382 safely omitted because the client will know that the progeny of a
2383 resource could not be moved when the client receives an error for the
2384 parent. Additionally 201 (Created)/204 (No Content) responses SHOULD
2385 NOT be returned as values in 207 (Multi-Status) responses from a
2386 MOVE. These responses can be safely omitted because they are the
2387 default success codes.
2389 8.9.3 MOVE and the Overwrite Header
2391 If a resource exists at the destination and the Overwrite header is
2392 "T" then prior to performing the move the server MUST perform a
2393 DELETE with "Depth: infinity" on the destination resource. If the
2394 Overwrite header is set to "F" then the operation will fail.
2398 201 (Created) - The source resource was successfully moved, and a new
2399 resource was created at the destination.
2401 204 (No Content) - The source resource was successfully moved to a
2402 pre-existing destination resource.
2404 403 (Forbidden) _ The source and destination URIs are the same.
2410 Goland, et al. Standards Track [Page 43]
2412 RFC 2518 WEBDAV February 1999
2415 409 (Conflict) _ A resource cannot be created at the destination
2416 until one or more intermediate collections have been created.
2418 412 (Precondition Failed) - The server was unable to maintain the
2419 liveness of the properties listed in the propertybehavior XML element
2420 or the Overwrite header is "F" and the state of the destination
2421 resource is non-null.
2423 423 (Locked) - The source or the destination resource was locked.
2425 502 (Bad Gateway) - This may occur when the destination is on another
2426 server and the destination server refuses to accept the resource.
2428 8.9.5 Example - MOVE of a Non-Collection
2430 This example shows resource
2431 http://www.ics.uci.edu/~fielding/index.html being moved to the
2432 location http://www.ics.uci.edu/users/f/fielding/index.html. The
2433 contents of the destination resource would have been overwritten if
2434 the destination resource had been non-null. In this case, since
2435 there was nothing at the destination resource, the response code is
2440 MOVE /~fielding/index.html HTTP/1.1
2441 Host: www.ics.uci.edu
2442 Destination: http://www.ics.uci.edu/users/f/fielding/index.html
2446 HTTP/1.1 201 Created
2447 Location: http://www.ics.uci.edu/users/f/fielding/index.html
2450 8.9.6 Example - MOVE of a Collection
2454 MOVE /container/ HTTP/1.1
2456 Destination: http://www.foo.bar/othercontainer/
2458 If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
2459 (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
2460 Content-Type: text/xml; charset="utf-8"
2461 Content-Length: xxxx
2466 Goland, et al. Standards Track [Page 44]
2468 RFC 2518 WEBDAV February 1999
2471 <?xml version="1.0" encoding="utf-8" ?>
2472 <d:propertybehavior xmlns:d='DAV:'>
2473 <d:keepalive>*</d:keepalive>
2474 </d:propertybehavior>
2478 HTTP/1.1 207 Multi-Status
2479 Content-Type: text/xml; charset="utf-8"
2480 Content-Length: xxxx
2482 <?xml version="1.0" encoding="utf-8" ?>
2483 <d:multistatus xmlns:d='DAV:'>
2485 <d:href>http://www.foo.bar/othercontainer/C2/</d:href>
2486 <d:status>HTTP/1.1 423 Locked</d:status>
2490 In this example the client has submitted a number of lock tokens with
2491 the request. A lock token will need to be submitted for every
2492 resource, both source and destination, anywhere in the scope of the
2493 method, that is locked. In this case the proper lock token was not
2494 submitted for the destination http://www.foo.bar/othercontainer/C2/.
2495 This means that the resource /container/C2/ could not be moved.
2496 Because there was an error copying /container/C2/, none of
2497 /container/C2's members were copied. However no errors were listed
2498 for those members due to the error minimization rules given in
2499 section 8.8.3. User agent authentication has previously occurred via
2500 a mechanism outside the scope of the HTTP protocol, in an underlying
2505 The following sections describe the LOCK method, which is used to
2506 take out a lock of any access type. These sections on the LOCK
2507 method describe only those semantics that are specific to the LOCK
2508 method and are independent of the access type of the lock being
2511 Any resource which supports the LOCK method MUST, at minimum, support
2512 the XML request and response formats defined herein.
2522 Goland, et al. Standards Track [Page 45]
2524 RFC 2518 WEBDAV February 1999
2529 A LOCK method invocation creates the lock specified by the lockinfo
2530 XML element on the Request-URI. Lock method requests SHOULD have a
2531 XML request body which contains an owner XML element for this lock
2532 request, unless this is a refresh request. The LOCK request may have
2535 Clients MUST assume that locks may arbitrarily disappear at any time,
2536 regardless of the value given in the Timeout header. The Timeout
2537 header only indicates the behavior of the server if "extraordinary"
2538 circumstances do not occur. For example, an administrator may remove
2539 a lock at any time or the system may crash in such a way that it
2540 loses the record of the lock's existence. The response MUST contain
2541 the value of the lockdiscovery property in a prop XML element.
2543 In order to indicate the lock token associated with a newly created
2544 lock, a Lock-Token response header MUST be included in the response
2545 for every successful LOCK request for a new lock. Note that the
2546 Lock-Token header would not be returned in the response for a
2547 successful refresh LOCK request because a new lock was not created.
2549 8.10.2 The Effect of Locks on Properties and Collections
2551 The scope of a lock is the entire state of the resource, including
2552 its body and associated properties. As a result, a lock on a
2553 resource MUST also lock the resource's properties.
2555 For collections, a lock also affects the ability to add or remove
2556 members. The nature of the effect depends upon the type of access
2559 8.10.3 Locking Replicated Resources
2561 A resource may be made available through more than one URI. However
2562 locks apply to resources, not URIs. Therefore a LOCK request on a
2563 resource MUST NOT succeed if can not be honored by all the URIs
2564 through which the resource is addressable.
2566 8.10.4 Depth and Locking
2568 The Depth header may be used with the LOCK method. Values other than
2569 0 or infinity MUST NOT be used with the Depth header on a LOCK
2570 method. All resources that support the LOCK method MUST support the
2573 A Depth header of value 0 means to just lock the resource specified
2578 Goland, et al. Standards Track [Page 46]
2580 RFC 2518 WEBDAV February 1999
2583 If the Depth header is set to infinity then the resource specified in
2584 the Request-URI along with all its internal members, all the way down
2585 the hierarchy, are to be locked. A successful result MUST return a
2586 single lock token which represents all the resources that have been
2587 locked. If an UNLOCK is successfully executed on this token, all
2588 associated resources are unlocked. If the lock cannot be granted to
2589 all resources, a 409 (Conflict) status code MUST be returned with a
2590 response entity body containing a multistatus XML element describing
2591 which resource(s) prevented the lock from being granted. Hence,
2592 partial success is not an option. Either the entire hierarchy is
2593 locked or no resources are locked.
2595 If no Depth header is submitted on a LOCK request then the request
2596 MUST act as if a "Depth:infinity" had been submitted.
2598 8.10.5 Interaction with other Methods
2600 The interaction of a LOCK with various methods is dependent upon the
2601 lock type. However, independent of lock type, a successful DELETE of
2602 a resource MUST cause all of its locks to be removed.
2604 8.10.6 Lock Compatibility Table
2606 The table below describes the behavior that occurs when a lock
2607 request is made on a resource.
2609 Current lock state/ | Shared Lock | Exclusive
2610 Lock request | | Lock
2611 =====================+=================+==============
2613 ---------------------+-----------------+--------------
2614 Shared Lock | True | False
2615 ---------------------+-----------------+--------------
2616 Exclusive Lock | False | False*
2617 ------------------------------------------------------
2619 Legend: True = lock may be granted. False = lock MUST NOT be
2620 granted. *=It is illegal for a principal to request the same lock
2623 The current lock state of a resource is given in the leftmost column,
2624 and lock requests are listed in the first row. The intersection of a
2625 row and column gives the result of a lock request. For example, if a
2626 shared lock is held on a resource, and an exclusive lock is
2627 requested, the table entry is "false", indicating the lock must not
2634 Goland, et al. Standards Track [Page 47]
2636 RFC 2518 WEBDAV February 1999
2641 200 (OK) - The lock request succeeded and the value of the
2642 lockdiscovery property is included in the body.
2644 412 (Precondition Failed) - The included lock token was not
2645 enforceable on this resource or the server could not satisfy the
2646 request in the lockinfo XML element.
2648 423 (Locked) - The resource is locked, so the method has been
2651 8.10.8 Example - Simple Lock Request
2655 LOCK /workspace/webdav/proposal.doc HTTP/1.1
2656 Host: webdav.sb.aol.com
2657 Timeout: Infinite, Second-4100000000
2658 Content-Type: text/xml; charset="utf-8"
2659 Content-Length: xxxx
2660 Authorization: Digest username="ejw",
2661 realm="ejw@webdav.sb.aol.com", nonce="...",
2662 uri="/workspace/webdav/proposal.doc",
2663 response="...", opaque="..."
2665 <?xml version="1.0" encoding="utf-8" ?>
2666 <D:lockinfo xmlns:D='DAV:'>
2667 <D:lockscope><D:exclusive/></D:lockscope>
2668 <D:locktype><D:write/></D:locktype>
2670 <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
2677 Content-Type: text/xml; charset="utf-8"
2678 Content-Length: xxxx
2680 <?xml version="1.0" encoding="utf-8" ?>
2681 <D:prop xmlns:D="DAV:">
2684 <D:locktype><D:write/></D:locktype>
2685 <D:lockscope><D:exclusive/></D:lockscope>
2686 <D:depth>Infinity</D:depth>
2690 Goland, et al. Standards Track [Page 48]
2692 RFC 2518 WEBDAV February 1999
2697 http://www.ics.uci.edu/~ejw/contact.html
2700 <D:timeout>Second-604800</D:timeout>
2703 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
2710 This example shows the successful creation of an exclusive write lock
2711 on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc.
2712 The resource http://www.ics.uci.edu/~ejw/contact.html contains
2713 contact information for the owner of the lock. The server has an
2714 activity-based timeout policy in place on this resource, which causes
2715 the lock to automatically be removed after 1 week (604800 seconds).
2716 Note that the nonce, response, and opaque fields have not been
2717 calculated in the Authorization request header.
2719 8.10.9 Example - Refreshing a Write Lock
2723 LOCK /workspace/webdav/proposal.doc HTTP/1.1
2724 Host: webdav.sb.aol.com
2725 Timeout: Infinite, Second-4100000000
2726 If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
2727 Authorization: Digest username="ejw",
2728 realm="ejw@webdav.sb.aol.com", nonce="...",
2729 uri="/workspace/webdav/proposal.doc",
2730 response="...", opaque="..."
2735 Content-Type: text/xml; charset="utf-8"
2736 Content-Length: xxxx
2738 <?xml version="1.0" encoding="utf-8" ?>
2739 <D:prop xmlns:D="DAV:">
2742 <D:locktype><D:write/></D:locktype>
2746 Goland, et al. Standards Track [Page 49]
2748 RFC 2518 WEBDAV February 1999
2751 <D:lockscope><D:exclusive/></D:lockscope>
2752 <D:depth>Infinity</D:depth>
2755 http://www.ics.uci.edu/~ejw/contact.html
2758 <D:timeout>Second-604800</D:timeout>
2761 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
2768 This request would refresh the lock, resetting any time outs. Notice
2769 that the client asked for an infinite time out but the server choose
2770 to ignore the request. In this example, the nonce, response, and
2771 opaque fields have not been calculated in the Authorization request
2774 8.10.10 Example - Multi-Resource Lock Request
2778 LOCK /webdav/ HTTP/1.1
2779 Host: webdav.sb.aol.com
2780 Timeout: Infinite, Second-4100000000
2782 Content-Type: text/xml; charset="utf-8"
2783 Content-Length: xxxx
2784 Authorization: Digest username="ejw",
2785 realm="ejw@webdav.sb.aol.com", nonce="...",
2786 uri="/workspace/webdav/proposal.doc",
2787 response="...", opaque="..."
2789 <?xml version="1.0" encoding="utf-8" ?>
2790 <D:lockinfo xmlns:D="DAV:">
2791 <D:locktype><D:write/></D:locktype>
2792 <D:lockscope><D:exclusive/></D:lockscope>
2794 <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
2802 Goland, et al. Standards Track [Page 50]
2804 RFC 2518 WEBDAV February 1999
2807 HTTP/1.1 207 Multi-Status
2808 Content-Type: text/xml; charset="utf-8"
2809 Content-Length: xxxx
2811 <?xml version="1.0" encoding="utf-8" ?>
2812 <D:multistatus xmlns:D="DAV:">
2814 <D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
2815 <D:status>HTTP/1.1 403 Forbidden</D:status>
2818 <D:href>http://webdav.sb.aol.com/webdav/</D:href>
2820 <D:prop><D:lockdiscovery/></D:prop>
2821 <D:status>HTTP/1.1 424 Failed Dependency</D:status>
2826 This example shows a request for an exclusive write lock on a
2827 collection and all its children. In this request, the client has
2828 specified that it desires an infinite length lock, if available,
2829 otherwise a timeout of 4.1 billion seconds, if available. The request
2830 entity body contains the contact information for the principal taking
2831 out the lock, in this case a web page URL.
2833 The error is a 403 (Forbidden) response on the resource
2834 http://webdav.sb.aol.com/webdav/secret. Because this resource could
2835 not be locked, none of the resources were locked. Note also that the
2836 lockdiscovery property for the Request-URI has been included as
2837 required. In this example the lockdiscovery property is empty which
2838 means that there are no outstanding locks on the resource.
2840 In this example, the nonce, response, and opaque fields have not been
2841 calculated in the Authorization request header.
2845 The UNLOCK method removes the lock identified by the lock token in
2846 the Lock-Token request header from the Request-URI, and all other
2847 resources included in the lock. If all resources which have been
2848 locked under the submitted lock token can not be unlocked then the
2849 UNLOCK request MUST fail.
2851 Any DAV compliant resource which supports the LOCK method MUST
2852 support the UNLOCK method.
2858 Goland, et al. Standards Track [Page 51]
2860 RFC 2518 WEBDAV February 1999
2863 8.11.1 Example - UNLOCK
2867 UNLOCK /workspace/webdav/info.doc HTTP/1.1
2868 Host: webdav.sb.aol.com
2869 Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
2870 Authorization: Digest username="ejw",
2871 realm="ejw@webdav.sb.aol.com", nonce="...",
2872 uri="/workspace/webdav/proposal.doc",
2873 response="...", opaque="..."
2877 HTTP/1.1 204 No Content
2879 In this example, the lock identified by the lock token
2880 "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
2881 successfully removed from the resource
2882 http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock
2883 included more than just one resource, the lock is removed from all
2884 resources included in the lock. The 204 (No Content) status code is
2885 used instead of 200 (OK) because there is no response entity body.
2887 In this example, the nonce, response, and opaque fields have not been
2888 calculated in the Authorization request header.
2890 9 HTTP Headers for Distributed Authoring
2894 DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
2896 This header indicates that the resource supports the DAV schema and
2897 protocol as specified. All DAV compliant resources MUST return the
2898 DAV header on all OPTIONS responses.
2900 The value is a list of all compliance classes that the resource
2901 supports. Note that above a comma has already been added to the 2.
2902 This is because a resource can not be level 2 compliant unless it is
2903 also level 1 compliant. Please refer to section 15 for more details.
2904 In general, however, support for one compliance class does not entail
2905 support for any other.
2909 Depth = "Depth" ":" ("0" | "1" | "infinity")
2914 Goland, et al. Standards Track [Page 52]
2916 RFC 2518 WEBDAV February 1999
2919 The Depth header is used with methods executed on resources which
2920 could potentially have internal members to indicate whether the
2921 method is to be applied only to the resource ("Depth: 0"), to the
2922 resource and its immediate children, ("Depth: 1"), or the resource
2923 and all its progeny ("Depth: infinity").
2925 The Depth header is only supported if a method's definition
2926 explicitly provides for such support.
2928 The following rules are the default behavior for any method that
2929 supports the Depth header. A method may override these defaults by
2930 defining different behavior in its definition.
2932 Methods which support the Depth header may choose not to support all
2933 of the header's values and may define, on a case by case basis, the
2934 behavior of the method if a Depth header is not present. For example,
2935 the MOVE method only supports "Depth: infinity" and if a Depth header
2936 is not present will act as if a "Depth: infinity" header had been
2939 Clients MUST NOT rely upon methods executing on members of their
2940 hierarchies in any particular order or on the execution being atomic
2941 unless the particular method explicitly provides such guarantees.
2943 Upon execution, a method with a Depth header will perform as much of
2944 its assigned task as possible and then return a response specifying
2945 what it was able to accomplish and what it failed to do.
2947 So, for example, an attempt to COPY a hierarchy may result in some of
2948 the members being copied and some not.
2950 Any headers on a method that has a defined interaction with the Depth
2951 header MUST be applied to all resources in the scope of the method
2952 except where alternative behavior is explicitly defined. For example,
2953 an If-Match header will have its value applied against every resource
2954 in the method's scope and will cause the method to fail if the header
2957 If a resource, source or destination, within the scope of the method
2958 with a Depth header is locked in such a way as to prevent the
2959 successful execution of the method, then the lock token for that
2960 resource MUST be submitted with the request in the If request header.
2962 The Depth header only specifies the behavior of the method with
2963 regards to internal children. If a resource does not have internal
2964 children then the Depth header MUST be ignored.
2970 Goland, et al. Standards Track [Page 53]
2972 RFC 2518 WEBDAV February 1999
2975 Please note, however, that it is always an error to submit a value
2976 for the Depth header that is not allowed by the method's definition.
2977 Thus submitting a "Depth: 1" on a COPY, even if the resource does not
2978 have internal members, will result in a 400 (Bad Request). The method
2979 should fail not because the resource doesn't have internal members,
2980 but because of the illegal value in the header.
2982 9.3 Destination Header
2984 Destination = "Destination" ":" absoluteURI
2986 The Destination header specifies the URI which identifies a
2987 destination resource for methods such as COPY and MOVE, which take
2988 two URIs as parameters. Note that the absoluteURI production is
2989 defined in [RFC2396].
2993 If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
2995 Tagged-list = Resource 1*List
2996 Resource = Coded-URL
2997 List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
2998 State-token = Coded-URL
2999 Coded-URL = "<" absoluteURI ">"
3001 The If header is intended to have similar functionality to the If-
3002 Match header defined in section 14.25 of [RFC2068]. However the If
3003 header is intended for use with any URI which represents state
3004 information, referred to as a state token, about a resource as well
3005 as ETags. A typical example of a state token is a lock token, and
3006 lock tokens are the only state tokens defined in this specification.
3008 All DAV compliant resources MUST honor the If header.
3010 The If header's purpose is to describe a series of state lists. If
3011 the state of the resource to which the header is applied does not
3012 match any of the specified state lists then the request MUST fail
3013 with a 412 (Precondition Failed). If one of the described state
3014 lists matches the state of the resource then the request may succeed.
3016 Note that the absoluteURI production is defined in [RFC2396].
3026 Goland, et al. Standards Track [Page 54]
3028 RFC 2518 WEBDAV February 1999
3031 9.4.1 No-tag-list Production
3033 The No-tag-list production describes a series of state tokens and
3034 ETags. If multiple No-tag-list productions are used then one only
3035 needs to match the state of the resource for the method to be allowed
3038 If a method, due to the presence of a Depth or Destination header, is
3039 applied to multiple resources then the No-tag-list production MUST be
3040 applied to each resource the method is applied to.
3042 9.4.1.1 Example - No-tag-list If Header
3044 If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another
3047 The previous header would require that any resources within the scope
3048 of the method must either be locked with the specified lock token and
3049 in the state identified by the "I am an ETag" ETag or in the state
3050 identified by the second ETag "I am another ETag". To put the matter
3051 more plainly one can think of the previous If header as being in the
3052 form (or (and <locktoken:a-write-lock-token> ["I am an ETag"]) (and
3053 ["I am another ETag"])).
3055 9.4.2 Tagged-list Production
3057 The tagged-list production scopes a list production. That is, it
3058 specifies that the lists following the resource specification only
3059 apply to the specified resource. The scope of the resource
3060 production begins with the list production immediately following the
3061 resource production and ends with the next resource production, if
3064 When the If header is applied to a particular resource, the Tagged-
3065 list productions MUST be searched to determine if any of the listed
3066 resources match the operand resource(s) for the current method. If
3067 none of the resource productions match the current resource then the
3068 header MUST be ignored. If one of the resource productions does
3069 match the name of the resource under consideration then the list
3070 productions following the resource production MUST be applied to the
3071 resource in the manner specified in the previous section.
3073 The same URI MUST NOT appear more than once in a resource production
3082 Goland, et al. Standards Track [Page 55]
3084 RFC 2518 WEBDAV February 1999
3087 9.4.2.1 Example - Tagged List If header
3089 COPY /resource1 HTTP/1.1
3091 Destination: http://www.foo.bar/resource2
3092 If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token>
3093 [W/"A weak ETag"]) (["strong ETag"])
3094 <http://www.bar.bar/random>(["another strong ETag"])
3096 In this example http://www.foo.bar/resource1 is being copied to
3097 http://www.foo.bar/resource2. When the method is first applied to
3098 http://www.foo.bar/resource1, resource1 must be in the state
3099 specified by "(<locktoken:a-write-lock-token> [W/"A weak ETag"])
3100 (["strong ETag"])", that is, it either must be locked with a lock
3101 token of "locktoken:a-write-lock-token" and have a weak entity tag
3102 W/"A weak ETag" or it must have a strong entity tag "strong ETag".
3104 That is the only success condition since the resource
3105 http://www.bar.bar/random never has the method applied to it (the
3106 only other resource listed in the If header) and
3107 http://www.foo.bar/resource2 is not listed in the If header.
3109 9.4.3 not Production
3111 Every state token or ETag is either current, and hence describes the
3112 state of a resource, or is not current, and does not describe the
3113 state of a resource. The boolean operation of matching a state token
3114 or ETag to the current state of a resource thus resolves to a true or
3115 false value. The not production is used to reverse that value. The
3116 scope of the not production is the state-token or entity-tag
3117 immediately following it.
3119 If: (Not <locktoken:write1> <locktoken:write2>)
3121 When submitted with a request, this If header requires that all
3122 operand resources must not be locked with locktoken:write1 and must
3123 be locked with locktoken:write2.
3125 9.4.4 Matching Function
3127 When performing If header processing, the definition of a matching
3128 state token or entity tag is as follows.
3130 Matching entity tag: Where the entity tag matches an entity tag
3131 associated with that resource.
3133 Matching state token: Where there is an exact match between the state
3134 token in the If header and any state token on the resource.
3138 Goland, et al. Standards Track [Page 56]
3140 RFC 2518 WEBDAV February 1999
3143 9.4.5 If Header and Non-DAV Compliant Proxies
3145 Non-DAV compliant proxies will not honor the If header, since they
3146 will not understand the If header, and HTTP requires non-understood
3147 headers to be ignored. When communicating with HTTP/1.1 proxies, the
3148 "Cache-Control: no-cache" request header MUST be used so as to
3149 prevent the proxy from improperly trying to service the request from
3150 its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache"
3151 request header MUST be used for the same reason.
3153 9.5 Lock-Token Header
3155 Lock-Token = "Lock-Token" ":" Coded-URL
3157 The Lock-Token request header is used with the UNLOCK method to
3158 identify the lock to be removed. The lock token in the Lock-Token
3159 request header MUST identify a lock that contains the resource
3160 identified by Request-URI as a member.
3162 The Lock-Token response header is used with the LOCK method to
3163 indicate the lock token created as a result of a successful LOCK
3164 request to create a new lock.
3166 9.6 Overwrite Header
3168 Overwrite = "Overwrite" ":" ("T" | "F")
3170 The Overwrite header specifies whether the server should overwrite
3171 the state of a non-null destination resource during a COPY or MOVE.
3172 A value of "F" states that the server must not perform the COPY or
3173 MOVE operation if the state of the destination resource is non-null.
3174 If the overwrite header is not included in a COPY or MOVE request
3175 then the resource MUST treat the request as if it has an overwrite
3176 header of value "T". While the Overwrite header appears to duplicate
3177 the functionality of the If-Match: * header of HTTP/1.1, If-Match
3178 applies only to the Request-URI, and not to the Destination of a COPY
3181 If a COPY or MOVE is not performed due to the value of the Overwrite
3182 header, the method MUST fail with a 412 (Precondition Failed) status
3185 All DAV compliant resources MUST support the Overwrite header.
3187 9.7 Status-URI Response Header
3189 The Status-URI response header may be used with the 102 (Processing)
3190 status code to inform the client as to the status of a method.
3194 Goland, et al. Standards Track [Page 57]
3196 RFC 2518 WEBDAV February 1999
3199 Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code
3200 is defined in 6.1.1 of [RFC2068]
3202 The URIs listed in the header are source resources which have been
3203 affected by the outstanding method. The status code indicates the
3204 resolution of the method on the identified resource. So, for
3205 example, if a MOVE method on a collection is outstanding and a 102
3206 (Processing) response with a Status-URI response header is returned,
3207 the included URIs will indicate resources that have had move
3208 attempted on them and what the result was.
3210 9.8 Timeout Request Header
3212 TimeOut = "Timeout" ":" 1#TimeType
3213 TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
3214 DAVTimeOutVal = 1*digit
3215 Other = "Extend" field-value ; See section 4.2 of [RFC2068]
3217 Clients may include Timeout headers in their LOCK requests. However,
3218 the server is not required to honor or even consider these requests.
3219 Clients MUST NOT submit a Timeout request header with any method
3220 other than a LOCK method.
3222 A Timeout request header MUST contain at least one TimeType and may
3223 contain multiple TimeType entries. The purpose of listing multiple
3224 TimeType entries is to indicate multiple different values and value
3225 types that are acceptable to the client. The client lists the
3226 TimeType entries in order of preference.
3228 Timeout response values MUST use a Second value, Infinite, or a
3229 TimeType the client has indicated familiarity with. The server may
3230 assume a client is familiar with any TimeType submitted in a Timeout
3233 The "Second" TimeType specifies the number of seconds that will
3234 elapse between granting of the lock at the server, and the automatic
3235 removal of the lock. The timeout value for TimeType "Second" MUST
3236 NOT be greater than 2^32-1.
3238 The timeout counter SHOULD be restarted any time an owner of the lock
3239 sends a method to any member of the lock, including unsupported
3240 methods, or methods which are unsuccessful. However the lock MUST be
3241 refreshed if a refresh LOCK method is successfully received.
3243 If the timeout expires then the lock may be lost. Specifically, if
3244 the server wishes to harvest the lock upon time-out, the server
3245 SHOULD act as if an UNLOCK method was executed by the server on the
3246 resource using the lock token of the timed-out lock, performed with
3250 Goland, et al. Standards Track [Page 58]
3252 RFC 2518 WEBDAV February 1999
3255 its override authority. Thus logs should be updated with the
3256 disposition of the lock, notifications should be sent, etc., just as
3257 they would be for an UNLOCK request.
3259 Servers are advised to pay close attention to the values submitted by
3260 clients, as they will be indicative of the type of activity the
3261 client intends to perform. For example, an applet running in a
3262 browser may need to lock a resource, but because of the instability
3263 of the environment within which the applet is running, the applet may
3264 be turned off without warning. As a result, the applet is likely to
3265 ask for a relatively small timeout value so that if the applet dies,
3266 the lock can be quickly harvested. However, a document management
3267 system is likely to ask for an extremely long timeout because its
3268 user may be planning on going off-line.
3270 A client MUST NOT assume that just because the time-out has expired
3271 the lock has been lost.
3273 10 Status Code Extensions to HTTP/1.1
3275 The following status codes are added to those defined in HTTP/1.1
3280 The 102 (Processing) status code is an interim response used to
3281 inform the client that the server has accepted the complete request,
3282 but has not yet completed it. This status code SHOULD only be sent
3283 when the server has a reasonable expectation that the request will
3284 take significant time to complete. As guidance, if a method is taking
3285 longer than 20 seconds (a reasonable, but arbitrary value) to process
3286 the server SHOULD return a 102 (Processing) response. The server MUST
3287 send a final response after the request has been completed.
3289 Methods can potentially take a long period of time to process,
3290 especially methods that support the Depth header. In such cases the
3291 client may time-out the connection while waiting for a response. To
3292 prevent this the server may return a 102 (Processing) status code to
3293 indicate to the client that the server is still processing the
3296 10.2 207 Multi-Status
3298 The 207 (Multi-Status) status code provides status for multiple
3299 independent operations (see section 11 for more information).
3306 Goland, et al. Standards Track [Page 59]
3308 RFC 2518 WEBDAV February 1999
3311 10.3 422 Unprocessable Entity
3313 The 422 (Unprocessable Entity) status code means the server
3314 understands the content type of the request entity (hence a
3315 415(Unsupported Media Type) status code is inappropriate), and the
3316 syntax of the request entity is correct (thus a 400 (Bad Request)
3317 status code is inappropriate) but was unable to process the contained
3318 instructions. For example, this error condition may occur if an XML
3319 request body contains well-formed (i.e., syntactically correct), but
3320 semantically erroneous XML instructions.
3324 The 423 (Locked) status code means the source or destination resource
3325 of a method is locked.
3327 10.5 424 Failed Dependency
3329 The 424 (Failed Dependency) status code means that the method could
3330 not be performed on the resource because the requested action
3331 depended on another action and that action failed. For example, if a
3332 command in a PROPPATCH method fails then, at minimum, the rest of the
3333 commands will also fail with 424 (Failed Dependency).
3335 10.6 507 Insufficient Storage
3337 The 507 (Insufficient Storage) status code means the method could not
3338 be performed on the resource because the server is unable to store
3339 the representation needed to successfully complete the request. This
3340 condition is considered to be temporary. If the request which
3341 received this status code was the result of a user action, the
3342 request MUST NOT be repeated until it is requested by a separate user
3345 11 Multi-Status Response
3347 The default 207 (Multi-Status) response body is a text/xml or
3348 application/xml HTTP entity that contains a single XML element called
3349 multistatus, which contains a set of XML elements called response
3350 which contain 200, 300, 400, and 500 series status codes generated
3351 during the method invocation. 100 series status codes SHOULD NOT be
3352 recorded in a response XML element.
3362 Goland, et al. Standards Track [Page 60]
3364 RFC 2518 WEBDAV February 1999
3367 12 XML Element Definitions
3369 In the section below, the final line of each section gives the
3370 element type declaration using the format defined in [REC-XML]. The
3371 "Value" field, where present, specifies further restrictions on the
3372 allowable contents of the XML element using BNF (i.e., to further
3373 restrict the values of a PCDATA element).
3375 12.1 activelock XML Element
3379 Purpose: Describes a lock on a resource.
3381 <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
3384 12.1.1 depth XML Element
3388 Purpose: The value of the Depth header.
3389 Value: "0" | "1" | "infinity"
3391 <!ELEMENT depth (#PCDATA) >
3393 12.1.2 locktoken XML Element
3397 Purpose: The lock token associated with a lock.
3398 Description: The href contains one or more opaque lock token URIs
3399 which all refer to the same lock (i.e., the OpaqueLockToken-URI
3400 production in section 6.4).
3402 <!ELEMENT locktoken (href+) >
3404 12.1.3 timeout XML Element
3408 Purpose: The timeout associated with a lock
3409 Value: TimeType ;Defined in section 9.8
3411 <!ELEMENT timeout (#PCDATA) >
3418 Goland, et al. Standards Track [Page 61]
3420 RFC 2518 WEBDAV February 1999
3423 12.2 collection XML Element
3427 Purpose: Identifies the associated resource as a collection. The
3428 resourcetype property of a collection resource MUST have this value.
3430 <!ELEMENT collection EMPTY >
3432 12.3 href XML Element
3436 Purpose: Identifies the content of the element as a URI.
3437 Value: URI ; See section 3.2.1 of [RFC2068]
3439 <!ELEMENT href (#PCDATA)>
3441 12.4 link XML Element
3445 Purpose: Identifies the property as a link and contains the source
3446 and destination of that link.
3447 Description: The link XML element is used to provide the sources and
3448 destinations of a link. The name of the property containing the link
3449 XML element provides the type of the link. Link is a multi-valued
3450 element, so multiple links may be used together to indicate multiple
3451 links with the same type. The values in the href XML elements inside
3452 the src and dst XML elements of the link XML element MUST NOT be
3453 rejected if they point to resources which do not exist.
3455 <!ELEMENT link (src+, dst+) >
3457 12.4.1 dst XML Element
3461 Purpose: Indicates the destination of a link
3464 <!ELEMENT dst (#PCDATA) >
3466 12.4.2 src XML Element
3470 Purpose: Indicates the source of a link.
3474 Goland, et al. Standards Track [Page 62]
3476 RFC 2518 WEBDAV February 1999
3481 <!ELEMENT src (#PCDATA) >
3483 12.5 lockentry XML Element
3487 Purpose: Defines the types of locks that can be used with the
3490 <!ELEMENT lockentry (lockscope, locktype) >
3492 12.6 lockinfo XML Element
3496 Purpose: The lockinfo XML element is used with a LOCK method to
3497 specify the type of lock the client wishes to have created.
3499 <!ELEMENT lockinfo (lockscope, locktype, owner?) >
3501 12.7 lockscope XML Element
3505 Purpose: Specifies whether a lock is an exclusive lock, or a
3508 <!ELEMENT lockscope (exclusive | shared) >
3510 12.7.1 exclusive XML Element
3514 Purpose: Specifies an exclusive lock
3516 <!ELEMENT exclusive EMPTY >
3518 12.7.2 shared XML Element
3522 Purpose: Specifies a shared lock
3524 <!ELEMENT shared EMPTY >
3530 Goland, et al. Standards Track [Page 63]
3532 RFC 2518 WEBDAV February 1999
3535 12.8 locktype XML Element
3539 Purpose: Specifies the access type of a lock. At present, this
3540 specification only defines one lock type, the write lock.
3542 <!ELEMENT locktype (write) >
3544 12.8.1 write XML Element
3548 Purpose: Specifies a write lock.
3550 <!ELEMENT write EMPTY >
3552 12.9 multistatus XML Element
3556 Purpose: Contains multiple response messages.
3557 Description: The responsedescription at the top level is used to
3558 provide a general message describing the overarching nature of the
3559 response. If this value is available an application may use it
3560 instead of presenting the individual response descriptions contained
3561 within the responses.
3563 <!ELEMENT multistatus (response+, responsedescription?) >
3565 12.9.1 response XML Element
3569 Purpose: Holds a single response describing the effect of a
3570 method on resource and/or its properties.
3571 Description: A particular href MUST NOT appear more than once as the
3572 child of a response XML element under a multistatus XML element.
3573 This requirement is necessary in order to keep processing costs for a
3574 response to linear time. Essentially, this prevents having to search
3575 in order to group together all the responses by href. There are,
3576 however, no requirements regarding ordering based on href values.
3578 <!ELEMENT response (href, ((href*, status)|(propstat+)),
3579 responsedescription?) >
3586 Goland, et al. Standards Track [Page 64]
3588 RFC 2518 WEBDAV February 1999
3591 12.9.1.1 propstat XML Element
3595 Purpose: Groups together a prop and status element that is
3596 associated with a particular href element.
3597 Description: The propstat XML element MUST contain one prop XML
3598 element and one status XML element. The contents of the prop XML
3599 element MUST only list the names of properties to which the result in
3600 the status element applies.
3602 <!ELEMENT propstat (prop, status, responsedescription?) >
3604 12.9.1.2 status XML Element
3608 Purpose: Holds a single HTTP status-line
3609 Value: status-line ;status-line defined in [RFC2068]
3611 <!ELEMENT status (#PCDATA) >
3613 12.9.2 responsedescription XML Element
3615 Name: responsedescription
3617 Purpose: Contains a message that can be displayed to the user
3618 explaining the nature of the response.
3619 Description: This XML element provides information suitable to be
3620 presented to a user.
3622 <!ELEMENT responsedescription (#PCDATA) >
3624 12.10 owner XML Element
3628 Purpose: Provides information about the principal taking out a
3630 Description: The owner XML element provides information sufficient
3631 for either directly contacting a principal (such as a telephone
3632 number or Email URI), or for discovering the principal (such as the
3633 URL of a homepage) who owns a lock.
3635 <!ELEMENT owner ANY>
3642 Goland, et al. Standards Track [Page 65]
3644 RFC 2518 WEBDAV February 1999
3647 12.11 prop XML element
3651 Purpose: Contains properties related to a resource.
3652 Description: The prop XML element is a generic container for
3653 properties defined on resources. All elements inside a prop XML
3654 element MUST define properties related to the resource. No other
3655 elements may be used inside of a prop element.
3659 12.12 propertybehavior XML element
3661 Name: propertybehavior Namespace: DAV: Purpose: Specifies
3662 how properties are handled during a COPY or MOVE.
3663 Description: The propertybehavior XML element specifies how
3664 properties are handled during a COPY or MOVE. If this XML element is
3665 not included in the request body then the server is expected to act
3666 as defined by the default property handling behavior of the
3667 associated method. All WebDAV compliant resources MUST support the
3668 propertybehavior XML element.
3670 <!ELEMENT propertybehavior (omit | keepalive) >
3672 12.12.1 keepalive XML element
3676 Purpose: Specifies requirements for the copying/moving of live
3678 Description: If a list of URIs is included as the value of keepalive
3679 then the named properties MUST be "live" after they are copied
3680 (moved) to the destination resource of a COPY (or MOVE). If the
3681 value "*" is given for the keepalive XML element, this designates
3682 that all live properties on the source resource MUST be live on the
3683 destination. If the requirements specified by the keepalive element
3684 can not be honored then the method MUST fail with a 412 (Precondition
3685 Failed). All DAV compliant resources MUST support the keepalive XML
3686 element for use with the COPY and MOVE methods.
3687 Value: "*" ; #PCDATA value can only be "*"
3689 <!ELEMENT keepalive (#PCDATA | href+) >
3698 Goland, et al. Standards Track [Page 66]
3700 RFC 2518 WEBDAV February 1999
3703 12.12.2 omit XML element
3707 Purpose: The omit XML element instructs the server that it should
3708 use best effort to copy properties but a failure to copy a property
3709 MUST NOT cause the method to fail. Description: The default behavior
3710 for a COPY or MOVE is to copy/move all properties or fail the method.
3711 In certain circumstances, such as when a server copies a resource
3712 over another protocol such as FTP, it may not be possible to
3713 copy/move the properties associated with the resource. Thus any
3714 attempt to copy/move over FTP would always have to fail because
3715 properties could not be moved over, even as dead properties. All DAV
3716 compliant resources MUST support the omit XML element on COPY/MOVE
3719 <!ELEMENT omit EMPTY >
3721 12.13 propertyupdate XML element
3723 Name: propertyupdate
3725 Purpose: Contains a request to alter the properties on a
3727 Description: This XML element is a container for the information
3728 required to modify the properties on the resource. This XML element
3731 <!ELEMENT propertyupdate (remove | set)+ >
3733 12.13.1 remove XML element
3737 Purpose: Lists the DAV properties to be removed from a resource.
3738 Description: Remove instructs that the properties specified in prop
3739 should be removed. Specifying the removal of a property that does
3740 not exist is not an error. All the XML elements in a prop XML
3741 element inside of a remove XML element MUST be empty, as only the
3742 names of properties to be removed are required.
3744 <!ELEMENT remove (prop) >
3746 12.13.2 set XML element
3750 Purpose: Lists the DAV property values to be set for a resource.
3754 Goland, et al. Standards Track [Page 67]
3756 RFC 2518 WEBDAV February 1999
3759 Description: The set XML element MUST contain only a prop XML
3760 element. The elements contained by the prop XML element inside the
3761 set XML element MUST specify the name and value of properties that
3762 are set on the resource identified by Request-URI. If a property
3763 already exists then its value is replaced. Language tagging
3764 information in the property's value (in the "xml:lang" attribute, if
3765 present) MUST be persistently stored along with the property, and
3766 MUST be subsequently retrievable using PROPFIND.
3768 <!ELEMENT set (prop) >
3770 12.14 propfind XML Element
3774 Purpose: Specifies the properties to be returned from a PROPFIND
3775 method. Two special elements are specified for use with propfind,
3776 allprop and propname. If prop is used inside propfind it MUST only
3777 contain property names, not values.
3779 <!ELEMENT propfind (allprop | propname | prop) >
3781 12.14.1 allprop XML Element
3783 Name: allprop Namespace: DAV: Purpose: The allprop XML
3784 element specifies that all property names and values on the resource
3787 <!ELEMENT allprop EMPTY >
3789 12.14.2 propname XML Element
3791 Name: propname Namespace: DAV: Purpose: The propname XML
3792 element specifies that only a list of property names on the resource
3795 <!ELEMENT propname EMPTY >
3799 For DAV properties, the name of the property is also the same as the
3800 name of the XML element that contains its value. In the section
3801 below, the final line of each section gives the element type
3802 declaration using the format defined in [REC-XML]. The "Value" field,
3803 where present, specifies further restrictions on the allowable
3804 contents of the XML element using BNF (i.e., to further restrict the
3805 values of a PCDATA element).
3810 Goland, et al. Standards Track [Page 68]
3812 RFC 2518 WEBDAV February 1999
3815 13.1 creationdate Property
3819 Purpose: Records the time and date the resource was created.
3820 Value: date-time ; See Appendix 2
3821 Description: The creationdate property should be defined on all DAV
3822 compliant resources. If present, it contains a timestamp of the
3823 moment when the resource was created (i.e., the moment it had non-
3826 <!ELEMENT creationdate (#PCDATA) >
3828 13.2 displayname Property
3832 Purpose: Provides a name for the resource that is suitable for
3833 presentation to a user.
3834 Description: The displayname property should be defined on all DAV
3835 compliant resources. If present, the property contains a description
3836 of the resource that is suitable for presentation to a user.
3838 <!ELEMENT displayname (#PCDATA) >
3840 13.3 getcontentlanguage Property
3842 Name: getcontentlanguage
3844 Purpose: Contains the Content-Language header returned by a GET
3845 without accept headers
3846 Description: The getcontentlanguage property MUST be defined on any
3847 DAV compliant resource that returns the Content-Language header on a
3849 Value: language-tag ;language-tag is defined in section 14.13
3852 <!ELEMENT getcontentlanguage (#PCDATA) >
3854 13.4 getcontentlength Property
3856 Name: getcontentlength
3858 Purpose: Contains the Content-Length header returned by a GET
3859 without accept headers.
3860 Description: The getcontentlength property MUST be defined on any
3861 DAV compliant resource that returns the Content-Length header in
3866 Goland, et al. Standards Track [Page 69]
3868 RFC 2518 WEBDAV February 1999
3871 Value: content-length ; see section 14.14 of [RFC2068]
3873 <!ELEMENT getcontentlength (#PCDATA) >
3875 13.5 getcontenttype Property
3877 Name: getcontenttype
3879 Purpose: Contains the Content-Type header returned by a GET
3880 without accept headers.
3881 Description: This getcontenttype property MUST be defined on any DAV
3882 compliant resource that returns the Content-Type header in response
3884 Value: media-type ; defined in section 3.7 of [RFC2068]
3886 <!ELEMENT getcontenttype (#PCDATA) >
3888 13.6 getetag Property
3892 Purpose: Contains the ETag header returned by a GET without
3894 Description: The getetag property MUST be defined on any DAV
3895 compliant resource that returns the Etag header.
3896 Value: entity-tag ; defined in section 3.11 of [RFC2068]
3898 <!ELEMENT getetag (#PCDATA) >
3900 13.7 getlastmodified Property
3902 Name: getlastmodified
3904 Purpose: Contains the Last-Modified header returned by a GET
3905 method without accept headers.
3906 Description: Note that the last-modified date on a resource may
3907 reflect changes in any part of the state of the resource, not
3908 necessarily just a change to the response to the GET method. For
3909 example, a change in a property may cause the last-modified date to
3910 change. The getlastmodified property MUST be defined on any DAV
3911 compliant resource that returns the Last-Modified header in response
3913 Value: HTTP-date ; defined in section 3.3.1 of [RFC2068]
3915 <!ELEMENT getlastmodified (#PCDATA) >
3922 Goland, et al. Standards Track [Page 70]
3924 RFC 2518 WEBDAV February 1999
3927 13.8 lockdiscovery Property
3931 Purpose: Describes the active locks on a resource
3932 Description: The lockdiscovery property returns a listing of who has
3933 a lock, what type of lock he has, the timeout type and the time
3934 remaining on the timeout, and the associated lock token. The server
3935 is free to withhold any or all of this information if the requesting
3936 principal does not have sufficient access rights to see the requested
3939 <!ELEMENT lockdiscovery (activelock)* >
3941 13.8.1 Example - Retrieving the lockdiscovery Property
3945 PROPFIND /container/ HTTP/1.1
3947 Content-Length: xxxx
3948 Content-Type: text/xml; charset="utf-8"
3950 <?xml version="1.0" encoding="utf-8" ?>
3951 <D:propfind xmlns:D='DAV:'>
3952 <D:prop><D:lockdiscovery/></D:prop>
3957 HTTP/1.1 207 Multi-Status
3958 Content-Type: text/xml; charset="utf-8"
3959 Content-Length: xxxx
3961 <?xml version="1.0" encoding="utf-8" ?>
3962 <D:multistatus xmlns:D='DAV:'>
3964 <D:href>http://www.foo.bar/container/</D:href>
3969 <D:locktype><D:write/></D:locktype>
3970 <D:lockscope><D:exclusive/></D:lockscope>
3971 <D:depth>0</D:depth>
3972 <D:owner>Jane Smith</D:owner>
3973 <D:timeout>Infinite</D:timeout>
3978 Goland, et al. Standards Track [Page 71]
3980 RFC 2518 WEBDAV February 1999
3984 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
3990 <D:status>HTTP/1.1 200 OK</D:status>
3995 This resource has a single exclusive write lock on it, with an
3998 13.9 resourcetype Property
4002 Purpose: Specifies the nature of the resource.
4003 Description: The resourcetype property MUST be defined on all DAV
4004 compliant resources. The default value is empty.
4006 <!ELEMENT resourcetype ANY >
4008 13.10 source Property
4012 Purpose: The destination of the source link identifies the
4013 resource that contains the unprocessed source of the link's source.
4014 Description: The source of the link (src) is typically the URI of the
4015 output resource on which the link is defined, and there is typically
4016 only one destination (dst) of the link, which is the URI where the
4017 unprocessed source of the resource may be accessed. When more than
4018 one link destination exists, this specification asserts no policy on
4021 <!ELEMENT source (link)* >
4023 13.10.1 Example - A source Property
4025 <?xml version="1.0" encoding="utf-8" ?>
4026 <D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
4029 <F:projfiles>Source</F:projfiles>
4030 <D:src>http://foo.bar/program</D:src>
4034 Goland, et al. Standards Track [Page 72]
4036 RFC 2518 WEBDAV February 1999
4039 <D:dst>http://foo.bar/src/main.c</D:dst>
4042 <F:projfiles>Library</F:projfiles>
4043 <D:src>http://foo.bar/program</D:src>
4044 <D:dst>http://foo.bar/src/main.lib</D:dst>
4047 <F:projfiles>Makefile</F:projfiles>
4048 <D:src>http://foo.bar/program</D:src>
4049 <D:dst>http://foo.bar/src/makefile</D:dst>
4054 In this example the resource http://foo.bar/program has a source
4055 property that contains three links. Each link contains three
4056 elements, two of which, src and dst, are part of the DAV schema
4057 defined in this document, and one which is defined by the schema
4058 http://www.foocorp.com/project/ (Source, Library, and Makefile). A
4059 client which only implements the elements in the DAV spec will not
4060 understand the foocorp elements and will ignore them, thus seeing the
4061 expected source and destination links. An enhanced client may know
4062 about the foocorp elements and be able to present the user with
4063 additional information about the links. This example demonstrates
4064 the power of XML markup, allowing element values to be enhanced
4065 without breaking older clients.
4067 13.11 supportedlock Property
4071 Purpose: To provide a listing of the lock capabilities supported
4073 Description: The supportedlock property of a resource returns a
4074 listing of the combinations of scope and access types which may be
4075 specified in a lock request on the resource. Note that the actual
4076 contents are themselves controlled by access controls so a server is
4077 not required to provide information the client is not authorized to
4080 <!ELEMENT supportedlock (lockentry)* >
4082 13.11.1 Example - Retrieving the supportedlock Property
4086 PROPFIND /container/ HTTP/1.1
4090 Goland, et al. Standards Track [Page 73]
4092 RFC 2518 WEBDAV February 1999
4096 Content-Length: xxxx
4097 Content-Type: text/xml; charset="utf-8"
4099 <?xml version="1.0" encoding="utf-8" ?>
4100 <D:propfind xmlns:D="DAV:">
4101 <D:prop><D:supportedlock/></D:prop>
4106 HTTP/1.1 207 Multi-Status
4107 Content-Type: text/xml; charset="utf-8"
4108 Content-Length: xxxx
4110 <?xml version="1.0" encoding="utf-8" ?>
4111 <D:multistatus xmlns:D="DAV:">
4113 <D:href>http://www.foo.bar/container/</D:href>
4118 <D:lockscope><D:exclusive/></D:lockscope>
4119 <D:locktype><D:write/></D:locktype>
4122 <D:lockscope><D:shared/></D:lockscope>
4123 <D:locktype><D:write/></D:locktype>
4127 <D:status>HTTP/1.1 200 OK</D:status>
4132 14 Instructions for Processing XML in DAV
4134 All DAV compliant resources MUST ignore any unknown XML element and
4135 all its children encountered while processing a DAV method that uses
4136 XML as its command language.
4138 This restriction also applies to the processing, by clients, of DAV
4139 property values where unknown XML elements SHOULD be ignored unless
4140 the property's schema declares otherwise.
4146 Goland, et al. Standards Track [Page 74]
4148 RFC 2518 WEBDAV February 1999
4151 This restriction does not apply to setting dead DAV properties on the
4152 server where the server MUST record unknown XML elements.
4154 Additionally, this restriction does not apply to the use of XML where
4155 XML happens to be the content type of the entity body, for example,
4156 when used as the body of a PUT.
4158 Since XML can be transported as text/xml or application/xml, a DAV
4159 server MUST accept DAV method requests with XML parameters
4160 transported as either text/xml or application/xml, and DAV client
4161 MUST accept XML responses using either text/xml or application/xml.
4163 15 DAV Compliance Classes
4165 A DAV compliant resource can choose from two classes of compliance.
4166 A client can discover the compliance classes of a resource by
4167 executing OPTIONS on the resource, and examining the "DAV" header
4170 Since this document describes extensions to the HTTP/1.1 protocol,
4171 minimally all DAV compliant resources, clients, and proxies MUST be
4172 compliant with [RFC2068].
4174 Compliance classes are not necessarily sequential. A resource that is
4175 class 2 compliant must also be class 1 compliant; but if additional
4176 compliance classes are defined later, a resource that is class 1, 2,
4177 and 4 compliant might not be class 3 compliant. Also note that
4178 identifiers other than numbers may be used as compliance class
4183 A class 1 compliant resource MUST meet all "MUST" requirements in all
4184 sections of this document.
4186 Class 1 compliant resources MUST return, at minimum, the value "1" in
4187 the DAV header on all responses to the OPTIONS method.
4191 A class 2 compliant resource MUST meet all class 1 requirements and
4192 support the LOCK method, the supportedlock property, the
4193 lockdiscovery property, the Time-Out response header and the Lock-
4194 Token request header. A class "2" compliant resource SHOULD also
4195 support the Time-Out request header and the owner XML element.
4197 Class 2 compliant resources MUST return, at minimum, the values "1"
4198 and "2" in the DAV header on all responses to the OPTIONS method.
4202 Goland, et al. Standards Track [Page 75]
4204 RFC 2518 WEBDAV February 1999
4207 16 Internationalization Considerations
4209 In the realm of internationalization, this specification complies
4210 with the IETF Character Set Policy [RFC2277]. In this specification,
4211 human-readable fields can be found either in the value of a property,
4212 or in an error message returned in a response entity body. In both
4213 cases, the human-readable content is encoded using XML, which has
4214 explicit provisions for character set tagging and encoding, and
4215 requires that XML processors read XML elements encoded, at minimum,
4216 using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual plane.
4217 XML examples in this specification demonstrate use of the charset
4218 parameter of the Content-Type header, as defined in [RFC2376], as
4219 well as the XML "encoding" attribute, which together provide charset
4220 identification information for MIME and XML processors.
4222 XML also provides a language tagging capability for specifying the
4223 language of the contents of a particular XML element. XML uses
4224 either IANA registered language tags (see [RFC1766]) or ISO 639
4225 language tags [ISO-639] in the "xml:lang" attribute of an XML element
4226 to identify the language of its content and attributes.
4228 WebDAV applications MUST support the character set tagging, character
4229 set encoding, and the language tagging functionality of the XML
4230 specification. Implementors of WebDAV applications are strongly
4231 encouraged to read "XML Media Types" [RFC2376] for instruction on
4232 which MIME media type to use for XML transport, and on use of the
4233 charset parameter of the Content-Type header.
4235 Names used within this specification fall into three categories:
4236 names of protocol elements such as methods and headers, names of XML
4237 elements, and names of properties. Naming of protocol elements
4238 follows the precedent of HTTP, using English names encoded in USASCII
4239 for methods and headers. Since these protocol elements are not
4240 visible to users, and are in fact simply long token identifiers, they
4241 do not need to support encoding in multiple character sets.
4242 Similarly, though the names of XML elements used in this
4243 specification are English names encoded in UTF-8, these names are not
4244 visible to the user, and hence do not need to support multiple
4245 character set encodings.
4247 The name of a property defined on a resource is a URI. Although some
4248 applications (e.g., a generic property viewer) will display property
4249 URIs directly to their users, it is expected that the typical
4250 application will use a fixed set of properties, and will provide a
4251 mapping from the property name URI to a human-readable field when
4252 displaying the property name to a user. It is only in the case where
4258 Goland, et al. Standards Track [Page 76]
4260 RFC 2518 WEBDAV February 1999
4263 the set of properties is not known ahead of time that an application
4264 need display a property name URI to a user. We recommend that
4265 applications provide human-readable property names wherever feasible.
4267 For error reporting, we follow the convention of HTTP/1.1 status
4268 codes, including with each status code a short, English description
4269 of the code (e.g., 423 (Locked)). While the possibility exists that
4270 a poorly crafted user agent would display this message to a user,
4271 internationalized applications will ignore this message, and display
4272 an appropriate message in the user's language and character set.
4274 Since interoperation of clients and servers does not require locale
4275 information, this specification does not specify any mechanism for
4276 transmission of this information.
4278 17 Security Considerations
4280 This section is provided to detail issues concerning security
4281 implications of which WebDAV applications need to be aware.
4283 All of the security considerations of HTTP/1.1 (discussed in
4284 [RFC2068]) and XML (discussed in [RFC2376]) also apply to WebDAV. In
4285 addition, the security risks inherent in remote authoring require
4286 stronger authentication technology, introduce several new privacy
4287 concerns, and may increase the hazards from poor server design.
4288 These issues are detailed below.
4290 17.1 Authentication of Clients
4292 Due to their emphasis on authoring, WebDAV servers need to use
4293 authentication technology to protect not just access to a network
4294 resource, but the integrity of the resource as well. Furthermore,
4295 the introduction of locking functionality requires support for
4298 A password sent in the clear over an insecure channel is an
4299 inadequate means for protecting the accessibility and integrity of a
4300 resource as the password may be intercepted. Since Basic
4301 authentication for HTTP/1.1 performs essentially clear text
4302 transmission of a password, Basic authentication MUST NOT be used to
4303 authenticate a WebDAV client to a server unless the connection is
4304 secure. Furthermore, a WebDAV server MUST NOT send Basic
4305 authentication credentials in a WWW-Authenticate header unless the
4306 connection is secure. Examples of secure connections include a
4307 Transport Layer Security (TLS) connection employing a strong cipher
4308 suite with mutual authentication of client and server, or a
4309 connection over a network which is physically secure, for example, an
4310 isolated network in a building with restricted access.
4314 Goland, et al. Standards Track [Page 77]
4316 RFC 2518 WEBDAV February 1999
4319 WebDAV applications MUST support the Digest authentication scheme
4320 [RFC2069]. Since Digest authentication verifies that both parties to
4321 a communication know a shared secret, a password, without having to
4322 send that secret in the clear, Digest authentication avoids the
4323 security problems inherent in Basic authentication while providing a
4324 level of authentication which is useful in a wide range of scenarios.
4326 17.2 Denial of Service
4328 Denial of service attacks are of special concern to WebDAV servers.
4329 WebDAV plus HTTP enables denial of service attacks on every part of a
4332 The underlying storage can be attacked by PUTting extremely large
4335 Asking for recursive operations on large collections can attack
4338 Making multiple pipelined requests on multiple connections can attack
4339 network connections.
4341 WebDAV servers need to be aware of the possibility of a denial of
4342 service attack at all levels.
4344 17.3 Security through Obscurity
4346 WebDAV provides, through the PROPFIND method, a mechanism for listing
4347 the member resources of a collection. This greatly diminishes the
4348 effectiveness of security or privacy techniques that rely only on the
4349 difficulty of discovering the names of network resources. Users of
4350 WebDAV servers are encouraged to use access control techniques to
4351 prevent unwanted access to resources, rather than depending on the
4352 relative obscurity of their resource names.
4354 17.4 Privacy Issues Connected to Locks
4356 When submitting a lock request a user agent may also submit an owner
4357 XML field giving contact information for the person taking out the
4358 lock (for those cases where a person, rather than a robot, is taking
4359 out the lock). This contact information is stored in a lockdiscovery
4360 property on the resource, and can be used by other collaborators to
4361 begin negotiation over access to the resource. However, in many
4362 cases this contact information can be very private, and should not be
4363 widely disseminated. Servers SHOULD limit read access to the
4364 lockdiscovery property as appropriate. Furthermore, user agents
4370 Goland, et al. Standards Track [Page 78]
4372 RFC 2518 WEBDAV February 1999
4375 SHOULD provide control over whether contact information is sent at
4376 all, and if contact information is sent, control over exactly what
4377 information is sent.
4379 17.5 Privacy Issues Connected to Properties
4381 Since property values are typically used to hold information such as
4382 the author of a document, there is the possibility that privacy
4383 concerns could arise stemming from widespread access to a resource's
4384 property data. To reduce the risk of inadvertent release of private
4385 information via properties, servers are encouraged to develop access
4386 control mechanisms that separate read access to the resource body and
4387 read access to the resource's properties. This allows a user to
4388 control the dissemination of their property data without overly
4389 restricting access to the resource's contents.
4391 17.6 Reduction of Security due to Source Link
4393 HTTP/1.1 warns against providing read access to script code because
4394 it may contain sensitive information. Yet WebDAV, via its source
4395 link facility, can potentially provide a URI for script resources so
4396 they may be authored. For HTTP/1.1, a server could reasonably
4397 prevent access to source resources due to the predominance of read-
4398 only access. WebDAV, with its emphasis on authoring, encourages read
4399 and write access to source resources, and provides the source link
4400 facility to identify the source. This reduces the security benefits
4401 of eliminating access to source resources. Users and administrators
4402 of WebDAV servers should be very cautious when allowing remote
4403 authoring of scripts, limiting read and write access to the source
4404 resources to authorized principals.
4406 17.7 Implications of XML External Entities
4408 XML supports a facility known as "external entities", defined in
4409 section 4.2.2 of [REC-XML], which instruct an XML processor to
4410 retrieve and perform an inline include of XML located at a particular
4411 URI. An external XML entity can be used to append or modify the
4412 document type declaration (DTD) associated with an XML document. An
4413 external XML entity can also be used to include XML within the
4414 content of an XML document. For non-validating XML, such as the XML
4415 used in this specification, including an external XML entity is not
4416 required by [REC-XML]. However, [REC-XML] does state that an XML
4417 processor may, at its discretion, include the external XML entity.
4419 External XML entities have no inherent trustworthiness and are
4420 subject to all the attacks that are endemic to any HTTP GET request.
4421 Furthermore, it is possible for an external XML entity to modify the
4422 DTD, and hence affect the final form of an XML document, in the worst
4426 Goland, et al. Standards Track [Page 79]
4428 RFC 2518 WEBDAV February 1999
4431 case significantly modifying its semantics, or exposing the XML
4432 processor to the security risks discussed in [RFC2376]. Therefore,
4433 implementers must be aware that external XML entities should be
4434 treated as untrustworthy.
4436 There is also the scalability risk that would accompany a widely
4437 deployed application which made use of external XML entities. In
4438 this situation, it is possible that there would be significant
4439 numbers of requests for one external XML entity, potentially
4440 overloading any server which fields requests for the resource
4441 containing the external XML entity.
4443 17.8 Risks Connected with Lock Tokens
4445 This specification, in section 6.4, requires the use of Universal
4446 Unique Identifiers (UUIDs) for lock tokens, in order to guarantee
4447 their uniqueness across space and time. UUIDs, as defined in [ISO-
4448 11578], contain a "node" field which "consists of the IEEE address,
4449 usually the host address. For systems with multiple IEEE 802 nodes,
4450 any available node address can be used." Since a WebDAV server will
4451 issue many locks over its lifetime, the implication is that it will
4452 also be publicly exposing its IEEE 802 address.
4454 There are several risks associated with exposure of IEEE 802
4455 addresses. Using the IEEE 802 address:
4457 * It is possible to track the movement of hardware from subnet to
4460 * It may be possible to identify the manufacturer of the hardware
4461 running a WebDAV server.
4463 * It may be possible to determine the number of each type of computer
4466 Section 6.4.1 of this specification details an alternate mechanism
4467 for generating the "node" field of a UUID without using an IEEE 802
4468 address, which alleviates the risks associated with exposure of IEEE
4469 802 addresses by using an alternate source of uniqueness.
4471 18 IANA Considerations
4473 This document defines two namespaces, the namespace of property
4474 names, and the namespace of WebDAV-specific XML elements used within
4482 Goland, et al. Standards Track [Page 80]
4484 RFC 2518 WEBDAV February 1999
4487 URIs are used for both names, for several reasons. Assignment of a
4488 URI does not require a request to a central naming authority, and
4489 hence allow WebDAV property names and XML elements to be quickly
4490 defined by any WebDAV user or application. URIs also provide a
4491 unique address space, ensuring that the distributed users of WebDAV
4492 will not have collisions among the property names and XML elements
4495 This specification defines a distinguished set of property names and
4496 XML elements that are understood by all WebDAV applications. The
4497 property names and XML elements in this specification are all derived
4498 from the base URI DAV: by adding a suffix to this URI, for example,
4499 DAV:creationdate for the "creationdate" property.
4501 This specification also defines a URI scheme for the encoding of lock
4502 tokens, the opaquelocktoken URI scheme described in section 6.4.
4504 To ensure correct interoperation based on this specification, IANA
4505 must reserve the URI namespaces starting with "DAV:" and with
4506 "opaquelocktoken:" for use by this specification, its revisions, and
4507 related WebDAV specifications.
4509 19 Intellectual Property
4511 The following notice is copied from RFC 2026 [RFC2026], section 10.4,
4512 and describes the position of the IETF concerning intellectual
4513 property claims made against this document.
4515 The IETF takes no position regarding the validity or scope of any
4516 intellectual property or other rights that might be claimed to
4517 pertain to the implementation or use other technology described in
4518 this document or the extent to which any license under such rights
4519 might or might not be available; neither does it represent that it
4520 has made any effort to identify any such rights. Information on the
4521 IETF's procedures with respect to rights in standards-track and
4522 standards-related documentation can be found in BCP-11. Copies of
4523 claims of rights made available for publication and any assurances of
4524 licenses to be made available, or the result of an attempt made to
4525 obtain a general license or permission for the use of such
4526 proprietary rights by implementors or users of this specification can
4527 be obtained from the IETF Secretariat.
4529 The IETF invites any interested party to bring to its attention any
4530 copyrights, patents or patent applications, or other proprietary
4531 rights which may cover technology that may be required to practice
4532 this standard. Please address the information to the IETF Executive
4538 Goland, et al. Standards Track [Page 81]
4540 RFC 2518 WEBDAV February 1999
4545 A specification such as this thrives on piercing critical review and
4546 withers from apathetic neglect. The authors gratefully acknowledge
4547 the contributions of the following people, whose insights were so
4548 valuable at every stage of our work.
4550 Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan
4551 Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-
4552 Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith
4553 Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee
4554 Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan
4555 Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis
4556 Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der
4557 Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven
4558 Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten,
4559 Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff,
4560 Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike
4561 Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi,
4562 Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran,
4563 Fabio Vitali, Gregory Woodhouse, and Lauren Wood.
4565 Two from this list deserve special mention. The contributions by
4566 Larry Masinter have been invaluable, both in helping the formation of
4567 the working group and in patiently coaching the authors along the
4568 way. In so many ways he has set high standards we have toiled to
4569 meet. The contributions of Judith Slein in clarifying the
4570 requirements, and in patiently reviewing draft after draft, both
4571 improved this specification and expanded our minds on document
4574 We would also like to thank John Turner for developing the XML DTD.
4578 21.1 Normative References
4580 [RFC1766] Alvestrand, H., "Tags for the Identification of
4581 Languages", RFC 1766, March 1995.
4583 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
4584 Languages", BCP 18, RFC 2277, January 1998.
4586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
4587 Requirement Levels", BCP 14, RFC 2119, March 1997.
4594 Goland, et al. Standards Track [Page 82]
4596 RFC 2518 WEBDAV February 1999
4599 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
4600 "Uniform Resource Identifiers (URI): Generic Syntax",
4601 RFC 2396, August 1998.
4603 [REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen,
4604 "Extensible Markup Language (XML)." World Wide Web
4605 Consortium Recommendation REC-xml-19980210.
4606 http://www.w3.org/TR/1998/REC-xml-19980210.
4608 [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in
4609 XML". World Wide Web Consortium Recommendation REC-
4610 xml-names-19990114. http://www.w3.org/TR/1999/REC-
4613 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach,
4614 P, Luotonen, A., Sink, E. and L. Stewart, "An
4615 Extension to HTTP : Digest Access Authentication",
4616 RFC 2069, January 1997.
4618 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and
4619 T. Berners-Lee, "Hypertext Transfer Protocol --
4620 HTTP/1.1", RFC 2068, January 1997.
4622 [ISO-639] ISO (International Organization for Standardization).
4623 ISO 639:1988. "Code for the representation of names
4626 [ISO-8601] ISO (International Organization for Standardization).
4627 ISO 8601:1988. "Data elements and interchange formats
4628 - Information interchange - Representation of dates
4631 [ISO-11578] ISO (International Organization for Standardization).
4632 ISO/IEC 11578:1996. "Information technology - Open
4633 Systems Interconnection - Remote Procedure Call
4636 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
4638 [UTF-8] Yergeau, F., "UTF-8, a transformation format of
4639 Unicode and ISO 10646", RFC 2279, January 1998.
4641 21.2 Informational References
4643 [RFC2026] Bradner, S., "The Internet Standards Process - Revision
4644 3", BCP 9, RFC 2026, October 1996.
4650 Goland, et al. Standards Track [Page 83]
4652 RFC 2518 WEBDAV February 1999
4655 [RFC1807] Lasher, R. and D. Cohen, "A Format for Bibliographic
4656 Records", RFC 1807, June 1995.
4658 [WF] C. Lagoze, "The Warwick Framework: A Container
4659 Architecture for Diverse Sets of Metadata", D-Lib
4660 Magazine, July/August 1996.
4661 http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
4663 [USMARC] Network Development and MARC Standards, Office, ed. 1994.
4664 "USMARC Format for Bibliographic Data", 1994. Washington,
4665 DC: Cataloging Distribution Service, Library of Congress.
4667 [REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS
4668 Label Distribution Label Syntax and Communication
4669 Protocols" Version 1.1, World Wide Web Consortium
4670 Recommendation REC-PICS-labels-961031.
4671 http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
4673 [RFC2291] Slein, J., Vitali, F., Whitehead, E. and D. Durand,
4674 "Requirements for Distributed Authoring and Versioning
4675 Protocol for the World Wide Web", RFC 2291, February 1998.
4677 [RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin
4678 Core Metadata for Resource Discovery", RFC 2413, September
4681 [RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
4684 22 Authors' Addresses
4687 Microsoft Corporation
4689 Redmond, WA 98052-6399
4691 EMail: yarong@microsoft.com
4694 E. J. Whitehead, Jr.
4695 Dept. Of Information and Computer Science
4696 University of California, Irvine
4697 Irvine, CA 92697-3425
4699 EMail: ejw@ics.uci.edu
4706 Goland, et al. Standards Track [Page 84]
4708 RFC 2518 WEBDAV February 1999
4713 685 East Middlefield Road
4714 Mountain View, CA 94043
4716 EMail: asad@netscape.com
4721 1555 N. Technology Way
4725 EMail: srcarter@novell.com
4730 1555 N. Technology Way
4734 EMail: dcjensen@novell.com
4762 Goland, et al. Standards Track [Page 85]
4764 RFC 2518 WEBDAV February 1999
4769 23.1 Appendix 1 - WebDAV Document Type Definition
4771 This section provides a document type definition, following the rules
4772 in [REC-XML], for the XML elements used in the protocol stream and in
4773 the values of properties. It collects the element definitions given
4774 in sections 12 and 13.
4776 <!DOCTYPE webdav-1.0 [
4778 <!--============ XML Elements from Section 12 ==================-->
4780 <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
4783 <!ELEMENT lockentry (lockscope, locktype) >
4784 <!ELEMENT lockinfo (lockscope, locktype, owner?) >
4786 <!ELEMENT locktype (write) >
4787 <!ELEMENT write EMPTY >
4789 <!ELEMENT lockscope (exclusive | shared) >
4790 <!ELEMENT exclusive EMPTY >
4791 <!ELEMENT shared EMPTY >
4793 <!ELEMENT depth (#PCDATA) >
4795 <!ELEMENT owner ANY >
4797 <!ELEMENT timeout (#PCDATA) >
4799 <!ELEMENT locktoken (href+) >
4801 <!ELEMENT href (#PCDATA) >
4803 <!ELEMENT link (src+, dst+) >
4804 <!ELEMENT dst (#PCDATA) >
4805 <!ELEMENT src (#PCDATA) >
4807 <!ELEMENT multistatus (response+, responsedescription?) >
4809 <!ELEMENT response (href, ((href*, status)|(propstat+)),
4810 responsedescription?) >
4811 <!ELEMENT status (#PCDATA) >
4812 <!ELEMENT propstat (prop, status, responsedescription?) >
4813 <!ELEMENT responsedescription (#PCDATA) >
4818 Goland, et al. Standards Track [Page 86]
4820 RFC 2518 WEBDAV February 1999
4823 <!ELEMENT prop ANY >
4825 <!ELEMENT propertybehavior (omit | keepalive) >
4826 <!ELEMENT omit EMPTY >
4828 <!ELEMENT keepalive (#PCDATA | href+) >
4830 <!ELEMENT propertyupdate (remove | set)+ >
4831 <!ELEMENT remove (prop) >
4832 <!ELEMENT set (prop) >
4834 <!ELEMENT propfind (allprop | propname | prop) >
4835 <!ELEMENT allprop EMPTY >
4836 <!ELEMENT propname EMPTY >
4838 <!ELEMENT collection EMPTY >
4840 <!--=========== Property Elements from Section 13 ===============-->
4841 <!ELEMENT creationdate (#PCDATA) >
4842 <!ELEMENT displayname (#PCDATA) >
4843 <!ELEMENT getcontentlanguage (#PCDATA) >
4844 <!ELEMENT getcontentlength (#PCDATA) >
4845 <!ELEMENT getcontenttype (#PCDATA) >
4846 <!ELEMENT getetag (#PCDATA) >
4847 <!ELEMENT getlastmodified (#PCDATA) >
4848 <!ELEMENT lockdiscovery (activelock)* >
4849 <!ELEMENT resourcetype ANY >
4850 <!ELEMENT source (link)* >
4851 <!ELEMENT supportedlock (lockentry)* >
4874 Goland, et al. Standards Track [Page 87]
4876 RFC 2518 WEBDAV February 1999
4879 23.2 Appendix 2 - ISO 8601 Date and Time Profile
4881 The creationdate property specifies the use of the ISO 8601 date
4882 format [ISO-8601]. This section defines a profile of the ISO 8601
4883 date format for use with this specification. This profile is quoted
4884 from an Internet-Draft by Chris Newman, and is mentioned here to
4885 properly attribute his work.
4887 date-time = full-date "T" full-time
4889 full-date = date-fullyear "-" date-month "-" date-mday
4890 full-time = partial-time time-offset
4892 date-fullyear = 4DIGIT
4893 date-month = 2DIGIT ; 01-12
4894 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
4896 time-hour = 2DIGIT ; 00-23
4897 time-minute = 2DIGIT ; 00-59
4898 time-second = 2DIGIT ; 00-59, 00-60 based on leap second rules
4899 time-secfrac = "." 1*DIGIT
4900 time-numoffset = ("+" / "-") time-hour ":" time-minute
4901 time-offset = "Z" / time-numoffset
4903 partial-time = time-hour ":" time-minute ":" time-second
4906 Numeric offsets are calculated as local time minus UTC (Coordinated
4907 Universal Time). So the equivalent time in UTC can be determined by
4908 subtracting the offset from the local time. For example, 18:50:00-
4909 04:00 is the same time as 22:58:00Z.
4911 If the time in UTC is known, but the offset to local time is unknown,
4912 this can be represented with an offset of "-00:00". This differs
4913 from an offset of "Z" which implies that UTC is the preferred
4914 reference point for the specified time.
4930 Goland, et al. Standards Track [Page 88]
4932 RFC 2518 WEBDAV February 1999
4935 23.3 Appendix 3 - Notes on Processing XML Elements
4937 23.3.1 Notes on Empty XML Elements
4939 XML supports two mechanisms for indicating that an XML element does
4940 not have any content. The first is to declare an XML element of the
4941 form <A></A>. The second is to declare an XML element of the form
4942 <A/>. The two XML elements are semantically identical.
4944 It is a violation of the XML specification to use the <A></A> form if
4945 the associated DTD declares the element to be EMPTY (e.g., <!ELEMENT
4946 A EMPTY>). If such a statement is included, then the empty element
4947 format, <A/> must be used. If the element is not declared to be
4948 EMPTY, then either form <A></A> or <A/> may be used for empty
4951 23.3.2 Notes on Illegal XML Processing
4953 XML is a flexible data format that makes it easy to submit data that
4954 appears legal but in fact is not. The philosophy of "Be flexible in
4955 what you accept and strict in what you send" still applies, but it
4956 must not be applied inappropriately. XML is extremely flexible in
4957 dealing with issues of white space, element ordering, inserting new
4958 elements, etc. This flexibility does not require extension,
4959 especially not in the area of the meaning of elements.
4961 There is no kindness in accepting illegal combinations of XML
4962 elements. At best it will cause an unwanted result and at worst it
4963 can cause real damage.
4965 23.3.2.1 Example - XML Syntax Error
4967 The following request body for a PROPFIND method is illegal.
4969 <?xml version="1.0" encoding="utf-8" ?>
4970 <D:propfind xmlns:D="DAV:">
4975 The definition of the propfind element only allows for the allprop or
4976 the propname element, not both. Thus the above is an error and must
4977 be responded to with a 400 (Bad Request).
4986 Goland, et al. Standards Track [Page 89]
4988 RFC 2518 WEBDAV February 1999
4991 Imagine, however, that a server wanted to be "kind" and decided to
4992 pick the allprop element as the true element and respond to it. A
4993 client running over a bandwidth limited line who intended to execute
4994 a propname would be in for a big surprise if the server treated the
4995 command as an allprop.
4997 Additionally, if a server were lenient and decided to reply to this
4998 request, the results would vary randomly from server to server, with
4999 some servers executing the allprop directive, and others executing
5000 the propname directive. This reduces interoperability rather than
5003 23.3.2.2 Example - Unknown XML Element
5005 The previous example was illegal because it contained two elements
5006 that were explicitly banned from appearing together in the propfind
5007 element. However, XML is an extensible language, so one can imagine
5008 new elements being defined for use with propfind. Below is the
5009 request body of a PROPFIND and, like the previous example, must be
5010 rejected with a 400 (Bad Request) by a server that does not
5011 understand the expired-props element.
5013 <?xml version="1.0" encoding="utf-8" ?>
5014 <D:propfind xmlns:D="DAV:"
5015 xmlns:E="http://www.foo.bar/standards/props/">
5019 To understand why a 400 (Bad Request) is returned let us look at the
5020 request body as the server unfamiliar with expired-props sees it.
5022 <?xml version="1.0" encoding="utf-8" ?>
5023 <D:propfind xmlns:D="DAV:"
5024 xmlns:E="http://www.foo.bar/standards/props/">
5027 As the server does not understand the expired-props element,
5028 according to the WebDAV-specific XML processing rules specified in
5029 section 14, it must ignore it. Thus the server sees an empty
5030 propfind, which by the definition of the propfind element is illegal.
5032 Please note that had the extension been additive it would not
5033 necessarily have resulted in a 400 (Bad Request). For example,
5034 imagine the following request body for a PROPFIND:
5036 <?xml version="1.0" encoding="utf-8" ?>
5037 <D:propfind xmlns:D="DAV:"
5038 xmlns:E="http://www.foo.bar/standards/props/">
5042 Goland, et al. Standards Track [Page 90]
5044 RFC 2518 WEBDAV February 1999
5048 <E:leave-out>*boss*</E:leave-out>
5051 The previous example contains the fictitious element leave-out. Its
5052 purpose is to prevent the return of any property whose name matches
5053 the submitted pattern. If the previous example were submitted to a
5054 server unfamiliar with leave-out, the only result would be that the
5055 leave-out element would be ignored and a propname would be executed.
5098 Goland, et al. Standards Track [Page 91]
5100 RFC 2518 WEBDAV February 1999
5103 23.4 Appendix 4 -- XML Namespaces for WebDAV
5107 All DAV compliant systems MUST support the XML namespace extensions
5108 as specified in [REC-XML-NAMES].
5110 23.4.2 Meaning of Qualified Names
5112 [Note to the reader: This section does not appear in [REC-XML-NAMES],
5113 but is necessary to avoid ambiguity for WebDAV XML processors.]
5115 WebDAV compliant XML processors MUST interpret a qualified name as a
5116 URI constructed by appending the LocalPart to the namespace name URI.
5120 <del:glider xmlns:del="http://www.del.jensen.org/">
5124 <del:glideraccidents/>
5127 In this example, the qualified element name "del:glider" is
5128 interpreted as the URL "http://www.del.jensen.org/glider".
5130 <bar:glider xmlns:del="http://www.del.jensen.org/">
5134 <bar:glideraccidents/>
5137 Even though this example is syntactically different from the previous
5138 example, it is semantically identical. Each instance of the
5139 namespace name "bar" is replaced with "http://www.del.jensen.org/"
5140 and then appended to the local name for each element tag. The
5141 resulting tag names in this example are exactly the same as for the
5144 <foo:r xmlns:foo="http://www.del.jensen.org/glide">
5154 Goland, et al. Standards Track [Page 92]
5156 RFC 2518 WEBDAV February 1999
5159 This example is semantically identical to the two previous ones.
5160 Each instance of the namespace name "foo" is replaced with
5161 "http://www.del.jensen.org/glide" which is then appended to the local
5162 name for each element tag, the resulting tag names are identical to
5163 those in the previous examples.
5210 Goland, et al. Standards Track [Page 93]
5212 RFC 2518 WEBDAV February 1999
5215 24. Full Copyright Statement
5217 Copyright (C) The Internet Society (1999). All Rights Reserved.
5219 This document and translations of it may be copied and furnished to
5220 others, and derivative works that comment on or otherwise explain it
5221 or assist in its implementation may be prepared, copied, published
5222 and distributed, in whole or in part, without restriction of any
5223 kind, provided that the above copyright notice and this paragraph are
5224 included on all such copies and derivative works. However, this
5225 document itself may not be modified in any way, such as by removing
5226 the copyright notice or references to the Internet Society or other
5227 Internet organizations, except as needed for the purpose of
5228 developing Internet standards in which case the procedures for
5229 copyrights defined in the Internet Standards process must be
5230 followed, or as required to translate it into languages other than
5233 The limited permissions granted above are perpetual and will not be
5234 revoked by the Internet Society or its successors or assigns.
5236 This document and the information contained herein is provided on an
5237 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
5238 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
5239 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
5240 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
5241 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5266 Goland, et al. Standards Track [Page 94]