idnits 2.17.1 draft-ietf-webdav-protocol-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 42) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 20 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 1998) is 9545 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Lagoze' is mentioned on line 374, but not defined == Missing Reference: 'Extension' is mentioned on line 704, but not defined == Missing Reference: '1' is mentioned on line 4033, but not defined == Missing Reference: '2' is mentioned on line 4035, but not defined == Missing Reference: '3' is mentioned on line 4052, but not defined == Missing Reference: '4' is mentioned on line 4065, but not defined == Missing Reference: '5' is mentioned on line 4066, but not defined == Missing Reference: '6' is mentioned on line 4067, but not defined == Missing Reference: '7' is mentioned on line 4087, but not defined == Missing Reference: '8' is mentioned on line 4088, but not defined == Missing Reference: '9' is mentioned on line 4097, but not defined == Missing Reference: '10' is mentioned on line 4098, but not defined == Missing Reference: '11' is mentioned on line 4099, but not defined == Unused Reference: 'Hollander' is defined on line 3688, but no explicit reference was found in the text == Unused Reference: 'Layman' is defined on line 3688, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1807 (ref. '1995') ** Obsolete normative reference: RFC 2279 (ref. '1998') (Obsoleted by RFC 3629) -- Duplicate reference: RFC2119, mentioned in '1997', was also mentioned in 'Bradner'. -- Possible downref: Non-RFC (?) normative reference: ref. 'Bray' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hollander' -- Possible downref: Non-RFC (?) normative reference: ref. 'Layman' -- Possible downref: Non-RFC (?) normative reference: ref. 'Paoli' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sperberg-McQueen' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-639' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8601' -- Duplicate reference: RFC1807, mentioned in 'Lasher', was also mentioned in '1995'. ** Downref: Normative reference to an Informational RFC: RFC 1807 (ref. 'Lasher') -- Duplicate reference: RFC1807, mentioned in 'Cohen', was also mentioned in 'Lasher'. ** Downref: Normative reference to an Informational RFC: RFC 1807 (ref. 'Cohen') -- Possible downref: Non-RFC (?) normative reference: ref. 'Leach' -- Possible downref: Non-RFC (?) normative reference: ref. 'Salz' -- Possible downref: Non-RFC (?) normative reference: ref. 'MARC' -- Possible downref: Non-RFC (?) normative reference: ref. '1994' -- Duplicate reference: RFC2279, mentioned in 'Yergeau', was also mentioned in '1998'. ** Obsolete normative reference: RFC 2279 (ref. 'Yergeau') (Obsoleted by RFC 3629) Summary: 12 errors (**), 0 flaws (~~), 19 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WEBDAV Working Group Y.Y. Goland, Microsoft 2 INTERNET DRAFT E.J. Whitehead, Jr., UC Irvine 3 A. Faizi, Netscape 4 S.R. Carter, Novell 5 D. Jensen, Novell 6 Expires August, 1998 March 6, 1998 8 Extensions for Distributed Authoring on the World Wide Web -- WEBDAV 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or made obsolete by other 19 documents at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. Please send comments to 29 the Distributed Authoring and Versioning (WEBDAV) working group at 30 , which may be joined by sending a message 31 with subject "subscribe" to . 33 Discussions of the WEBDAV working group are archived at 34 . 36 Abstract 38 This document specifies a set of methods, headers, and content-types 39 ancillary to HTTP/1.1 for the management of resource properties, 40 creation and management of resource collections, namespace 41 manipulation, and resource locking (collision avoidance). 43 Contents 45 STATUS OF THIS MEMO..................................................1 46 ABSTRACT.............................................................1 47 CONTENTS.............................................................2 48 1 INTRODUCTION.......................................................7 49 2 NOTATIONAL CONVENTIONS.............................................8 50 3 DATA MODEL FOR RESOURCE PROPERTIES.................................8 51 3.1 The Resource Property Model.....................................8 52 3.2 Existing Metadata Proposals.....................................9 53 3.3 Properties and HTTP Headers....................................10 54 3.4 Property Values................................................10 55 3.5 Property Names.................................................10 56 3.6 Media Independent Links........................................11 57 4 COLLECTIONS OF WEB RESOURCES......................................11 58 4.1 Collection Resources...........................................11 59 4.2 Creation and Retrieval of Collection Resources.................12 60 4.3 HTTP URL Namespace Model.......................................12 61 4.4 Source Resources and Output Resources..........................12 62 5 LOCKING...........................................................13 63 5.1 Exclusive Vs. Shared Locks.....................................14 64 5.2 Required Support...............................................15 65 5.3 Lock Tokens....................................................15 66 5.4 opaquelocktoken Lock Token URI Scheme..........................15 67 5.5 Lock Capability Discovery......................................16 68 5.6 Active Lock Discovery..........................................16 69 5.7 Usage Considerations...........................................16 70 6 WRITE LOCK........................................................17 71 6.1 Methods Restricted by Write Locks..............................17 72 6.2 Write Locks and Properties.....................................18 73 6.3 Write Locks and Null Resources.................................18 74 6.4 Write Locks and Collections....................................18 75 6.5 Write Locks and the If Request Header..........................19 76 6.5.1Write Lock Example............................................19 77 6.6 Write Locks and COPY/MOVE......................................19 78 6.7 Refreshing Write Locks.........................................20 79 7 HTTP METHODS FOR DISTRIBUTED AUTHORING............................20 80 7.1 PROPFIND.......................................................21 81 7.1.1 Example: Retrieving Named Properties.........................22 82 7.1.2 Example: Using allprop to Retrieve All Properties............23 83 7.1.3 Example: Using propname to Retrieve all Property Names.......26 84 7.2 PROPPATCH......................................................27 85 7.2.1 Status Codes for use with Multi-Status.......................28 86 7.2.2 Example......................................................28 87 7.3 MKCOL Method...................................................29 88 7.3.1 Request......................................................29 89 7.3.2 Response Codes...............................................30 90 7.3.3 Example......................................................30 91 7.4 GET, HEAD for Collections......................................31 92 7.5 POST for Collections...........................................31 93 7.6 DELETE.........................................................31 94 7.6.1 DELETE for Non-Collection Resources..........................31 95 7.6.2 DELETE for Collections.......................................31 96 7.7 PUT............................................................32 97 7.7.1 PUT for Non-Collection Resources.............................32 98 7.7.2 PUT for Collections..........................................33 99 7.8 COPY Method....................................................33 100 7.8.1 COPY for HTTP/1.1 resources..................................33 101 7.8.2 COPY for Properties..........................................34 102 7.8.3 COPY for Collections.........................................34 103 7.8.4 COPY and the Overwrite Header................................35 104 7.8.5 Status Codes.................................................35 105 7.8.6 Overwrite Example............................................35 106 7.8.7 No Overwrite Example.........................................36 107 7.8.8 Collection Example...........................................36 108 7.9 MOVE Method....................................................37 109 7.9.1 MOVE for Properties..........................................37 110 7.9.2 MOVE for Collections.........................................38 111 7.9.3 MOVE and the Overwrite Header................................38 112 7.9.4 Status Codes.................................................39 113 7.9.5 Non-Collection Example.......................................39 114 7.9.6 Collection Example...........................................39 115 7.10 LOCK Method....................................................40 116 7.10.1 Operation...................................................40 117 7.10.2 The Effect of Locks on Properties and Collections...........41 118 7.10.3 Locking Replicated Resources................................41 119 7.10.4 Depth and Locking...........................................41 120 7.10.5 Interaction with other Methods..............................42 121 7.10.6 Lock Compatibility Table....................................42 122 7.10.7 Status Codes................................................42 123 7.10.8 Example - Simple Lock Request...............................43 124 7.10.9 Example - Refreshing a Write Lock...........................44 125 7.10.10 Example - Multi-Resource Lock Request......................45 126 7.11 UNLOCK Method..................................................46 127 7.11.1 Example.....................................................46 128 8 HTTP HEADERS FOR DISTRIBUTED AUTHORING............................47 129 8.1 DAV Header.....................................................47 130 8.2 Depth Header...................................................47 131 8.3 Destination Header.............................................48 132 8.4 If Header......................................................48 133 8.4.1 No-tag-list Production.......................................49 134 8.4.2 Tagged-list Production.......................................49 135 8.4.3 not Production...............................................50 136 8.4.4 Matching Function............................................50 137 8.4.5 If Header and Non-DAV Compliant Proxies......................50 138 8.5 Lock-Token Request Header......................................51 139 8.6 Overwrite Header...............................................51 140 8.7 Status-URI Response Header.....................................51 141 8.8 Timeout Request Header.........................................52 142 9 STATUS CODE EXTENSIONS TO HTTP/1.1................................53 143 9.1 102 Processing.................................................53 144 9.2 207 Multi-Status...............................................53 145 9.3 422 Unprocessable Entity.......................................53 146 9.4 423 Locked.....................................................53 147 9.5 424 Method Failure.............................................53 148 9.6 425 Insufficient Space on Resource.............................53 149 10 MULTI-STATUS RESPONSE............................................53 150 11 XML ELEMENT DEFINITIONS..........................................54 151 11.1 activelock XML Element.........................................54 152 11.1.1 depth XML Element...........................................54 153 11.1.2 locktoken XML Element.......................................54 154 11.1.3 timeout XML Element.........................................54 155 11.2 collection XML Element.........................................55 156 11.3 href XML Element...............................................55 157 11.4 link XML Element...............................................55 158 11.4.1 dst XML Element.............................................55 159 11.4.2 src XML Element.............................................55 160 11.5 lockentry XML Element..........................................56 161 11.6 lockinfo XML Element...........................................56 162 11.7 lockscope XML Element..........................................56 163 11.7.1 exclusive XML Element.......................................56 164 11.7.2 shared XML Element..........................................56 165 11.8 locktype XML Element...........................................56 166 11.8.1 write XML Element...........................................57 167 11.9 multistatus XML Element........................................57 168 11.9.1 response XML Element........................................57 169 11.9.2 responsedescription XML Element.............................58 170 11.10 owner XML Element.............................................58 171 11.11 prop XML element..............................................58 172 11.12 propertybehavior XML element..................................58 173 11.12.1 keepalive XML element......................................59 174 11.12.2 omit XML element...........................................59 175 11.13 propertyupdate XML element....................................59 176 11.13.1 remove XML element.........................................60 177 11.13.2 set XML element............................................60 178 11.14 propfind XML Element..........................................60 179 11.14.1 allprop XML Element........................................60 180 11.14.2 propname XML Element.......................................61 181 12 DAV PROPERTIES...................................................61 182 12.1 creationdate Property..........................................61 183 12.2 displayname Property...........................................61 184 12.3 getcontentlanguage Property....................................61 185 12.4 getcontentlength Property......................................62 186 12.5 getcontenttype Property........................................62 187 12.6 getetag Property...............................................62 188 12.7 getlastmodified Property.......................................63 189 12.8 lockdiscovery Property.........................................63 190 12.8.1 Example.....................................................63 191 12.9 resourcetype Property..........................................64 192 12.10 source Property...............................................64 193 12.10.1 Example....................................................65 194 12.11 supportedlock Property........................................66 195 12.11.1 Example....................................................66 196 13 DAV XML PROCESSING INSTRUCTIONS..................................67 197 14 DAV COMPLIANCE CLASSES...........................................67 198 14.1 Class 1........................................................67 199 14.2 Class 2........................................................68 200 15 INTERNATIONALIZATION CONSIDERATIONS..............................68 201 16 SECURITY CONSIDERATIONS..........................................69 202 16.1 Authentication of Clients......................................69 203 16.2 Denial of Service..............................................70 204 16.3 Security through Obscurity.....................................70 205 16.4 Privacy Issues Connected to Locks..............................70 206 16.5 Privacy Issues Connected to Properties.........................70 207 16.6 Reduction of Security due to Source Link.......................71 208 17 IANA CONSIDERATIONS..............................................71 209 18 TERMINOLOGY......................................................72 210 19 COPYRIGHT........................................................72 211 20 INTELLECTUAL PROPERTY............................................73 212 21 ACKNOWLEDGEMENTS.................................................73 213 22 REFERENCES.......................................................75 214 23 AUTHORS' ADDRESSES...............................................77 215 24 APPENDICES.......................................................78 216 24.1 Appendix 1 - WebDAV Document Type Definition...................78 217 24.2 Appendix 2 - ISO 8601 Date and Time Profile....................79 218 24.3 Appendix 3 - Notes on Processing XML Elements..................80 219 24.3.1 XML Syntax Error Example....................................80 220 24.3.2 Unknown XML Element Example.................................81 221 24.4 Appendix 4 -- XML Namespaces for WebDAV........................82 222 24.4.1 Introduction................................................82 223 24.4.2 Namespace Declaration PI....................................83 224 24.4.3 Prolog with Namespace Declarations..........................83 225 24.4.4 Well-Formedness Constraint - Unique Namespace Names.........83 226 24.4.5 Qualified Names.............................................83 227 24.4.6 Well-Formedness Constraint - Namespace Name Declared........83 228 24.4.7 Using Qualified Names.......................................84 229 24.4.8 Element Names...............................................84 230 24.4.9 Scope and Meaning of Qualified Names........................84 232 1 Introduction 234 This document describes an extension to the HTTP/1.1 protocol that 235 allows clients to perform remote web content authoring operations. 236 This extension provides a coherent set of methods, headers, request 237 entity body formats, and response entity body formats that provide 238 operations for: 240 Properties: The ability to create, remove, and query information 241 about Web pages, such as their authors, creation dates, etc. Also, 242 the ability to link pages of any media type to related pages. 244 Collections: The ability to create sets of related documents and to 245 retrieve a hierarchical membership listing (like a directory listing 246 in a file system). 248 Locking: The ability to keep more than one person from working on a 249 document at the same time. This prevents the "lost update problem," 250 in which modifications are lost as first one author then another 251 writes changes without merging the other author's changes. 253 Namespace Operations: The ability to instruct the server to copy and 254 move Web resources. 256 Requirements and rationale for these operations are described in a 257 companion document, "Requirements for a Distributed Authoring and 258 Versioning Protocol for the World Wide Web" [Slein et al., 1998]. 260 The sections below provide a detailed introduction to resource 261 properties (section 3), collections of resources (section 4), and 262 locking operations (section 5). These sections introduce the 263 abstractions manipulated by the WebDAV-specific HTTP methods 264 described in section 7, "HTTP Methods for Distributed Authoring". 266 In HTTP/1.1, method parameter information was exclusively encoded in 267 HTTP headers. Unlike HTTP/1.1, WebDAV, encodes method parameter 268 information either in an Extensible Markup Language (XML) [Bray, 269 Paoli, Sperberg-McQueen, 1998] request entity body, or in an HTTP 270 header. The use of XML to encode method parameters was motivated by 271 the ability to add extra XML elements to existing structures, 272 providing extensibility, and by XML's ability to encode information 273 in ISO 10646 character sets, providing internationalization support. 274 As a rule of thumb, parameters are encoded in XML entity bodies when 275 they have unbounded length, or when they may be shown to a human 276 user and hence require encoding in an ISO 10646 character set. 277 Otherwise, parameters are encoded within HTTP headers. Section 8 278 describes the new HTTP headers used with WebDAV methods. 280 In addition to encoding method parameters, XML is used in WebDAV to 281 encode the responses from methods, providing the extensibility and 282 internationalization advantages of XML for method output, as well as 283 input. 285 XML elements used in this specification are defined in section 11. 287 The XML namespace extension (Appendix 4) is also used in this 288 specification in order to allow for new XML elements to be added 289 without fear of colliding with other element names. 291 While the status codes provided by HTTP/1.1 are sufficient to 292 describe most error conditions encountered by WebDAV methods, there 293 are some errors that do not fall neatly into the existing 294 categories. New status codes developed for the WebDAV methods are 295 defined in section 9. Since some WebDAV methods may operate over 296 many resources, the Multi-Status response has been introduced to 297 return status information for multiple resources. The Multi-Status 298 response is described in section 10. 300 WebDAV employs the property mechanism to store information about the 301 current state of the resource. For example, when a lock is taken 302 out on a resource, a lock information property describes the current 303 state of the lock. Section 12 defines the properties used within the 304 WebDAV specification. 306 Finishing off the specification are sections on what it means to be 307 compliant with this specification (section 14), on 308 internationalization support (section 15), and on security (section 309 16). 311 2 Notational Conventions 313 Since this document describes a set of extensions to the HTTP/1.1 314 protocol, the augmented BNF used herein to describe protocol 315 elements is exactly the same as described in section 2.1 of 316 [Fielding et al., 1997]. Since this augmented BNF uses the basic 317 production rules provided in section 2.2 of [Fielding et al., 1997], 318 these rules apply to this document as well. 320 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 321 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 322 document are to be interpreted as described in RFC 2119 [Bradner, 323 1997]. 325 3 Data Model for Resource Properties 327 3.1 The Resource Property Model 329 Properties are pieces of data that describe the state of a resource. 330 Properties are data about data. 332 Properties are used in distributed authoring environments to provide 333 for efficient discovery and management of resources. For example, a 334 'subject' property might allow for the indexing of all resources by 335 their subject, and an 'author' property might allow for the 336 discovery of what authors have written which documents. 338 The DAV property model consists of name/value pairs. The name of a 339 property identifies the property's syntax and semantics, and 340 provides an address by which to refer to its syntax and semantics. 342 There are two categories of properties: "live" and "dead". A live 343 property has its syntax and semantics enforced by the server. Live 344 properties include cases where a) the value of a property is read- 345 only, maintained by the server, and b) the value of the property is 346 maintained by the client, but the server performs syntax checking on 347 submitted values. A dead property has its syntax and semantics 348 enforced by the client; the server merely records the value of the 349 property verbatim. 351 3.2 Existing Metadata Proposals 353 Properties have long played an essential role in the maintenance of 354 large document repositories, and many current proposals contain some 355 notion of a property, or discuss web metadata more generally. These 356 include PICS [Miller et al., 1996], PICS-NG, XML, Web Collections, 357 and several proposals on representing relationships within HTML. 358 Work on PICS-NG and Web Collections has been subsumed by the 359 Resource Definition Framework (RDF) metadata activity of the World 360 Wide Web Consortium. RDF consists of a network-based data model and 361 an XML representation of that model. 363 Some proposals come from a digital library perspective. These 364 include the Dublin Core [Weibel et al., 1995] metadata set and the 365 Warwick Framework [Lagoze, 1996], a container architecture for 366 different metadata schemas. The literature includes many examples 367 of metadata, including MARC [MARC, 1994], a bibliographic metadata 368 format, and RFC 1807 [Lasher, Cohen, 1995], a technical report 369 bibliographic format employed by the Dienst system. Additionally, 370 the proceedings from the first IEEE Metadata conference describe 371 many community-specific metadata sets. 373 Participants of the 1996 Metadata II Workshop in Warwick, UK 374 [Lagoze, 1996], noted that "new metadata sets will develop as the 375 networked infrastructure matures" and "different communities will 376 propose, design, and be responsible for different types of 377 metadata." These observations can be corroborated by noting that 378 many community-specific sets of metadata already exist, and there is 379 significant motivation for the development of new forms of metadata 381 as many communities increasingly make their data available in 382 digital form, requiring a metadata format to assist data location 383 and cataloging. 385 3.3 Properties and HTTP Headers 387 Properties already exist, in a limited sense, in HTTP message 388 headers. However, in distributed authoring environments a 389 relatively large number of properties are needed to describe the 390 state of a resource, and setting/returning them all through HTTP 391 headers is inefficient. Thus a mechanism is needed which allows a 392 principal to identify a set of properties in which the principal is 393 interested and to set or retrieve just those properties. 395 3.4 Property Values 397 The value of a property is, at minimum, well formed XML. 399 XML has been chosen because it is a flexible, self-describing, 400 structured data format that supports rich schema definitions, and 401 because of its support for multiple character sets. XML's self- 402 describing nature allows any property's value to be extended by 403 adding new elements. Older clients will not break when they 404 encounter extensions because they will still have the data specified 405 in the original schema and will ignore elements they do not 406 understand. XML's support for multiple character sets allows any 407 human-readable property to be encoded and read in a character set 408 familiar to the user. 410 3.5 Property Names 412 A property name is a universally unique identifier that is 413 associated with a schema that provides information about the syntax 414 and semantics of the property. 416 Because a property's name is universally unique, clients can depend 417 upon consistent behavior for a particular property across multiple 418 resources, so long as that property is "live" on the resources in 419 question. 421 The XML namespace mechanism, which is based on URIs, is used to name 422 properties because it prevents namespace collisions and provides for 423 varying degrees of administrative control. 425 The property namespace is flat; that is, no hierarchy of properties 426 is explicitly recognized. Thus, if a property A and a property A/B 427 exist on a resource, there is no recognition of any relationship 428 between the two properties. It is expected that a separate 429 specification will eventually be produced which will address issues 430 relating to hierarchical properties. 432 Finally, it is not possible to define the same property twice on a 433 single resource, as this would cause a collision in the resource's 434 property namespace. 436 3.6 Media Independent Links 438 Although HTML resources support links to other resources, the Web 439 needs more general support for links between resources of any media 440 type. WebDAV provides such links. A WebDAV link is a special type 441 of property value, formally defined in section 11.4, that allows 442 typed connections to be established between resources of any media 443 type. The property value consists of source and destination Uniform 444 Resource Locators (URLs); the property name identifies the link 445 type. 447 4 Collections of Web Resources 449 This section provides a description of a new type of Web resource, 450 the collection, and discusses its interactions with the HTTP URL 451 namespace. The purpose of a collection resource is to model 452 collection-like objects (e.g., file system directories) within a 453 server's namespace. 455 All DAV compliant resources MUST support the HTTP URL namespace 456 model specified herein. 458 4.1 Collection Resources 460 A collection is a resource whose state consists of an unordered list 461 of internal members and a set of properties. An internal member 462 resource MUST have a URI that is immediately relative to the base 463 URI of the collection. That is, the internal member's URI is equal 464 to the parent collection's URI plus an additional segment where 465 segment is defined in section 3.2.1 of RFC 2068 [Fielding et al., 466 1996]. 468 Any given internal member MUST only belong to the collection once, 469 i.e., it is illegal to have multiple instances of the same URI in a 470 collection. Properties defined on collections behave exactly as do 471 properties on non-collection resources. 473 WebDAV servers MUST treat HTTP URL namespaces as collections, 474 regardless of whether they were created with the MKCOL method 475 described in section 7.3. 477 There is a standing convention that when a collection is referred to 478 by its name without a trailing slash, the trailing slash is 479 automatically appended. Due to this, a resource may accept a URI 480 without a trailing "/" to point to a collection. In this case it 481 SHOULD return a location header in the response pointing to the URL 482 ending with the "/". For example, if a client invokes a method on 483 http://foo.bar/blah (no trailing slash), the resource 484 http://foo.bar/blah/ (trailing slash) may respond as if the 485 operation were invoked on it, and should return a location header 486 with http://foo.bar/blah/ in it. In general clients SHOULD use the 487 "/" form of collection names. 489 4.2 Creation and Retrieval of Collection Resources 491 This document specifies the MKCOL method to create new collection 492 resources, rather than using the existing HTTP/1.1 PUT or POST 493 method, for the following reasons: 495 In HTTP/1.1, the PUT method is defined to store the request body at 496 the location specified by the Request-URI. While a description 497 format for a collection can readily be constructed for use with PUT, 498 the implications of sending such a description to the server are 499 undesirable. For example, if a description of a collection that 500 omitted some existing resources were PUT to a server, this might be 501 interpreted as a command to remove those members. This would extend 502 PUT to perform DELETE functionality, which is undesirable since it 503 changes the semantics of PUT, and makes it difficult to control 504 DELETE functionality with an access control scheme based on methods. 506 While the POST method is sufficiently open-ended that a "create a 507 collection" POST command could be constructed, this is undesirable 508 because it would be difficult to separate access control for 509 collection creation from other uses of POST. 511 The exact definition of the behavior of GET and PUT on collections 512 is defined later in this document. 514 4.3 HTTP URL Namespace Model 516 The HTTP URL Namespace is a hierarchical namespace where the 517 hierarchy is delimited with the "/" character. DAV compliant 518 resources MUST maintain the consistency of the HTTP URL namespace. 519 For example, if the collection http://www.foo.bar.org/a/ exists, but 520 http://www.foo.bar.org/a/b/ does not exist, an attempt to create 521 http://www.foo.bar.org/a/b/c must fail. 523 4.4 Source Resources and Output Resources 525 For many resources, the entity returned by a GET method exactly 526 matches the persistent state of the resource, for example, a GIF 527 file stored on a disk. For this simple case, the URL at which a 528 resource is accessed is identical to the URL at which the source 529 (the persistent state) of the resource is accessed. This is also 530 the case for HTML source files that are not processed by the server 531 prior to transmission. 533 However, the server can sometimes process HTML resources before they 534 are transmitted as a return entity body. For example, a server- 535 side-include directive within an HTML file might instruct a server 536 to replace the directive with another value, such as the current 537 date. In this case, what is returned by GET (HTML plus date) 538 differs from the persistent state of the resource (HTML plus 539 directive). Typically there is no way to access the HTML resource 540 containing the unprocessed directive. 542 Sometimes the entity returned by GET is the output of a data- 543 producing process that is described by one or more source resources 544 (that may not even have a location in the URL namespace). A single 545 data-producing process may dynamically generate the state of a 546 potentially large number of output resources. An example of this is 547 a CGI script that describes a "finger" gateway process that maps 548 part of the namespace of a server into finger requests, such as 549 http://www.foo.bar.org/finger_gateway/user@host. 551 In the absence of distributed authoring capabilities, it is 552 acceptable to have no mapping of source resource(s) to the URI 553 namespace. In fact, preventing access to the source resource(s) has 554 desirable security benefits. However, if remote editing of the 555 source resource(s) is desired, the source resource(s) should be 556 given a location in the URI namespace. This source location should 557 not be one of the locations at which the generated output is 558 retrievable, since in general it is impossible for the server to 559 differentiate requests for source resources from requests for 560 process output resources. There is often a many-to-many 561 relationship between source resources and output resources. 563 On WebDAV compliant servers, for all output resources which have a 564 single source resource (and that source resource has a URI), the URI 565 of the source resource may be stored in a link on the output 566 resource with type DAV:source (see section 12.10 for a description 567 of the source link property). Storing the source URIs in links on 568 the output resources places the burden of discovering the source on 569 the authoring client. Note that the value of a source link is not 570 guaranteed to point to the correct source. Source links may break 571 or incorrect values may be entered. Also note that not all servers 572 will allow the client to set the source link value. For example a 573 server which generates source links on the fly for its CGI files 574 will most likely not allow a client to set the source link value. 576 5 Locking 578 The ability to lock a resource provides a mechanism for serializing 579 access to that resource. Using a lock, an authoring client can 580 provide a reasonable guarantee that another principal will not 581 modify a resource while it is being edited. In this way, a client 582 can prevent the "lost update" problem. 584 This specification allows locks to vary over two client-specified 585 parameters, the number of principals involved (exclusive vs. shared) 586 and the type of access to be granted. This document defines locking 587 for only one access type, write. However, the syntax is extensible, 588 and permits the eventual specification of locking for other access 589 types. 591 5.1 Exclusive Vs. Shared Locks 593 The most basic form of lock is an exclusive lock. This is a lock 594 where the access right in question is only granted to a single 595 principal. The need for this arbitration results from a desire to 596 avoid having to merge results. 598 However, there are times when the goal of a lock is not to exclude 599 others from exercising an access right but rather to provide a 600 mechanism for principals to indicate that they intend to exercise 601 their access rights. Shared locks are provided for this case. A 602 shared lock allows multiple principals to receive a lock. Hence any 603 principal with appropriate access can get the lock. 605 With shared locks there are two trust sets that affect a resource. 606 The first trust set is created by access permissions. Principals 607 who are trusted, for example, may have permission to write to the 608 resource. Among those who have access permission to write to the 609 resource, the set of principals who have taken out a shared lock 610 also must trust each other, creating a (typically) smaller trust set 611 within the access permission write set. 613 Starting with every possible principal on the Internet, in most 614 situations the vast majority of these principals will not have write 615 access to a given resource. Of the small number who do have write 616 access, some principals may decide to guarantee their edits are free 617 from overwrite conflicts by using exclusive write locks. Others may 618 decide they trust their collaborators will not overwrite their work 619 (the potential set of collaborators being the set of principals who 620 have write permission) and use a shared lock, which informs their 621 collaborators that a principal may be working on the resource. 623 The WebDAV extensions to HTTP do not need to provide all of the 624 communications paths necessary for principals to coordinate their 625 activities. When using shared locks, principals may use any out of 626 band communication channel to coordinate their work (e.g., face-to- 627 face interaction, written notes, post-it notes on the screen, 628 telephone conversation, Email, etc.) The intent of a shared lock is 629 to let collaborators know who else may be working on a resource. 631 Shared locks are included because experience from web distributed 632 authoring systems has indicated that exclusive locks are often too 633 rigid. An exclusive lock is used to enforce a particular editing 634 process: take out an exclusive lock, read the resource, perform 635 edits, write the resource, release the lock. This editing process 636 has the problem that locks are not always properly released, for 637 example when a program crashes, or when a lock owner leaves without 638 unlocking a resource. While both timeouts and administrative action 639 can be used to remove an offending lock, neither mechanism may be 640 available when needed; the timeout may be long or the administrator 641 may not be available. 643 5.2 Required Support 645 A WebDAV compliant server is not required to support locking in any 646 form. If the server does support locking it may choose to support 647 any combination of exclusive and shared locks for any access types. 649 The reason for this flexibility is that locking policy strikes to 650 the very heart of the resource management and versioning systems 651 employed by various storage repositories. These repositories 652 require control over what sort of locking will be made available. 653 For example, some repositories only support shared write locks while 654 others only provide support for exclusive write locks while yet 655 others use no locking at all. As each system is sufficiently 656 different to merit exclusion of certain locking features, this 657 specification leaves locking as the sole axis of negotiation within 658 WebDAV. 660 5.3 Lock Tokens 662 A lock token is a type of state token, represented as a URI, which 663 identifies a particular lock. A lock token is returned by every 664 successful LOCK operation in the Lock-Token response header, and can 665 also be discovered through lock discovery on a resource. 667 Lock token URIs MUST be unique across all resources for all time. 668 This uniqueness constraint allows lock tokens to be submitted across 669 resources and servers without fear of confusion. 671 This specification provides a lock token URI scheme called 672 opaquelocktoken that meets the uniqueness requirements. However 673 resources are free to return any URI scheme so long as it meets the 674 uniqueness requirements. 676 Having a lock token provides no special access rights. Anyone can 677 find out anyone else's lock token by performing lock discovery. 678 Locks MUST be enforced based upon whatever authentication mechanism 679 is used by the server, not based on the secrecy of the token values. 681 5.4 opaquelocktoken Lock Token URI Scheme 683 The opaquelocktoken URI scheme is designed to be unique across all 684 resources for all time. Due to this uniqueness quality, a client 685 may submit an opaque lock token in an If header on a resource other 686 than the one that returned it. 688 All resources MUST recognize the opaquelocktoken scheme and, at 689 minimum, recognize that the lock token does not refer to an 690 outstanding lock on the resource. 692 In order to guarantee uniqueness across all resources for all time 693 the opaquelocktoken requires the use of the Universally Unique 694 Identifier (UUID, also known as a Globally Unique Identifier, or 695 GUID) mechanism, as described in [Leach, Salz, 1998]. 697 Opaquelocktoken generators, however, have a choice of how they 698 create these tokens. They can either generate a new UUID for every 699 lock token they create or they can create a single UUID and then add 700 extension characters. If the second method is selected then the 701 program generating the extensions MUST guarantee that the same 702 extension will never be used twice with the associated UUID. 704 OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The 705 UUID production is the string form of a UUID, as defined in [Leach, 706 Salz, 1998]. Note that white space (LWS) is not allowed between 707 elements of this production. 709 Extension = path ; path is defined in section 3.2.1 of RFC 2068 710 [Fielding et al., 1996] 712 5.5 Lock Capability Discovery 714 Since server lock support is optional, a client trying to lock a 715 resource on a server can either try the lock and hope for the best, 716 or perform some form of discovery to determine what lock 717 capabilities the server supports. This is known as lock capability 718 discovery. Lock capability discovery differs from discovery of 719 supported access control types, since there may be access control 720 types without corresponding lock types. A client can determine what 721 lock types the server supports by retrieving the supportedlock 722 property. 724 Any DAV compliant resource that supports the LOCK method MUST 725 support the supportedlock property. 727 5.6 Active Lock Discovery 729 If another principal locks a resource that a principal wishes to 730 access, it is useful for the second principal to be able to find out 731 who the first principal is. For this purpose the lockdiscovery 732 property is provided. This property lists all outstanding locks, 733 describes their type, and where available, provides their lock 734 token. 736 Any DAV compliant resource that supports the LOCK method MUST 737 support the lockdiscovery property. 739 5.7 Usage Considerations 741 Although the locking mechanisms specified here provide some help in 742 preventing lost updates, they cannot guarantee that updates will 743 never be lost. Consider the following scenario: 745 Two clients A and B are interested in editing the resource 746 'index.html'. Client A is an HTTP client rather than a WebDAV 747 client, and so does not know how to perform locking. 749 Client A doesn't lock the document, but does a GET and begins 750 editing. 751 Client B does LOCK, performs a GET and begins editing. 752 Client B finishes editing, performs a PUT, then an UNLOCK. 753 Client A performs a PUT, overwriting and losing all of B's changes. 755 There are several reasons why the WebDAV protocol itself cannot 756 prevent this situation. First, it cannot force all clients to use 757 locking because it must be compatible with HTTP clients that do not 758 comprehend locking. Second, it cannot require servers to support 759 locking because of the variety of repository implementations, some 760 of which rely on reservations and merging rather than on locking. 761 Finally, being stateless, it cannot enforce a sequence of operations 762 like LOCK / GET / PUT / UNLOCK. 764 WebDAV servers that support locking can reduce the likelihood that 765 clients will accidentally overwrite each other's changes by 766 requiring clients to lock resources before modifying them. Such 767 servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from 768 modifying resources. 770 WebDAV clients can be good citizens by using a lock / retrieve / 771 write /unlock sequence of operations (at least by default) whenever 772 they interact with a WebDAV server that supports locking. 774 HTTP 1.1 clients can be good citizens, avoiding overwriting other 775 clients' changes, by using entity tags in If-Match headers with any 776 requests that would modify resources. 778 Information managers may attempt to prevent overwrites by 779 implementing client-side procedures requiring locking before 780 modifying WebDAV resources. 782 6 Write Lock 784 This section describes the semantics specific to the write lock 785 type. The write lock is a specific instance of a lock type, and is 786 the only lock type described in this specification. 788 6.1 Methods Restricted by Write Locks 790 A write lock MUST prevent a principal without the lock from 791 successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, 792 DELETE, or MKCOL on the locked resource. All other current methods, 793 GET in particular, function independent of the lock. 795 Note, however, that as new methods are created it will be necessary 796 to specify how they interact with a write lock. 798 6.2 Write Locks and Properties 800 While those without a write lock may not alter a property on a 801 resource it is still possible for the values of live properties to 802 change, even while locked, due to the requirements of their schemas. 803 Only dead properties and live properties defined to respect locks 804 are guaranteed not to change while write locked. 806 6.3 Write Locks and Null Resources 808 It is possible to assert a write lock on a null resource in order to 809 lock the name. A write locked null resource acts in all ways as a 810 null resource, except that it MUST respond to a PROPFIND request and 811 MUST support the lockdiscovery and supportedlock properties. 813 Until a method such as PUT or MKCOL is executed, the resource MUST 814 stay in the null state with the exception of the behavior described 815 above. 817 If the resource is unlocked without a PUT, MKCOL, or similar method 818 having been executed then the resource MUST return to its original 819 NULL state. 821 A return to a full NULL state is generally interpreted as meaning 822 that any attempt to execute a method on the resource will result in 823 a 404 Not Found. 825 6.4 Write Locks and Collections 827 A write lock on a collection prevents the addition or removal of 828 members of the collection by non-lock owners. As a consequence, 829 when a principal issues a request to create a new internal member of 830 a write locked collection using PUT or POST, or to remove an 831 existing internal member of a write locked collection using DELETE, 832 this request MUST fail if the principal does not have a write lock 833 on the collection. 835 However, if a write lock request is issued to a collection 836 containing internal member resources that are currently locked in a 837 manner which conflicts with the write lock, the request MUST fail 838 with a 423 Locked status code. 840 If a lock owner causes a resource to be added as an internal member 841 of a locked collection then the new resource MUST be automatically 842 added to the lock. This is the only mechanism that allows a 843 resource to be added to a write lock. Thus, for example, if the 844 collection /a/b/ is write locked and the resource /c is moved to 845 /a/b/c then /a/b/c will be added to the write lock. 847 6.5 Write Locks and the If Request Header 849 If a user agent is not required to have knowledge about a lock when 850 requesting an operation on a locked resource, the following scenario 851 might occur. Program A, run by User A, takes out a write lock on a 852 resource. Program B, also run by User A, has no knowledge of the 853 lock taken out by Program A, yet performs a PUT to the locked 854 resource. In this scenario, the PUT succeeds because locks are 855 associated with a principal, not a program, and thus program B, 856 because it is acting with principal A's credential, is allowed to 857 perform the PUT. However, had program B known about the lock, it 858 would not have overwritten the resource, preferring instead to 859 present a dialog box describing the conflict to the user. Due to 860 this scenario, a mechanism is needed to prevent different programs 861 from accidentally ignoring locks taken out by other programs with 862 the same authorization. 864 In order to prevent these collisions a lock token MUST be submitted 865 by an authorized principal in the If header for all locked resources 866 that a method may interact with or the method MUST fail. For 867 example, if a resource is to be moved and both the source and 868 destination are locked then two lock tokens must be submitted, one 869 for the source and the other for the destination. 871 6.5.1 Write Lock Example 873 >>Request 875 COPY /~fielding/index.html HTTP/1.1 876 Host: www.ics.uci.edu 877 Destination: http://www.ics.uci.edu/users/f/fielding/index.html 878 If: 879 () 881 >>Response 883 HTTP/1.1 204 No Content 885 In this example, even though both the source and destination are 886 locked, only one lock token must be submitted, for the lock on the 887 destination. This is because the source resource is not modified by 888 a COPY, and hence unaffected by the write lock. In this example, 889 user agent authentication has previously occurred via a mechanism 890 outside the scope of the HTTP protocol, in the underlying transport 891 layer. 893 6.6 Write Locks and COPY/MOVE 895 A COPY method invocation MUST NOT duplicate any write locks active 896 on the source. However, as previously noted, if the COPY copies the 897 resource into a collection that is depth locked then the resource 898 will be added to the lock. 900 A MOVE MUST NOT move the write lock with the resource although the 901 resource is subject to being added to an existing lock as specified 902 in section 6.4. For example, if the MOVE makes the resource a child 903 of a collection that is depth locked then the resource will be under 904 that collection's lock. Additionally, if a depth locked resource is 905 moved to a destination that is within the scope of the same depth 906 lock (e.g., within the namespace tree covered by the lock), the 907 moved resource will again be a member of the lock. In both these 908 examples, as specified in section 6.5, an If header must be 909 submitted containing a lock token for both the source and 910 destination. 912 6.7 Refreshing Write Locks 914 A client MUST NOT submit the same write lock request twice. Note 915 that a client is always aware it is resubmitting the same lock 916 request because it must include the lock token in the If header in 917 order to make the request for a resource that is already locked. 919 However, a client may submit a LOCK method with an If header but 920 without a body. This form of LOCK MUST only be used to "refresh" a 921 lock. Meaning, at minimum, that any timers associated with the lock 922 MUST be re-set. 924 A server may return a Timeout header with a lock refresh that is 925 different than the Timeout header returned when the lock was 926 originally requested. Additionally clients may submit Timeout 927 headers of arbitrary value with their lock refresh requests. 928 Servers, as always, may ignore Timeout headers submitted by the 929 client. 931 If an error is received in response to a refresh LOCK request the 932 client SHOULD assume that the lock was not refreshed. 934 7 HTTP Methods for Distributed Authoring 936 The following new HTTP methods use XML as a request and response 937 format. All DAV compliant clients and resources MUST use XML 938 parsers that are compliant with [Bray, Paoli, Sperberg-McQueen, 939 1998]. All XML used in either requests or responses MUST be, at 940 minimum, well formed. If a server receives ill-formed XML in a 941 request it MUST reject the entire request with a 400 Bad Request. 942 If a client receives ill-formed XML in a response then it MUST NOT 943 assume anything about the outcome of the executed method and SHOULD 944 treat the server as malfunctioning. 946 7.1 PROPFIND 948 The PROPFIND method retrieves properties defined on the Request-URI, 949 if the resource does not have any internal members, or on the 950 Request-URI and potentially its member resources, if the resource 951 does have internal members. All DAV compliant resources MUST 952 support the PROPFIND method and the propfind XML element (section 953 11.14) along with all XML elements defined for use with that 954 element. 956 A client may submit a Depth header with a value of "0", "1", or 957 "infinity" with a PROPFIND on a resource with internal members. DAV 958 compliant servers MUST support the "0", "1" and "infinity" 959 behaviors. By default, the PROPFIND method without a Depth header 960 MUST act as if a "Depth: infinity" header was included. 962 A client may submit a propfind XML element in the body of the 963 request method describing what information is being requested. It 964 is possible to request particular property values, all property 965 values, or a list of the names of the resource's properties. A 966 client may choose not to submit a request body. An empty PROPFIND 967 request body MUST be treated as a request for the names and values 968 of all properties. 970 All servers MUST support returning a response of content type 971 text/xml that contains a multistatus XML element that describes the 972 results of the attempts to retrieve the various properties. 974 If there is an error retrieving a property then a proper error 975 result MUST be included in the response. A request to retrieve the 976 value of a property which does not exist is an error and MUST be 977 noted, if the response uses a multistatus XML element, with a 978 response XML element which contains a 404 Not Found status value. 980 Consequently, the multistatus XML element for a resource with 981 members MUST include a response XML element for each member of the 982 resource, to whatever depth was requested. Each response XML element 983 MUST contain an href XML element that identifies the resource on 984 which the properties in the prop XML element are defined. Results 985 for a PROPFIND on a resource with internal members are returned as a 986 flat list whose order of entries is not significant. 988 In the case of allprop and propname, if a principal does not have 989 the right to know whether a particular property exists then the 990 property should be silently excluded from the response. 992 The results of this method SHOULD NOT be cached. 994 7.1.1 Example: Retrieving Named Properties 996 >>Request 998 PROPFIND /files/ HTTP/1.1 999 Host: www.foo.bar 1000 Depth: 0 1001 Content-type: text/xml 1002 Content-Length: xyz 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1016 >>Response 1018 HTTP/1.1 207 Multi-Status 1019 Content-Type: text/xml 1020 Content-Length: xxxxx 1022 1023 1024 1025 1026 1027 http://www.foo.bar/files/ 1028 1029 1030 1031 Box type A 1032 1033 1034 J.J. Johnson 1035 1036 1037 HTTP/1.1 200 OK 1038 1039 1040 1041 HTTP/1.1 403 Forbidden 1042 The user does not have access to 1043 the DingALing property. 1044 1045 1047 1048 There has been an access violation error. 1049 1050 1052 In this example, PROPFIND is executed on the collection 1053 http://www.foo.bar/files/. The specified depth is zero, hence the 1054 PROPFIND applies only to the collection itself, and not to any of 1055 its members. The propfind XML element specifies the name of four 1056 properties whose values are being requested. In this case only two 1057 properties were returned, since the principal issuing the request 1058 did not have sufficient access rights to see the third and fourth 1059 properties. 1061 7.1.2 Example: Using allprop to Retrieve All Properties 1063 >>Request 1065 PROPFIND /container/ HTTP/1.1 1066 Host: www.foo.bar 1067 Depth: 1 1068 Content-Type: text/xml 1069 Content-Length: xxxxx 1071 1072 1073 1074 1075 1077 >>Response 1079 HTTP/1.1 207 Multi-Status 1080 Content-Type: text/xml 1081 Content-Length: xxxxx 1083 1084 1085 1086 1087 1088 http://www.foo.bar/container/ 1089 1090 1091 1092 Box type A 1093 1094 1095 Hadrian 1096 1097 1098 1997-12-01T17:42:21-08:00 1100 1101 1102 Example collection 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 HTTP/1.1 200 OK 1115 1116 1117 1118 http://www.foo.bar/container/front.html 1119 1120 1121 1122 Box type B 1123 1124 1125 1997-12-01T18:27:21-08:00 1126 1127 1128 Example HTML resource 1129 1130 1131 4525 1132 1133 1134 text/html 1135 1136 1137 zzyzx 1138 1139 1140 Monday, 12-Jan-98 09:25:56 GMT 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 HTTP/1.1 200 OK 1153 1154 1155 1157 In this example, PROPFIND was invoked on the resource 1158 http://www.foo.bar/container/ with a Depth header of 1, meaning the 1159 request applies to the resource and its children, and a propfind XML 1160 element containing the allprop XML element, meaning the request 1161 should return the name and value of all properties defined on each 1162 resource. 1164 The resource http://www.foo.bar/container/ has six properties 1165 defined on it: 1167 http://www.foo.bar/boxschema/bigbox, 1168 http://www.foo.bar/boxschema/author, DAV:creationdate, 1169 DAV:displayname, DAV:resourcetype, and DAV:supportedlock. 1171 The last four properties are WebDAV-specific, defined in section 12. 1172 Since GET is not supported on this resource, the get* properties 1173 (e.g., getcontentlength) are not defined on this resource. The DAV- 1174 specific properties assert that "container" was created on December 1175 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT 1176 (creationdate), has a name of "Example collection" (displayname), a 1177 collection resource type (resourcetype), and supports exclusive 1178 write and shared write locks (supportedlock). 1180 The resource http://www.foo.bar/container/front.html has nine 1181 properties defined on it: 1183 http://www.foo.bar/boxschema/bigbox (another instance of the 1184 "bigbox" property type), DAV:creationdate, DAV:displayname, 1185 DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, 1186 DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock. 1188 The DAV-specific properties assert that "front.html" was created on 1189 December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT 1190 (creationdate), has a name of "Example HTML resource" (displayname), 1191 a content length of 4525 bytes (getcontentlength), a MIME type of 1192 "text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), 1193 was last modified on Monday, January 12, 1998, at 09:25:56 GMT 1194 (getlastmodified), has an undefined resource type, meaning that it 1195 is not a collection (resourcetype), and supports both exclusive 1196 write and shared write locks (supportedlock). 1198 7.1.3 Example: Using propname to Retrieve all Property Names 1200 >>Request 1202 PROPFIND /container/ HTTP/1.1 1203 Host: www.foo.bar 1204 Content-Type: text/xml 1205 Content-Length: xxxxx 1207 1208 1209 1210 1211 1213 >>Response 1215 HTTP/1.1 207 Multi-Status 1216 Content-Type: text/xml 1217 Content-Length: xxxx 1219 1220 1221 1222 1223 1224 http://www.foo.bar/container/ 1225 1226 1227 1228 1229 1231 1232 1233 1234 1235 HTTP/1.1 200 OK 1236 1237 1238 1239 http://www.foo.bar/container/front.html 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1252 1253 HTTP/1.1 200 OK 1254 1255 1256 1258 In this example, PROPFIND is invoked on the collection resource 1259 http://www.foo.bar/container/, with a propfind XML element 1260 containing the propname XML element, meaning the name of all 1261 properties should be returned. Since no depth header is present, it 1262 assumes its default value of "infinity", meaning the name of the 1263 properties on the collection and all its progeny should be returned. 1265 Consistent with the previous example, resource 1266 http://www.foo.bar/container/ has six properties defined on it, 1267 http://www.foo.bar/boxschema/bigbox, 1268 http://www.foo.bar/boxschema/author, DAV:creationdate, 1269 DAV:displayname, DAV:resourcetype, and DAV:supportedlock. 1271 The resource http://www.foo.bar/container/index.html, a member of 1272 the "container" collection, has nine properties defined on it, 1273 http://www.foo.bar/boxschema/bigbox, DAV:creationdate, 1274 DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, 1275 DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and 1276 DAV:supportedlock. 1278 7.2 PROPPATCH 1280 The PROPPATCH method processes instructions specified in the request 1281 body to set and/or remove properties defined on the resource 1282 identified by the Request-URI. 1284 All DAV compliant resources MUST support the PROPPATCH method and 1285 MUST process instructions that are specified using the 1286 propertyupdate, set, and remove XML elements of the DAV schema. 1287 Execution of the directives in this method is, of course, subject to 1288 access control constraints. DAV compliant resources SHOULD support 1289 the setting of arbitrary dead properties. 1291 The request message body of a PROPPATCH method MUST contain at least 1292 one propertyupdate XML element. Instruction processing MUST occur in 1293 the order instructions are received (i.e., from top to bottom). 1294 Instructions MUST either all be executed or none executed. Thus if 1295 any error occurs during processing all executed instructions MUST be 1296 undone and a proper error result returned. Instruction processing 1297 details can be found in the definition of the set and remove 1298 instructions in section 11.13. 1300 7.2.1 Status Codes for use with Multi-Status 1302 The following are examples of response codes one would expect to be 1303 used in a Multi-Status response for this method. Note, however, 1304 that unless explicitly prohibited any 2/3/4/5xx series response code 1306 may be used in a Multi-Status response. 1308 200 OK - The command succeeded. As there can be a mixture of sets 1309 and removes in a body, a 201 Created seems inappropriate. 1311 403 Forbidden - The client, for reasons the server chooses not to 1312 specify, cannot alter one of the properties. 1314 409 Conflict - The client has provided a value whose semantics are 1315 not appropriate for the property. This includes trying to set read- 1316 only properties. 1318 423 Locked - The specified resource is locked and the client either 1319 is not a lock owner or the lock type requires a lock token to be 1320 submitted and the client did not submit it. 1322 425 Insufficient Space on Resource - The server did not have 1323 sufficient space to record the property. 1325 7.2.2 Example 1327 >>Request 1329 PROPPATCH /bar.html HTTP/1.1 1330 Host: www.foo.com 1331 Content-Type: text/xml 1332 Content-Length: xxxx 1334 1335 1336 1337 1338 1339 1340 1341 Jim Whitehead 1342 Roy Fielding 1343 1344 1345 1346 1347 1348 1349 1350 >>Response 1352 HTTP/1.1 207 Multi-Status 1353 Content-Type: text/xml 1354 Content-Length: xxxxx 1356 1357 1358 1359 1360 1361 http://www.foo.com/bar.html 1362 1363 1364 HTTP/1.1 424 Method Failure 1365 1366 1367 1368 HTTP/1.1 409 Conflict 1369 1370 Copyright Owner can not be deleted or 1371 altered. 1372 1373 1375 In this example, the client requests the server to set the value of 1376 the http://www.w3.com/standards/z39.50/Authors property, and to 1377 remove the property http://www.w3.com/standards/z39.50/Copyright- 1378 Owner. Since the Copyright-Owner property could not be removed, no 1379 property modifications occur. The Method Failure status code for 1380 the Authors property indicates this action would have succeeded if 1381 it were not for the conflict with removing the Copyright-Owner 1382 property. 1384 7.3 MKCOL Method 1386 The MKCOL method is used to create a new collection. All DAV 1387 compliant resources MUST support the MKCOL method. 1389 7.3.1 Request 1391 MKCOL creates a new collection resource at the location specified by 1392 the Request-URI. If the resource identified by the Request-URI is 1393 non-null then the MKCOL MUST fail. During MKCOL processing, a 1394 server MUST make the Request-URI a member of its parent collection, 1395 unless the Request-URI is "/". If no such ancestor exists, the 1396 method MUST fail. When the MKCOL operation creates a new collection 1397 resource, all ancestors MUST already exist, or the method MUST fail 1398 with a 409 Conflict status code. For example, if a request to 1399 create collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/ 1400 exists, the request must fail. 1402 When MKCOL is invoked without a request body, the newly created 1403 collection SHOULD have no members. 1405 A MKCOL request message may contain a message body. The behavior of 1406 a MKCOL request when the body is present is limited to creating 1407 collections, members of a collection, bodies of members and 1408 properties on the collections or members. If the server receives a 1409 MKCOL request entity type it does not support or understand it MUST 1410 respond with a 415 Unsupported Media Type status code. The exact 1411 behavior of MKCOL for various request media types is undefined in 1412 this document, and will be specified in separate documents. 1414 7.3.2 Response Codes 1416 Responses from a MKCOL request MUST NOT be cached as MKCOL has non- 1417 idempotent semantics. 1419 201 Created - The collection or structured resource was created in 1420 its entirety. 1422 403 Forbidden - This indicates at least one of two conditions: 1) 1423 the server does not allow the creation of collections at the given 1424 location in its namespace, or 2) the parent collection of the 1425 Request-URI exists but cannot accept members. 1427 405 Method Not Allowed - MKCOL can only be executed on a 1428 deleted/non-existent resource. 1430 409 Conflict - A collection cannot be made at the Request-URI until 1431 one or more intermediate collections have been created. 1433 415 Unsupported Media Type- The server does not support the request 1434 type of the body. 1436 425 Insufficient Space on Resource - The resource does not have 1437 sufficient space to record the state of the resource after the 1438 execution of this method. 1440 7.3.3 Example 1442 This example creates a collection called /webdisc/xfiles/ on the 1443 server www.server.org. 1445 >>Request 1447 MKCOL /webdisc/xfiles/ HTTP/1.1 1448 Host: www.server.org 1450 >>Response 1452 HTTP/1.1 201 Created 1454 7.4 GET, HEAD for Collections 1456 The semantics of GET are unchanged when applied to a collection, 1457 since GET is defined as, "retrieve whatever information (in the form 1458 of an entity) is identified by the Request-URI" [Fielding et al., 1459 1997]. GET when applied to a collection may return the contents of 1460 an "index.html" resource, a human-readable view of the contents of 1461 the collection, or something else altogether. Hence it is possible 1462 that the result of a GET on a collection will bear no correlation to 1463 the membership of the collection. 1465 Similarly, since the definition of HEAD is a GET without a response 1466 message body, the semantics of HEAD are unmodified when applied to 1467 collection resources. 1469 7.5 POST for Collections 1471 Since by definition the actual function performed by POST is 1472 determined by the server and often depends on the particular 1473 resource, the behavior of POST when applied to collections cannot be 1474 meaningfully modified because it is largely undefined. Thus the 1475 semantics of POST are unmodified when applied to a collection. 1477 7.6 DELETE 1479 7.6.1 DELETE for Non-Collection Resources 1481 If the DELETE method is issued to a non-collection resource which is 1482 an internal member of a collection, then during DELETE processing a 1483 server MUST remove the Request-URI from its parent collection. 1485 7.6.2 DELETE for Collections 1487 The DELETE method on a collection MUST act as if a "Depth: infinity" 1488 header was used on it. A client MUST NOT submit a Depth header with 1489 a DELETE on a collection with any value but infinity. 1491 DELETE instructs that the collection specified in the request-URI 1492 and all its internal member resources are to be deleted. 1494 If any member cannot be deleted then all of the member's ancestors 1495 MUST NOT be deleted, so as to maintain the namespace. 1497 Any headers included with DELETE MUST be applied in processing every 1498 resource to be deleted. 1500 When the DELETE method has completed processing it MUST return a 1501 consistent namespace. 1503 If an error occurs with a resource other than the resource 1504 identified in the request URI then the response MUST be a 207 Multi- 1505 Status. 424 Method Failure errors SHOULD NOT be in the 207 Multi- 1506 Status. They can be safely left out because the client will know 1507 that the ancestors of a resource could not be deleted when the 1509 client receives an error for the ancestor's progeny. Additionally 1510 204 No Content errors SHOULD NOT be returned in the 207 Multi- 1511 Status. The reason for this prohibition is that 204 No Content is 1512 the default success code. 1514 7.6.2.1 Example 1516 >>Request 1518 DELETE /container/ HTTP/1.1 1519 Host: www.foo.bar 1521 >>Response 1523 HTTP/1.1 207 Multi-Status 1524 Content-Type: text/xml 1525 Content-Length: xxxxx 1527 1528 1529 1530 1531 http://www.foo.bar/container/resource3 1532 HTTP/1.1 423 Locked 1533 1534 1536 In this example the attempt to delete 1537 http://www.foo.bar/container/resource3 failed because it is locked, 1538 and no lock token was submitted with the request. Consequently, the 1539 attempt to delete http://www.foo.bar/container/ also failed. Thus 1540 the client knows that the attempt to delete 1541 http://ww.foo.bar/container/ must have also failed since the parent 1542 can not be deleted unless its child has also been deleted. Even 1543 though a Depth header has not been included, a depth of infinity is 1544 assumed because the method is on a collection. 1546 7.7 PUT 1548 7.7.1 PUT for Non-Collection Resources 1550 A PUT performed on an existing resource replaces the GET response 1551 entity of the resource. Properties defined on the resource may be 1552 recomputed during PUT processing but are not otherwise affected. 1553 For example, if a server recognizes the content type of the request 1554 body, it may be able to automatically extract information that could 1555 be profitably exposed as properties. 1557 A PUT that would result in the creation of a resource without an 1558 appropriately scoped parent collection MUST fail with a 409 1559 Conflict. 1561 7.7.2 PUT for Collections 1563 As defined in the HTTP/1.1 specification [Fielding et al., 1997], 1564 the "PUT method requests that the enclosed entity be stored under 1565 the supplied Request-URI." Since submission of an entity 1566 representing a collection would implicitly encode creation and 1567 deletion of resources, this specification intentionally does not 1568 define a transmission format for creating a collection using PUT. 1569 Instead, the MKCOL method is defined to create collections. 1571 When the PUT operation creates a new non-collection resource all 1572 ancestors MUST already exist. If all ancestors do not exist, the 1573 method MUST fail with a 409 Conflict status code. For example, if 1574 resource /a/b/c/d.html is to be created and /a/b/c/ does not exist, 1575 then the request must fail. 1577 7.8 COPY Method 1579 The COPY method creates a duplicate of the source resource, given by 1580 the Request-URI, in the destination resource, given by the 1581 Destination header. The Destination header MUST be present. The 1582 exact behavior of the COPY method depends on the type of the source 1583 resource. 1585 All WebDAV compliant resources MUST support the COPY method. 1586 However, support for the COPY method does not guarantee the ability 1587 to copy a resource. For example, separate programs may control 1588 resources on the same server. As a result, it may not be possible 1589 to copy a resource to a location that appears to be on the same 1590 server. 1592 7.8.1 COPY for HTTP/1.1 resources 1594 When the source resource is not a collection the result of the COPY 1595 method is the creation of a new resource at the destination whose 1596 state and behavior match that of the source resource as closely as 1597 possible. However, the exact state and behavior of the destination 1598 resource depend on what information the source resource is able to 1599 provide and what information the destination resource is able to 1600 accept. 1602 Subsequent alterations to the destination resource will not modify 1603 the source resource. Subsequent alterations to the source resource 1604 will not modify the destination resource. 1606 All properties on the source resource MUST be duplicated on the 1607 destination resource, subject to modifying headers and XML elements, 1608 following the definition for copying properties. 1610 7.8.2 COPY for Properties 1612 The following section defines how properties on a resource are 1613 handled during a COPY operation. 1615 Live properties SHOULD be duplicated as identically behaving live 1616 properties at the destination resource. If a property cannot be 1617 copied live, then its value MUST be duplicated, octet-for-octet, in 1619 an identically named, dead property on the destination resource 1620 subject to the effects of the propertybehavior XML element. 1622 The propertybehavior XML element can specify that properties are 1623 copied on best effort, that all live properties must be successfully 1624 copied or the method must fail, or that a specified list of live 1625 properties must be successfully copied or the method must fail. The 1626 propertybehavior XML element is defined in section 11.12. 1628 7.8.3 COPY for Collections 1630 The COPY method on a collection without a Depth header MUST act as 1631 if a Depth header with value "infinity" was included. A client may 1632 submit a Depth header on a COPY on a collection with a value of "0" 1633 or "infinity". DAV compliant servers MUST support the "0" and 1634 "infinity" Depth header behaviors. 1636 A COPY of depth infinity instructs that the collection specified in 1637 the Request-URI is to be copied to the location specified in the 1638 Destination header, and all its internal member resources are to be 1639 copied to a location relative to it, recursively through all levels 1640 of the collection hierarchy. 1642 A COPY of depth "0" only instructs that the collection and its 1643 properties but not its internal members, are to be copied. 1645 Any headers included with a COPY MUST be applied in processing every 1646 resource to be copied with the exception of the Destination header. 1648 The Destination header only specifies the destination for the 1649 Request-URI. When applied to members of the collection specified in 1650 the request-URI the value of Destination is to be modified to 1651 reflect the current location in the hierarchy. So, if the request- 1652 URI is /a/ and the destination is /b/ then when /a/c/d is processed 1653 it must use a destination of /b/c/d. 1655 When the COPY method has completed processing it MUST have created a 1656 consistent namespace at the destination. However, if an error 1657 occurs while copying an internal member collection, the server MUST 1658 NOT copy any members of this collection. After detecting an error, 1659 the COPY operation SHOULD try to finish as much of the original copy 1660 operation as possible. So, for example, if an infinite depth copy 1661 operation is performed on collection /a/, which contains collections 1662 /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt 1663 should still be made to copy /a/c/. Similarly, after encountering an 1664 error copying a non-collection resource as part of an infinite depth 1665 copy, the server SHOULD try to finish as much of the original copy 1666 operation as possible. 1668 If an error in executing the COPY method occurs with a resource 1669 other than the resource identified in the request URI then the 1670 response MUST be a 207 Multi-Status. 1672 424 Method Failure errors SHOULD NOT be returned in the 207 Multi- 1673 Status from a COPY method. These responses can be safely omitted 1674 because the client will know that the progeny of a resource could 1675 not be copied when the client receives an error for the parent. 1676 Additionally 201 Created/204 No Content response codes SHOULD NOT be 1677 returned as values in 207 Multi-Status responses from COPY methods. 1678 They, too, can be safely omitted because they are the default 1679 success codes. 1681 7.8.4 COPY and the Overwrite Header 1683 If a resource exists at the destination and the Overwrite header is 1684 "T" then prior to performing the copy the server MUST perform a 1685 DELETE with Depth Infinity on the destination resource. If the 1686 Overwrite header is set to "F" then the operation will fail. 1688 7.8.5 Status Codes 1690 201 Created - The source resource was successfully copied. The copy 1691 operation resulted in the creation of a new resource. 1693 204 No Content - The source resource was successfully copied to a 1694 pre-existing destination resource. 1696 412 Precondition Failed - The server was unable to maintain the 1697 liveness of the properties listed in the propertybehavior XML 1698 element or the Overwrite header is "F" and the state of the 1699 destination resource is non-null. 1701 423 Locked - The destination resource was locked. 1703 425 Insufficient Space on Resource - The destination resource does 1704 not have sufficient space to record the state of the resource after 1705 the execution of this method. 1707 502 Bad Gateway - This may occur when the destination is on another 1708 server and the destination server refuses to accept the resource. 1710 7.8.6 Overwrite Example 1712 This example shows resource 1713 http://www.ics.uci.edu/~fielding/index.html being copied to the 1714 location http://www.ics.uci.edu/users/f/fielding/index.html. The 1715 204 No Content status code indicates the existing resource at the 1716 destination was overwritten. 1718 >>Request 1720 COPY /~fielding/index.html HTTP/1.1 1721 Host: www.ics.uci.edu 1722 Destination: http://www.ics.uci.edu/users/f/fielding/index.html 1724 >>Response 1726 HTTP/1.1 204 No Content 1728 7.8.7 No Overwrite Example 1730 The following example shows the same copy operation being performed, 1731 but with the Overwrite header set to "F." A response of 412 1732 Precondition Failed is returned because the destination resource has 1733 a non-null state. 1735 >>Request 1737 COPY /~fielding/index.html HTTP/1.1 1738 Host: www.ics.uci.edu 1739 Destination: http://www.ics.uci.edu/users/f/fielding/index.html 1740 Overwrite: F 1742 >>Response 1744 HTTP/1.1 412 Precondition Failed 1746 7.8.8 Collection Example 1748 >>Request 1750 COPY /container/ HTTP/1.1 1751 Host: www.foo.bar 1752 Destination: http://www.foo.bar/othercontainer/ 1753 Depth: infinity 1754 Content-Type: text/xml 1755 Content-Length: xxxxx 1757 1758 1759 1760 * 1761 1762 >>Response 1764 HTTP/1.1 207 Multi-Status 1765 Content-Type: text/xml 1766 Content-Length: xxxxx 1768 1769 1770 1771 1772 http://www.foo.bar/othercontainer/R2/ 1773 HTTP/1.1 412 Precondition Failed 1774 1775 1777 The Depth header is unnecessary as the default behavior of COPY on a 1778 collection is to act as if a "Depth: infinity" header had been 1779 submitted. In this example most of the resources, along with the 1780 collection, were copied successfully. However the collection R2 1781 failed, most likely due to a problem with maintaining the liveness 1782 of properties (this is specified by the propertybehavior XML 1783 element). Because there was an error copying R2, none of R2's 1784 members were copied. However no errors were listed for those 1785 members due to the error minimization rules given in section 7.8.3. 1787 7.9 MOVE Method 1789 The MOVE operation on a non-collection resource is the logical 1790 equivalent of a copy (COPY) followed by a delete of the source, 1791 where the actions are performed atomically. Consequently, the 1792 Destination header MUST be present on all MOVE methods and MUST 1793 follow all COPY requirements for the COPY part of the MOVE method. 1794 All DAV compliant resources MUST support the MOVE method. However, 1795 support for the MOVE method does not guarantee the ability to move a 1796 resource to a particular destination. 1798 For example, separate programs may actually control different sets 1799 of resources on the same server. Therefore, it may not be possible 1800 to move a resource within a namespace that appears to belong to the 1801 same server. 1803 If a resource exists at the destination, the destination resource 1804 will be DELETEd as a side-effect of the MOVE operation, subject to 1805 the restrictions of the Overwrite header. 1807 7.9.1 MOVE for Properties 1809 The behavior of properties on a MOVE, including the effects of the 1810 propertybehavior XML element, MUST be the same as specified in 1811 section 7.8.2. 1813 7.9.2 MOVE for Collections 1815 A MOVE of depth infinity instructs that the collection specified in 1816 the Request-URI be moved to the location specified in the 1817 Destination header, and all its internal member resources are to be 1818 moved to locations relative to it, recursively through all levels of 1819 the collection hierarchy. 1821 The MOVE method on a collection MUST act as if a Depth "infinity" 1822 header was used on it. A client MUST NOT submit a Depth header on a 1823 MOVE on a collection with any value but "infinity". 1825 Any headers included with MOVE MUST be applied in processing every 1826 resource to be moved with the exception of the Destination header. 1828 The behavior of the Destination header is the same as given for COPY 1829 on collections. 1831 When the MOVE method has completed processing it MUST have created a 1832 consistent namespace on both the source and destination. However, if 1833 an error occurs while moving an internal member collection, the 1834 server MUST NOT move any members of the failed collection.. In this 1835 case, after detecting the error, the move operation SHOULD try to 1836 finish as much of the original move as possible. So, for example, 1837 if an infinite depth move is performed on collection /a/, which 1838 contains collections /a/b/ and /a/c/, and an error occurs moving 1839 /a/b/, an attempt should still be made to try moving /a/c/. 1840 Similarly, after encountering an error moving a non-collection 1841 resource as part of an infinite depth move, the server SHOULD try to 1842 finish as much of the original move operation as possible. 1844 If an error occurs with a resource other than the resource 1845 identified in the request URI then the response MUST be a 207 Multi- 1846 Status. 1848 424 Method Failure errors SHOULD NOT be returned as values in the 1849 207 Multi-Status from a MOVE method. These errors can be safely 1850 omitted because the client will know that the progeny of a resource 1851 could not be moved when the client receives an error for the parent. 1852 Additionally 201 Created/204 No Content responses SHOULD NOT be 1853 returned as values in 207 Multi-Status responses from MOVES. These 1854 responses can be safely omitted because they are the default success 1855 codes. 1857 7.9.3 MOVE and the Overwrite Header 1859 If a resource exists at the destination and the Overwrite header is 1860 "T" then prior to performing the move the server MUST perform a 1861 DELETE with Depth infinity on the destination resource. If the 1862 Overwrite header is set to "F" then the operation will fail. 1864 7.9.4 Status Codes 1866 201 Created - The source resource was successfully moved, and a new 1867 resource was created at the destination. 1869 204 No Content - The source resource was successfully moved to a 1870 pre-existing destination resource. 1872 412 Precondition Failed - The server was unable to maintain the 1873 liveness of the properties listed in the propertybehavior XML 1874 element or the Overwrite header is "F" and the state of the 1875 destination resource is non-null. 1877 423 Locked - The source or the destination resource was locked. 1879 502 Bad Gateway - This may occur when the destination is on another 1880 server and the destination server refuses to accept the resource. 1882 7.9.5 Non-Collection Example 1884 This example shows resource 1885 http://www.ics.uci.edu/~fielding/index.html being moved to the 1886 location http://www.ics.uci.edu/users/f/fielding/index.html. The 1887 contents of the destination resource would have been overwritten if 1888 the destination resource had been non-null. In this case, since 1889 there was nothing at the destination resource, the response code is 1890 201 Created. 1892 >>Request 1894 MOVE /~fielding/index.html HTTP/1.1 1895 Host: www.ics.uci.edu 1896 Destination: http://www.ics.uci.edu/users/f/fielding/index.html 1898 >>Response 1900 HTTP/1.1 201 Created 1901 Location: http://www.ics.uci.edu/users/f/fielding/index.html 1903 7.9.6 Collection Example 1905 >>Request 1907 MOVE /container/ HTTP/1.1 1908 Host: www.foo.bar 1909 Destination: http://www.foo.bar/othercontainer/ 1910 Overwrite: F 1911 If: () 1912 () 1913 Content-Type: text/xml 1914 Content-Length: xyz 1916 1917 1918 1919 * 1920 1922 >>Response 1924 HTTP/1.1 207 Multi-Status 1925 Content-Type: text/xml 1926 Content-Length: zzz 1928 1929 1930 1931 1932 http://www.foo.bar/othercontainer/C2/ 1933 HTTP/1.1 423 Locked 1934 1935 1937 In this example the client has submitted a number of lock tokens 1938 with the request. A lock token will need to be submitted for every 1939 resource, both source and destination, anywhere in the scope of the 1940 method, that is locked. In this case the proper lock token was not 1941 submitted for the destination http://www.foo.bar/othercontainer/C2/. 1942 This means that the resource /container/C2/ could not be moved. 1943 Because there was an error copying /container/C2/, none of 1944 /container/C2's members were copied. However no errors were listed 1945 for those members due to the error minimization rules given in 1946 section 7.8.3. User agent authentication has previously occurred 1947 via a mechanism outside the scope of the HTTP protocol, in an 1948 underlying transport layer. 1950 7.10 LOCK Method 1952 The following sections describe the LOCK method, which is used to 1953 take out a lock of any access type. These sections on the LOCK 1954 method describe only those semantics that are specific to the LOCK 1955 method and are independent of the access type of the lock being 1956 requested. 1958 Any resource which supports the LOCK method MUST, at minimum, 1959 support the XML request and response formats defined herein. 1961 7.10.1 Operation 1963 A LOCK method invocation creates the lock specified by the lockinfo 1964 XML element on the Request-URI. Lock method requests SHOULD have a 1965 XML request body which contains an owner XML element for this lock 1966 request, unless this is a refresh request. The LOCK request may have 1967 a Timeout header. 1969 Clients MUST assume that locks may arbitrarily disappear at any 1970 time, regardless of the value given in the Timeout header. The 1971 Timeout header only indicates the behavior of the server if 1972 "extraordinary" circumstances do not occur. For example, an 1973 administrator may remove a lock at any time or the system may crash 1974 in such a way that it loses the record of the lock's existence. The 1975 response MUST contain the value of the lockdiscovery property in a 1976 prop XML element. 1978 7.10.2 The Effect of Locks on Properties and Collections 1980 The scope of a lock is the entire state of the resource, including 1981 its body and associated properties. As a result, a lock on a 1982 resource MUST also lock the resource's properties. 1984 For collections, a lock also affects the ability to add or remove 1985 members. The nature of the effect depends upon the type of access 1986 control involved. 1988 7.10.3 Locking Replicated Resources 1990 Some servers automatically replicate resources across multiple URLs. 1991 In such a circumstance the server MUST only accept a lock on one of 1992 the URLs if the server can guarantee that the lock will be honored 1993 across all the URLs. 1995 7.10.4 Depth and Locking 1997 The Depth header may be used with the LOCK method. Values other 1998 than 0 or infinity MUST NOT be used with the Depth header on a LOCK 1999 method. All resources that support the LOCK method MUST support the 2000 Depth header. 2002 A Depth header of value 0 means to just lock the resource specified 2003 by the request-URI. 2005 If the Depth header is set to infinity then the resource specified 2006 in the request-URI along with all its internal members, all the way 2007 down the hierarchy, are to be locked. A successful result MUST 2008 return a single lock token which represents all the resources that 2009 have been locked. If an UNLOCK is successfully executed on this 2010 token, all associated resources are unlocked. If the lock cannot be 2011 granted to all resources, a 409 Conflict status code MUST be 2012 returned with a response entity body containing a multistatus XML 2013 element describing which resource(s) prevented the lock from being 2014 granted. Hence, partial success is not an option. Either the 2015 entire hierarchy is locked or no resources are locked. 2017 If no depth header is submitted on a LOCK request then the request 2018 MUST act as if a Depth of infinity had been submitted. 2020 7.10.5 Interaction with other Methods 2022 The interaction of a LOCK with various methods is dependent upon the 2023 lock type. However, independent of lock type, a successful DELETE 2024 of a resource MUST cause all of its locks to be removed. 2026 7.10.6 Lock Compatibility Table 2028 The table below describes the behavior that occurs when a lock 2029 request is made on a resource. 2031 Current lock state/ Shared Lock Exclusive 2032 Lock request Lock 2034 None True True 2036 Shared Lock True False 2038 Exclusive Lock False False* 2040 Legend: True = lock may be granted. False = lock MUST NOT be 2041 granted. *=if the principal requesting the lock is the owner of the 2042 lock, the lock must be refreshed. 2044 The current lock state of a resource is given in the leftmost 2045 column, and lock requests are listed in the first row. The 2046 intersection of a row and column gives the result of a lock request. 2047 For example, if a shared lock is held on a resource, and an 2048 exclusive lock is requested, the table entry is "false", indicating 2049 the lock must not be granted. 2051 If an exclusive or shared lock is re-requested by the principal who 2052 owns the lock, the lock MUST be refreshed. 2054 7.10.7 Status Codes 2056 200 Success - The lock request succeeded and the value of the 2057 lockdiscovery property is included in the body. 2059 412 Precondition Failed - The included lock token was not 2060 enforceable on this resource or the server could not satisfy the 2061 request in the lockinfo XML element. 2063 423 Locked - The resource is locked, so the method has been 2064 rejected. 2066 7.10.8 Example - Simple Lock Request 2068 >>Request 2070 LOCK /workspace/webdav/proposal.doc HTTP/1.1 2071 Host: webdav.sb.aol.com 2072 Timeout: Infinite, Second-4100000000 2073 Content-Type: text/xml 2074 Content-Length: xyz 2075 Authorization: Digest username="ejw", 2076 realm="ejw@webdav.sb.aol.com", nonce="...", 2077 uri="/workspace/webdav/proposal.doc", 2078 response="...", opaque="..." 2080 2081 2082 2084 2085 2086 2087 http://www.ics.uci.edu/~ejw/contact.html 2088 2089 2091 >>Response 2093 HTTP/1.1 200 OK 2094 Content-Type: text/xml 2095 Content-Length: xxxxx 2097 2098 2099 2100 2101 2102 2103 2104 Infinity 2105 2106 2107 http://www.ics.uci.edu/~ejw/contact.html 2108 2109 2110 Second-604800 2111 2112 2113 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 2114 2115 2116 2117 2118 2119 This example shows the successful creation of an exclusive write 2120 lock on resource 2121 http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The 2122 resource http://www.ics.uci.edu/~ejw/contact.html contains contact 2123 information for the owner of the lock. The server has an activity- 2124 based timeout policy in place on this resource, which causes the 2125 lock to automatically be removed after 1 week (604800 seconds). 2126 Note that the nonce, response, and opaque fields have not been 2127 calculated in the Authorization request header. 2129 7.10.9 Example - Refreshing a Write Lock 2131 >>Request 2133 LOCK /workspace/webdav/proposal.doc HTTP/1.1 2134 Host: webdav.sb.aol.com 2135 Timeout: Infinite, Second-4100000000 2136 If: () 2137 Authorization: Digest username="ejw", 2138 realm="ejw@webdav.sb.aol.com", nonce="...", 2139 uri="/workspace/webdav/proposal.doc", 2140 response="...", opaque="..." 2142 >>Response 2144 HTTP/1.1 200 OK 2145 Content-Type: text/xml 2146 Content-Length: xxxxx 2148 2149 2150 2151 2152 2153 2154 2155 Infinity 2156 2157 2158 http://www.ics.uci.edu/~ejw/contact.html 2159 2160 2161 Second-604800 2162 2163 2164 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 2165 2166 2167 2168 2169 2170 This request would refresh the lock, resetting any time outs. 2171 Notice that the client asked for an infinite time out but the server 2172 choose to ignore the request. In this example, the nonce, response, 2173 and opaque fields have not been calculated in the Authorization 2174 request header. 2176 7.10.10 Example - Multi-Resource Lock Request 2178 >>Request 2180 LOCK /webdav/ HTTP/1.1 2181 Host: webdav.sb.aol.com 2182 Timeout: Infinite, Second-4100000000 2183 Depth: infinity 2184 Authorization: Digest username="ejw", 2185 realm="ejw@webdav.sb.aol.com", nonce="...", 2186 uri="/workspace/webdav/proposal.doc", 2187 response="...", opaque="..." 2189 2190 2191 2192 2193 2194 2195 http://www.ics.uci.edu/~ejw/contact.html 2196 2197 2199 >>Response 2201 HTTP/1.1 207 Multi-Status 2202 Content-Type: text/xml 2203 Content-Length: xxxxx 2205 2206 2207 2208 2209 http://webdav.sb.aol.com/webdav/secret 2210 HTTP/1.1 403 Forbidden 2211 2212 2214 This example shows a request for an exclusive write lock on a 2215 collection and all its children. In this request, the client has 2216 specified that it desires an infinite length lock, if available, 2217 otherwise a timeout of 4.1 billion seconds, if available. The 2218 request entity body contains the contact information for the 2219 principal taking out the lock, in this case a web page URL. 2221 The error is a 403 Forbidden response on the resource 2222 http://webdav.sb.aol.com/webdav/secret. Because this resource could 2223 not be locked, none of the resources were locked. 2225 In this example, the nonce, response, and opaque fields have not 2226 been calculated in the Authorization request header. 2228 7.11 UNLOCK Method 2230 The UNLOCK method removes the lock identified by the lock token in 2231 the Lock-Token request header from the Request-URI, and all other 2232 resources included in the lock. If all resources which have been 2233 locked under the submitted lock token can not be unlocked then the 2234 UNLOCK request MUST fail. 2236 Any DAV compliant resource which supports the LOCK method MUST 2237 support the UNLOCK method. 2239 7.11.1 Example 2241 >>Request 2243 UNLOCK /workspace/webdav/info.doc HTTP/1.1 2244 Host: webdav.sb.aol.com 2245 Lock-Token: () 2246 Authorization: Digest username="ejw", 2247 realm="ejw@webdav.sb.aol.com", nonce="...", 2248 uri="/workspace/webdav/proposal.doc", 2249 response="...", opaque="..." 2251 >>Response 2253 HTTP/1.1 204 No Content 2255 In this example, the lock identified by the lock token 2256 "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is 2257 successfully removed from the resource 2258 http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock 2259 included more than just one resource, the lock is removed from all 2260 resources included in the lock. The 204 status code is used instead 2261 of 200 OK because there is no response entity body. 2263 In this example, the nonce, response, and opaque fields have not 2264 been calculated in the Authorization request header. 2266 8 HTTP Headers for Distributed Authoring 2268 8.1 DAV Header 2270 DAV = "DAV" ":" "1" [",2"] ["," 1#extend] 2272 This header indicates that the resource supports the DAV schema and 2273 protocol as specified. All DAV compliant resources MUST return the 2274 DAV header on all OPTIONS responses. 2276 The value is a list of all compliance classes that the resource 2277 supports. Note that above a comma has already been added to the 2. 2278 This is because a resource can not be level 2 compliant unless it is 2279 also level 1 compliant. Please refer to section 14 for more details. 2280 In general, however, support for one compliance class does not 2281 entail support for any other. 2283 8.2 Depth Header 2285 Depth = "Depth" ":" ("0" | "1" | "infinity") 2287 The Depth header is used with methods executed on resources which 2288 could potentially have internal members to indicate whether the 2289 method is to be applied only to the resource (Depth = 0), to the 2290 resource and its immediate children, (Depth = 1), or the resource 2291 and all its progeny (Depth = infinity). 2293 The Depth header is only supported if a method's definition 2294 explicitly provides for such support. 2296 The following rules are the default behavior for any method that 2297 supports the Depth header. A method may override these defaults by 2298 defining different behavior in its definition. 2300 Methods which support the Depth header may choose not to support all 2301 of the header's values and may define, on a case by case basis, the 2302 behavior of the method if a Depth header is not present. For 2303 example, the MOVE method only supports Depth = infinity and if a 2304 Depth header is not present will act as if a Depth = infinity header 2305 had been applied. 2307 Clients MUST NOT rely upon methods executing on members of their 2308 hierarchies in any particular order or on the execution being atomic 2309 unless the particular method explicitly provides such guarantees. 2311 Upon execution, a method with a Depth header will perform as much of 2312 its assigned task as possible and then return a response specifying 2313 what it was able to accomplish and what it failed to do. 2315 So, for example, an attempt to COPY a hierarchy may result in some 2316 of the members being copied and some not. 2318 Any headers on a method that has a defined interaction with the 2319 Depth header MUST be applied to all resources in the scope of the 2320 method except where alternative behavior is explicitly defined. For 2321 example, an If-Match header will have its value applied against 2322 every resource in the method's scope and will cause the method to 2323 fail if the header fails to match. 2325 If a resource, source or destination, within the scope of the method 2326 with a depth header is locked in such a way as to prevent the 2327 successful execution of the method, then the lock token for that 2328 resource MUST be submitted with the request in the If request 2329 header. 2331 The Depth header only specifies the behavior of the method with 2332 regards to internal children. If a resource does not have internal 2333 children then the Depth header MUST be ignored. 2335 Please note, however, that it is always an error to submit a value 2336 for the Depth header that is not allowed by the method's definition. 2337 Thus submitting a "Depth: 1" on a COPY, even if the resource does 2338 not have internal members, will result in a 400 Bad Request. The 2339 method should fail not because the resource doesn't have internal 2340 members, but because of the illegal value in the header. 2342 8.3 Destination Header 2344 Destination = "Destination" ":" URI 2346 The Destination header specifies a destination resource for methods 2347 such as COPY and MOVE, which take two URIs as parameters. 2349 8.4 If Header 2351 If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) 2352 No-tag-list = List 2353 Tagged-list = Resource 1*List 2354 Resource = Coded-url 2355 List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")" 2356 State-token = Coded-url 2357 Coded-url = "<" URI ">" 2359 The If header is intended to have similar functionality to the If- 2360 Match header defined in section 14.25 of [Fielding et al., 1997]. 2361 However the If header is intended for use with any URI which 2362 represents state information, referred to as a state token, about a 2363 resource as well as e-tags. A typical example of a state token is a 2364 lock token, and lock tokens are the only state tokens defined in 2365 this specification. 2367 All DAV compliant resources MUST honor the If header. 2369 The If header's purpose is to describe a series of state lists. If 2370 the state of the resource to which the header is applied does not 2371 match any of the specified state lists then the request MUST fail 2372 with a 412 Precondition Failed. If one of the described state lists 2373 matches the state of the resource then the request may succeed. 2375 8.4.1 No-tag-list Production 2377 The No-tag-list production describes a series of state tokens and e- 2378 tags. If multiple No-tag-list productions are used then only one 2379 needs to match the state of the resource for the method to be 2380 allowed to continue. 2382 If a method, due to the presence of a Depth or Destination header, 2383 is applied to multiple resources then the No-tag-list production 2384 MUST be applied to each resource the method is applied to. 2386 For example: 2388 If: ( ["I am an e-tag"]) (["I am 2389 another e-tag"]) 2391 The previous header would require that any resources within the 2392 scope of the method must either be locked with the specified lock 2393 token and in the state identified by the "I am an e-tag" e-tag or in 2394 the state identified by the second e-tag "I am another e-tag". To 2395 put the matter more plainly one can think of the previous If header 2396 as being in the form (or (and ["I am 2397 an e-tag"]) (and ["I am another e-tag"])). 2399 8.4.2 Tagged-list Production 2401 The tagged-list production scopes a list production. That is, it 2402 specifies that the lists following the resource specification only 2403 apply to the specified resource. The scope of the resource 2404 production begins with the list production immediately following the 2405 resource production and ends with the next resource production, if 2406 any. 2408 When the If header is applied to a particular resource, the Tagged- 2409 list productions MUST be searched to determine if any of the listed 2410 resources match the operand resource(s) for the current method. If 2411 none of the resource productions match the current resource then the 2412 header MUST be ignored. If one of the resource productions does 2413 match the name of the resource under consideration then the list 2414 productions following the resource production MUST be applied to the 2415 resource in the manner specified in the previous section. 2417 The same URI MUST NOT appear more than once in a resource production 2418 in an If header. 2420 For example: 2422 COPY /resource1 HTTP/1.1 2423 Host: www.foo.bar 2424 Destination: http://www.foo.bar/resource2 2425 If: ( 2426 [W/"A weak e-tag"]) (["strong e-tag"]) 2427 (["another strong e-tag"]) 2429 In this example http://www.foo.bar/resource1 is being copied to 2430 http://www.foo.bar/resource2. When the method is first applied to 2431 http://www.foo.bar/resource1, resource1 must be in the state 2432 specified by "( [W/"A weak e-tag"]) 2433 (["strong e-tag"])", that is, it either must be locked with a lock 2434 token of "locktoken:a-write-lock-token" and have a weak entity tag 2435 W/"A weak e-tag" or it must have a strong entity tag "strong e-tag". 2437 That is the only success condition since the resource 2438 http://www.bar.bar/random never has the method applied to it (the 2439 only other resource listed in the If header) and 2441 http://www.foo.bar/resource2 is not listed in the If header. 2443 8.4.3 not Production 2445 Every state token or e-tag is either current, and hence describes 2446 the state of a resource, or is not current, and does not describe 2447 the state of a resource. The boolean operation of matching a state 2448 token or e-tag to the current state of a resource thus resolves to a 2449 true or false value. The not production is used to reverse that 2450 value. The scope of the not production is the state-token or 2452 entity-tag immediately following it. 2454 If: (Not ) 2456 When submitted with a request, this If header requires that all 2457 operand resources must not be locked with locktoken:write1 and must 2458 be locked with locktoken:write2. 2460 8.4.4 Matching Function 2462 When performing If header processing, the definition of a matching 2463 state token or entity tag is as follows. 2465 Matching entity tag: Where the entity tag matches an entity tag 2466 associated with that resource. 2468 Matching state token: Where there is an exact match between the 2469 state token in the If header and any state token on the resource. 2471 8.4.5 If Header and Non-DAV Compliant Proxies 2473 Non-DAV compliant proxies will not honor the If header, since they 2474 will not understand the If header, and HTTP requires non-understood 2475 headers to be ignored. When communicating with HTTP/1.1 proxies, 2476 the "Cache-Control: no-cache" request header MUST be used so as to 2477 prevent the proxy from improperly trying to service the request from 2478 its cache. When dealing with HTTP/1.0 proxies the "Pragma: no- 2479 cache" request header MUST be used for the same reason. 2481 8.5 Lock-Token Request Header 2483 Lock-Token = "Lock-Token" ":" Coded-URL 2485 The Lock-Token request header is used with the UNLOCK method to 2486 identify the lock to be removed. The lock token in the Lock-Token 2487 request header MUST identify a lock that contains the resource 2488 identified by Request-URI as a member. 2490 8.6 Overwrite Header 2492 Overwrite = "Overwrite" ":" ("T" | "F") 2494 The Overwrite header specifies whether the server should overwrite 2495 the state of a non-null destination resource during a COPY or MOVE. 2496 A value of "F" states that the server must not perform the COPY or 2497 MOVE operation if the state of the destination resource is non-null. 2498 If the overwrite header is not included in a COPY or MOVE request 2499 then the resource MUST treat the request as if it has an overwrite 2500 header of value "T". While the Overwrite header appears to duplicate 2501 the functionality of the If-Match: * header of HTTP/1.1, If-Match 2502 applies only to the Request-URI, and not to the Destination of a 2503 COPY or MOVE. 2505 If a COPY or MOVE is not performed due to the value of the Overwrite 2506 header, the method MUST fail with a 409 Conflict status code. 2508 All DAV compliant resources MUST support the Overwrite header. 2510 8.7 Status-URI Response Header 2512 The Status-URI response header may be used with the 102 Processing 2513 status code to inform the client as to the status of a method. 2515 Status-URI = "Status-URI" ":" *(Status-Code "<" URI ">") ; Status- 2516 Code is defined in 6.1.1 of [Fielding et al., 1997] 2518 The URIs listed in the header are source resources which have been 2519 affected by the outstanding method. The status code indicates the 2520 resolution of the method on the identified resource. So, for 2521 example, if a MOVE method on a collection is outstanding and a 102 2522 "Processing" response with a Status-URI response header is returned, 2523 the included URIs will indicate resources that have had move 2524 attempted on them and what the result was. 2526 8.8 Timeout Request Header 2528 TimeOut = "Timeout" ":" 1#TimeType 2529 TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other) 2530 DAVTimeOutVal = 1*digit 2531 Other = Extend field-value ; See section 4.2 of [Fielding et al., 2532 1997] 2534 Clients may include Timeout headers in their LOCK requests. 2535 However, the server is not required to honor or even consider these 2536 requests. Clients MUST NOT submit a Timeout request header with any 2537 method other than a LOCK method. 2539 A Timeout request header MUST contain at least one TimeType and may 2540 contain multiple TimeType entries. The purpose of listing multiple 2541 TimeType entries is to indicate multiple different values and value 2542 types that are acceptable to the client. The client lists the 2543 TimeType entries in order of preference. 2545 Timeout response valuse MUST use a Second value, Infinite, or a 2546 TimeType the client has indicated familiarity with. The server may 2547 assume a client is familiar with any TimeType submitted in a Timeout 2548 header. 2550 The "Second" TimeType specifies the number of seconds that will 2551 elapse between granting of the lock at the server, and the automatic 2552 removal of the lock. The timeout value for timetype "Second" MUST 2553 NOT be greater than 2^32-1. 2555 The timeout counter SHOULD be restarted any time an owner of the 2556 lock sends a method to any member of the lock, including unsupported 2557 methods, or methods which are unsuccessful. However the lock MUST 2558 be refreshed if a refresh LOCK method is successfully received. 2560 If the timeout expires then the lock may be lost. Specifically, if 2561 the server wishes to harvest the lock upon time-out, the server 2562 SHOULD act as if an UNLOCK method was executed by the server on the 2563 resource using the lock token of the timed-out lock, performed with 2564 its override authority. Thus logs should be updated with the 2565 disposition of the lock, notifications should be sent, etc., just as 2566 they would be for an UNLOCK request. 2568 Servers are advised to pay close attention to the values submitted 2569 by clients, as they will be indicative of the type of activity the 2570 client intends to perform. For example, an applet running in a 2571 browser may need to lock a resource, but because of the instability 2572 of the environment within which the applet is running, the applet 2573 may be turned off without warning. As a result, the applet is 2574 likely to ask for a relatively small timeout value so that if the 2575 applet dies, the lock can be quickly harvested. However, a document 2576 management system is likely to ask for an extremely long timeout 2577 because its user may be planning on going off-line. 2579 A client MUST NOT assume that just because the time-out has expired 2580 the lock has been lost. 2582 9 Status Code Extensions to HTTP/1.1 2584 The following status codes are added to those defined in HTTP/1.1 2585 [Fielding et al., 1997]. 2587 9.1 102 Processing 2589 Methods can potentially take a long period of time to process, 2590 especially methods that support the Depth header. In such cases the 2591 client may time-out the connection while waiting for a response. To 2592 prevent this the server may return a 102 status code to indicate to 2593 the client that the server is still processing the method. 2595 If a method is taking longer than 20 seconds (a reasonable, but 2596 arbitrary value) to process the server SHOULD return a 102 2597 "Processing" response. 2599 9.2 207 Multi-Status 2601 The response provides status for multiple independent operations. 2603 9.3 422 Unprocessable Entity 2605 The server understands the content type of the request entity, but 2606 was unable to process the contained instructions. 2608 9.4 423 Locked 2610 The source or destination resource of a method is locked. 2612 9.5 424 Method Failure 2614 The method was not executed on a particular resource within its 2615 scope because some part of the method's execution failed causing the 2616 entire method to be aborted. For example, if a resource could not 2617 be moved as part of a MOVE method, all the other resources would 2618 fail with a 424 Method Failure. 2620 9.6 425 Insufficient Space on Resource 2622 The resource does not have sufficient space to record the state of 2623 the resource after the execution of this method. 2625 10 Multi-Status Response 2627 The default 207 Multi-Status response body is a text/xml HTTP entity 2628 that contains a single XML element called multistatus, which 2629 contains a set of XML elements called response which contain 200, 2630 300, 400, and 500 series status codes generated during the method 2631 invocation. 100 series status codes SHOULD NOT be recorded in a 2632 response XML element. 2634 11 XML Element Definitions 2636 In the section below, the final line of each section gives the 2637 element type declaration using the format defined in [Bray, Paoli, 2638 Sperberg-McQueen, 1998]. The "Value" field, where present, specifies 2639 futher restrictions on the allowable contents of the XML element 2640 using BNF (i.e., to further restrict the values of a PCDATA 2641 element). 2643 11.1 activelock XML Element 2645 Name: activelock 2646 Namespace: DAV: 2647 Purpose: Describes a lock on a resource. 2649 2652 11.1.1 depth XML Element 2654 Name: depth 2655 Namespace: DAV: 2656 Purpose: The value of the depth header used to create a lock. 2657 Value: "0" | "infinity" 2659 2661 11.1.2 locktoken XML Element 2663 Name: locktoken 2664 Namespace: DAV: 2665 Purpose: The lock token associated with a lock. 2666 Description: The href contains one or more opaque lock token URIs 2667 which all refer to the same lock (i.e., the OpaqueLockToken-URI 2668 production in section 5.4). 2670 2672 11.1.3 timeout XML Element 2674 Name: timeout 2675 Namespace: DAV: 2676 Purpose: The timeout associated with a lock 2677 Value: TimeType ;Defined in section 8.8 2679 2681 11.2 collection XML Element 2683 Name: collection 2684 Namespace: DAV: 2685 Purpose: Identifies the associated resource as a collection. The 2686 resourcetype property of a collection resource MUST have this value. 2688 2690 11.3 href XML Element 2692 Name: href 2693 Namespace: DAV: 2694 Purpose: Identifies the content of the element as a URI. 2695 Value: URI ; See section 3.2.1 of [Fielding et al., 1997] 2697 2699 11.4 link XML Element 2701 Name: link 2702 Namespace: DAV: 2703 Purpose: Identifies the property as a link and contains the 2704 source and destination of that link. 2705 Description: The link XML element is used to provide the sources and 2706 destinations of a link. The name of the property containing the 2707 link XML element provides the type of the link. Link is a multi- 2708 valued element, so multiple links may be used together to indicate 2709 multiple links with the same type. The values in the href XML 2710 elements inside the src and dst XML elements of the link XML element 2711 MUST NOT be rejected if they point to resources which do not exist. 2713 2715 11.4.1 dst XML Element 2717 Name: dst 2718 Namespace: DAV: 2719 Purpose: Indicates the destination of a link 2720 Value: URI 2722 2724 11.4.2 src XML Element 2726 Name: src 2727 Namespace: DAV: 2728 Purpose: Indicates the source of a link. 2729 Value: URI 2731 2733 11.5 lockentry XML Element 2735 Name: lockentry 2736 Namespace: DAV: 2737 Purpose: Defines the types of locks that can be used with the 2738 resource. 2740 2742 11.6 lockinfo XML Element 2744 Name: lockinfo 2745 Namespace: DAV: 2746 Purpose: The lockinfo XML element is used with a LOCK method to 2747 specify the type of lock the client wishes to have created. 2749 2751 11.7 lockscope XML Element 2753 Name: lockscope 2754 Namespace: DAV: 2755 Purpose: Specifies whether a lock is an exclusive lock, or a 2756 shared lock. 2758 2760 11.7.1 exclusive XML Element 2762 Name: exclusive 2763 Namespace: DAV: 2764 Purpose: Specifies an exclusive lock 2766 2768 11.7.2 shared XML Element 2770 Name: shared 2771 Namespace: DAV: 2772 Purpose: Specifies a shared lock 2774 2776 11.8 locktype XML Element 2778 Name: locktype 2779 Namespace: DAV: 2780 Purpose: Specifies the access type of a lock. At present, this 2781 specification only defines one lock type, the write lock. 2783 2785 11.8.1 write XML Element 2787 Name: write 2788 Namespace: DAV: 2789 Purpose: Specifies a write lock. 2791 2793 11.9 multistatus XML Element 2795 Name: multistatus 2796 Namespace: DAV: 2797 Purpose: Contains multiple response messages. 2798 Description: The responsedescription at the top level is used to 2799 provide a general message describing the overarching nature of the 2800 response. If this value is available an application may use it 2801 instead of presenting the individual response descriptions contained 2802 within the responses. 2804 2806 11.9.1 response XML Element 2808 Name: response 2809 Namespace: DAV: 2810 Purpose: Holds a single response describing the effect of a 2811 method on resource and/or its properties. 2812 Description: A particular href MUST NOT appear more than once as the 2813 child of a response XML element under a multistatus XML element. 2814 This requirement is necessary in order to keep processing costs for 2815 a response to linear time. Essentially, this prevents having to 2816 search in order to group together all the responses by href. There 2817 are, however, no requirements regarding ordering based on href 2818 values. 2820 2823 11.9.1.1 propstat XML Element 2825 Name: propstat 2826 Namespace: DAV: 2827 Purpose: Groups together a prop and status element that is 2828 associated with a particular href element. 2829 Description: The propstat XML element MUST contain one or more empty 2830 prop XML elements representing the names of properties. Multiple 2831 properties may be included if the same response applies to them all. 2833 2835 11.9.1.2 status XML Element 2837 Name: status 2838 Namespace: DAV: 2839 Purpose: Holds a single HTTP status-line 2840 Value: status-line ;status-line defined in [Fielding et al., 2841 1997] 2843 2845 11.9.2 responsedescription XML Element 2847 Name: responsedescription 2848 Namespace: DAV: 2849 Purpose: Contains a message that can be displayed to the user 2850 explaining the nature of the response. 2851 Description: This XML element provides information suitable to be 2852 presented to a user. 2854 2856 11.10 owner XML Element 2858 Name: owner 2859 Namespace: DAV: 2860 Purpose: Provides information about the principal taking out a 2861 lock. 2862 Description: The owner XML element provides information sufficient 2863 for either directly contacting a principal (such as a telephone 2864 number or Email URI), or for discovering the principal (such as the 2865 URL of a homepage) who owns a lock. 2867 2869 11.11 prop XML element 2871 Name: prop 2872 Namespace: DAV: 2873 Purpose: Contains properties related to a resource. 2874 Description: The prop XML element is a generic container for 2875 properties defined on resources. All elements inside a prop XML 2876 element MUST define properties related to the resource. No other 2877 elements may be used inside of a prop element. 2879 2881 11.12 propertybehavior XML element 2883 Name: propertybehavior 2884 Namespace: DAV: 2886 Purpose: Specifies how properties are handled during a COPY or 2887 MOVE. 2889 Description: The propertybehavior XML element specifies how 2890 properties are handled during a COPY or MOVE. If this XML element 2891 is not included in the request body then the server is expected to 2892 act as defined by the default property handling behavior of the 2893 associated method. All WebDAV compliant resources MUST support the 2894 propertybehavior XML element. 2896 2898 11.12.1 keepalive XML element 2900 Name: keepalive 2901 Namespace: DAV: 2902 Purpose: Specifies requirements for the copying/moving of live 2903 properties. 2904 Description: If a list of URIs is included as the value of keepalive 2905 then the named properties MUST be "live" after they are copied 2906 (moved) to the destination resource of a COPY (or MOVE). If the 2907 value "*" is given for the keepalive XML element, this designates 2908 that all live properties on the source resource MUST be live on the 2909 destination. If the requirements specified by the keepalive element 2910 can not be honored then the method MUST fail with a 412 Precondition 2911 Failed. All DAV compliant resources MUST support the keepalive XML 2912 element for use with the COPY and MOVE methods. 2913 Value: "*" ; #PCDATA value can only be "*" 2915 2917 11.12.2 omit XML element 2919 Name: omit 2920 Namespace: DAV: 2921 Purpose: The omit XML element instructs the server that it should 2922 use best effort to copy properties but a failure to copy a property 2923 MUST NOT cause the method to fail. 2924 Description: The default behavior for a COPY or MOVE is to copy/move 2925 all properties or fail the method. In certain circumstances, such 2926 as when a server copies a resource over another protocol such as 2927 FTP, it may not be possible to copy/move the properties associated 2928 with the resource. Thus any attempt to copy/move over FTP would 2929 always have to fail because properties could not be moved over, even 2930 as dead properties. All DAV compliant resources MUST support the 2931 omit XML element on COPY/MOVE methods. 2933 2935 11.13 propertyupdate XML element 2937 Name: propertyupdate 2938 Namespace: DAV: 2939 Purpose: Contains a request to alter the properties on a 2940 resource. 2942 Description: This XML element is a container for the information 2943 required to modify the properties on the resource. This XML element 2944 is multi-valued. 2946 2948 11.13.1 remove XML element 2950 Name: remove 2951 Namespace: DAV: 2952 Purpose: Lists the DAV properties to be removed from a resource. 2953 Description: Remove instructs that the properties specified in prop 2954 should be removed. Specifying the removal of a property that does 2955 not exist is not an error. All the XML elements in a prop XML 2956 element inside of a remove XML element MUST be empty, as only the 2958 names of properties to be removed are required. 2960 2962 11.13.2 set XML element 2964 Name: set 2965 Namespace: DAV: 2966 Purpose: Lists the DAV property values to be set for a resource. 2967 Description: The set XML element MUST contain only a prop XML 2968 element. The elements contained by the prop XML element inside the 2969 set XML element MUST specify the name and value of properties that 2970 are set on the Request-URI. If a property already exists then its 2971 value is replaced. 2973 2975 11.14 propfind XML Element 2977 Name: propfind 2978 Namespace: DAV: 2979 Purpose: Specifies the properties to be returned from a PROPFIND 2980 method. Two special elements are specified for use with propfind, 2981 allprop and propname. If prop is used inside propfind it MUST only 2982 contain property names, not values. 2984 2986 11.14.1 allprop XML Element 2988 Name: allprop 2989 Namespace: DAV: 2990 Purpose: The allprop XML element specifies that all property 2991 names and values on the resource are to be returned. 2993 2995 11.14.2 propname XML Element 2997 Name: propname 2998 Namespace: DAV: 2999 Purpose: The propname XML element specifies that only a list of 3000 property names on the resource is to be returned. 3002 3004 12 DAV Properties 3006 For DAV properties, the name of the property is also the same as the 3007 name of the XML element that contains its value. In the section 3008 below, the final line of each section gives the element type 3010 declaration using the format defined in [Bray, Paoli, Sperberg- 3011 McQueen, 1998]. The "Value" field, where present, specifies futher 3012 restrictions on the allowable contents of the XML element using BNF 3013 (i.e., to further restrict the values of a PCDATA element). 3015 12.1 creationdate Property 3017 Name: creationdate 3018 Namespace: DAV: 3019 Purpose: Records the time and date the resource was created. 3020 Value: date-time ; See Appendix 2 3021 Description: The creationdate property should be defined on all DAV 3022 compliant resources. If present, it contains a timestamp of the 3023 moment when the resource was created (i.e., the moment it had non- 3024 null state). 3026 3028 12.2 displayname Property 3030 Name: displayname 3031 Namespace: DAV: 3032 Purpose: Provides a name for the resource that is suitable for 3033 presentation to a user. 3034 Description: The displayname property should be defined on all DAV 3035 compliant resources. If present, the property contains a 3036 description of the resource that is suitable for presentation to a 3037 user. 3039 3041 12.3 getcontentlanguage Property 3043 Name: getcontentlanguage 3044 Namespace: DAV: 3045 Purpose: Contains the Content-Language header returned by a GET 3046 without accept headers 3047 Description: The getcontentlanguage property MUST be defined on any 3048 DAV compliant resource that returns the Content-Language header on a 3049 GET. 3050 Value: language-tag ;language-tag is defined in section 14.13 3051 of [Fielding et al., 1997] 3053 3055 12.4 getcontentlength Property 3057 Name: getcontentlength 3058 Namespace: DAV: 3059 Purpose: Contains the Content-Length header returned by a GET 3060 without accept headers. 3061 Description: The getcontentlength property MUST be defined on any 3062 DAV compliant resource that returns the Content-Length header in 3063 response to a GET. 3064 Value: content-length ; see section 14.14 of [Fielding et al., 3065 1997] 3067 3069 12.5 getcontenttype Property 3071 Name: getcontenttype 3072 Namespace: DAV: 3073 Purpose: Contains the Content-Type header returned by a GET 3074 without accept headers. 3075 Description: This getcontenttype property MUST be defined on any DAV 3076 compliant resource that returns the Content-Type header in response 3077 to a GET. 3078 Value: media-type ; defined in section 3.7 of [Fielding et 3079 al., 1997] 3081 3083 12.6 getetag Property 3085 Name: getetag 3086 Namespace: DAV: 3088 Purpose: Contains the ETag header returned by a GET without 3089 accept headers. 3090 Description: Note that the ETag on a resource may reflect changes in 3091 any part of the state of the resource, not necessarily just a change 3092 to the response to the GET method. For example, a change to a 3093 resource's access permissions may cause the ETag to change. The 3094 getetag property MUST be defined on any DAV compliant resource that 3095 returns the Etag header in response to a GET. 3096 Value: entity-tag ; defined in section 3.11 of [Fielding et 3097 al., 1997] 3099 3101 12.7 getlastmodified Property 3103 Name: getlastmodified 3104 Namespace: DAV: 3105 Purpose: Contains the Last-Modified header returned by a GET 3106 method without accept headers. 3107 Description: Note that the last-modified date on a resource may 3108 reflect changes in any part of the state of the resource, not 3109 necessarily just a change to the response to the GET method. For 3110 example, a change in a property may cause the last-modified date to 3111 change. The getlastmodified property MUST be defined on any DAV 3112 compliant resource that returns the Last-Modified header in response 3113 to a GET. 3114 Value: HTTP-date ; defined in section 3.3.1 of [Fielding et 3115 al., 1997] 3117 3119 12.8 lockdiscovery Property 3121 Name: lockdiscovery 3122 Namespace: DAV: 3123 Purpose: Describes the active locks on a resource 3124 Description: The lockdiscovery property returns a listing of who has 3125 a lock, what type of lock he has, the timeout type and the time 3126 remaining on the timeout, and the associated lock token. The server 3127 is free to withhold any or all of this information if the requesting 3128 principal does not have sufficient access rights to see the 3129 requested data. 3131 3133 12.8.1 Example 3135 >>Request 3137 PROPFIND /container/ HTTP/1.1 3138 Host: www.foo.bar 3139 Content-Length: xxxx 3140 Content-Type: text/xml 3142 3143 3144 3145 3146 3147 >>Response 3149 HTTP/1.1 207 Multi-Status 3150 Content-Type: text/xml 3151 Content-Length: xxxxx 3153 3154 3155 3156 3157 http://www.foo.bar/container/ 3158 3159 3160 3161 3162 3163 3164 0 3165 Jane Smith 3166 Infinite 3167 3168 3169 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 3170 3171 3172 3173 3174 3175 HTTP/1.1 200 OK 3176 3177 3178 3180 This resource has a single exclusive write lock on it, with an 3181 infinite timeout. 3183 12.9 resourcetype Property 3185 Name: resourcetype 3186 Namespace: DAV: 3187 Purpose: Specifies the nature of the resource. 3188 Description: The resourcetype property MUST be defined on all DAV 3189 compliant resources. The default value is empty. 3191 3193 12.10 source Property 3195 Name: source 3196 Namespace: DAV: 3197 Purpose: The destination of the source link identifies the 3198 resource that contains the unprocessed source of the link's source. 3200 Description: The source of the link (src) is typically the URI of 3201 the output resource on which the link is defined, and there is 3202 typically only one destination (dst) of the link, which is the URI 3203 where the unprocessed source of the resource may be accessed. When 3204 more than one link destination exists, this specification asserts no 3205 policy on ordering. 3207 3209 12.10.1 Example 3211 3212 3213 3214 3215 3216 3217 Source 3218 http://foo.bar/program 3219 http://foo.bar/src/main.c 3220 3221 3222 Library 3223 http://foo.bar/program 3224 http://foo.bar/src/main.lib 3225 3226 3227 Makefile 3228 http://foo.bar/program 3229 http://foo.bar/src/makefile 3230 3231 3232 3234 In this example the resource http://foo.bar/program has a source 3235 property that contains three links. Each link contains three 3236 elements, two of which, src and dst, are part of the DAV schema 3237 defined in this document, and one which is defined by the schema 3238 http://www.foocorp.com/project/ (Source, Library, and Makefile). A 3239 client which only implements the elements in the DAV spec will not 3240 understand the foocorp elements and will ignore them, thus seeing 3241 the expected source and destination links. An enhanced client may 3242 know about the foocorp elements and be able to present the user with 3243 additional information about the links. This example demonstrates 3244 the power of XML markup, allowing element values to be enhanced 3245 without breaking older clients. 3247 12.11 supportedlock Property 3249 Name: supportedlock 3250 Namespace: DAV: 3251 Purpose: To provide a listing of the lock capabilities supported 3252 by the resource. 3253 Description: The supportedlock property of a resource returns a 3254 listing of the combinations of scope and access types which may be 3255 specified in a lock request on the resource. Note that the actual 3256 contents are themselves controlled by access controls so a server is 3257 not required to provide information the client is not authorized to 3259 see. 3261 3263 12.11.1 Example 3265 >>Request 3267 PROPFIND /container/ HTTP/1.1 3268 Host: www.foo.bar 3269 Content-Length: xxxx 3270 Content-Type: text/xml 3272 3273 3274 3275 3276 3278 >>Response 3280 HTTP/1.1 207 Multi-Status 3281 Content-Type: text/xml 3282 Content-Length: xxxxx 3284 3285 3286 3287 3288 http://www.foo.bar/container/ 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3301 3302 3303 HTTP/1.1 200 OK 3304 3305 3306 3308 13 DAV XML Processing Instructions 3310 All DAV compliant resources MUST ignore any unknown XML element and 3311 all its children encountered while processing a DAV method that uses 3312 XML as its command language. 3314 This restriction also applies to the processing, by clients, of DAV 3315 property values where unknown XML elements SHOULD be ignored unless 3316 the property's schema declares otherwise. 3318 This restriction does not apply to setting dead DAV properties on 3319 the server where the server MUST record unknown XML elements. 3321 Additionally, this restriction does not apply to the use of XML 3322 where XML happens to be the content type of the entity body, for 3323 example, when used as the body of a PUT. 3325 14 DAV Compliance Classes 3327 A DAV compliant resource can choose from two classes of compliance. 3328 A client can discover the compliance classes of a resource by 3329 executing OPTIONS on the resource, and examining the "DAV" header 3330 which is returned. 3332 Since this document describes extensions to the HTTP/1.1 protocol, 3333 minimally all DAV compliant resources, clients, and proxies MUST be 3334 compliant with [Fielding et al., 1997]. 3336 Compliance classes are not necessarily sequential. A resource that 3337 is class 2 compliant must also be class 1 compliant; but if 3338 additional compliance classes are defined later, a resource that is 3339 class 1, 2, and 4 compliant might not be class 3 compliant. Also 3340 note that identifiers other than numbers may be used as compliance 3341 class identifiers. 3343 14.1 Class 1 3345 A class 1 compliant resource MUST meet all "MUST" requirements in 3346 all sections of this document. 3348 Class 1 compliant resources MUST return, at minimum, the value "1" 3349 in the DAV header on all responses to the OPTIONS method. 3351 14.2 Class 2 3353 A class 2 compliant resource MUST meet all class 1 requirements and 3354 support the LOCK method, the supportedlock property, the 3355 lockdiscovery property, the Time-Out response header and the Lock- 3356 Token request header. A class "2" compliant resource SHOULD also 3357 support the Time-Out request header and the owner XML element. 3359 Class 2 compliant resources MUST return, at minimum, the values "1" 3360 and "2" in the DAV header on all responses to the OPTIONS method. 3362 15 Internationalization Considerations 3364 In the realm of internationalization, this specification complies 3365 with the IETF Character Set Policy [Alvestrand, 1998]. In this 3366 specification, human-readable fields can be found either in the 3367 value of a property, or in an error message returned in a response 3368 entity body. In both cases, the human-readable content is encoded 3369 using XML, which has explicit provisions for character set tagging 3370 and encoding, and requires that XML processors read XML elements 3371 encoded, at minimum, using the UTF-8 [Yergeau, 1998] encoding of the 3372 ISO 10646 multilingual plane. 3374 XML also provides a language tagging capability for specifying the 3375 language of the contents of a particular XML element. XML uses 3376 either IANA registered language tags (see RFC 1766, [Alvestrand, 3377 1995]) or ISO 639 language tags [ISO-639] in the "xml:lang" 3378 attribute of an XML element to identify the language of its content 3379 and attributes. 3381 WebDAV applications MUST support the character set tagging, 3382 character set encoding, and the language tagging functionality of 3383 the XML specification. 3385 Names used within this specification fall into three categories: 3386 names of protocol elements such as methods and headers, names of XML 3387 elements, and names of properties. Naming of protocol elements 3388 follows the precedent of HTTP, using English names encoded in 3389 USASCII for methods and headers. Since these protocol elements are 3390 not visible to users, and are in fact simply long token identifiers, 3391 they do not need to support encoding in multiple character sets. 3392 Similarly, though the names of XML elements used in this 3393 specification are English names encoded in UTF-8, these names are 3394 not visible to the user, and hence do not need to support multiple 3395 character set encodings. 3397 The name of a property defined on a resource is a URI. Although 3398 some applications (e.g., a generic property viewer) will display 3399 property URIs directly to their users, it is expected that the 3400 typical application will use a fixed set of properties, and will 3401 provide a mapping from the property name URI to a human-readable 3402 field when displaying the property name to a user. It is only in 3403 the case where the set of properties is not known ahead of time that 3404 an application need display a property name URI to a user. We 3405 recommend that applications provide human-readable property names 3406 wherever feasible. 3408 For error reporting, we follow the convention of HTTP/1.1 status 3409 codes, including with each status code a short, English description 3410 of the code (e.g., 423 Locked). While the possibility exists that a 3411 poorly crafted user agent would display this message to a user, 3412 internationalized applications will ignore this message, and display 3413 an appropriate message in the user's language and character set. 3415 Since interoperation of clients and servers does not require locale 3416 information, this specification does not specify any mechanism for 3417 transmission of this information. 3419 16 Security Considerations 3421 This section is provided to detail issues concerning security 3422 implications of which WebDAV applications need to be aware. 3424 All of the security considerations of HTTP/1.1 also apply to WebDAV. 3425 In addition, the security risks inherent in remote authoring require 3426 stronger authentication technology, introduce several new privacy 3427 concerns, and may increase the hazards from poor server design. 3428 These issues are detailed below. 3430 16.1 Authentication of Clients 3432 Due to their emphasis on authoring, WebDAV servers need to use 3433 authentication technology to protect not just access to a network 3434 resource, but the integrity of the resource as well. Furthermore, 3435 the introduction of locking functionality requires support for 3436 authentication. 3438 A password sent in the clear over an insecure channel is an 3439 inadequate means for protecting the accessibility and integrity of a 3440 resource as the password may be intercepted. Since Basic 3441 authentication for HTTP/1.1 performs essentially clear text 3442 transmission of a password, Basic authentication MUST NOT be used to 3443 authenticate a WebDAV client to a server unless the connection is 3444 secure. Furthermore, a WebDAV server MUST NOT send Basic 3445 authentication credentials in a WWW-Authenticate header unless the 3446 connection is secure. Examples of secure connections include a 3447 Transport Layer Security (TLS) connection, or a connection over a 3448 network which is physically secure, for example, an isolated network 3449 in a building with restricted access. 3451 WebDAV applications MUST support the Digest authentication scheme 3452 [Franks et al., 1997]. Since Digest authentication verifies that 3453 both parties to a communication know a shared secret, a password, 3454 without having to send that secret in the clear, Digest 3455 authentication avoids the security problems inherent in Basic 3456 authentication while providing a level of authentication which is 3457 useful in a wide range of scenarios. 3459 16.2 Denial of Service 3461 Denial of service attacks are of special concern to WebDAV servers. 3462 WebDAV plus HTTP enables denial of service attacks on every part of 3463 a system's resources. 3465 The underlying storage can be attacked by PUTting extremely large 3466 files. 3468 Asking for recursive operations on large collections can attack 3469 processing time. 3471 Making multiple pipelined requests on multiple connections can 3472 attack network connections. 3474 WebDAV servers need to be aware of the possibility of a denial of 3475 service attack at all levels. 3477 16.3 Security through Obscurity 3479 WebDAV provides, through the PROPFIND method, a mechanism for 3480 listing the member resources of a collection. This greatly 3481 diminishes the effectiveness of security or privacy techniques that 3482 rely only on the difficulty of discovering the names of network 3483 resources. Users of WebDAV servers are encouraged to use access 3484 control techniques to prevent unwanted access to resources, rather 3485 than depending on the relative obscurity of their resource names. 3487 16.4 Privacy Issues Connected to Locks 3489 When submitting a lock request a user agent may also submit an owner 3490 XML field giving contact information for the person taking out the 3491 lock (for those cases where a person, rather than a robot, is taking 3492 out the lock). This contact information is stored in a lockdiscovery 3493 property on the resource, and can be used by other collaborators to 3494 begin negotiation over access to the resource. However, in many 3495 cases this contact information can be very private, and should not 3496 be widely disseminated. Servers SHOULD limit read access to the 3497 lockdiscovery property as appropriate. Furthermore, user agents 3498 SHOULD provide control over whether contact information is sent at 3499 all, and if contact information is sent, control over exactly what 3500 information is sent. 3502 16.5 Privacy Issues Connected to Properties 3504 Since property values are typically used to hold information such as 3505 the author of a document, there is the possibility that privacy 3506 concerns could arise stemming from widespread access to a resource's 3507 property data. To reduce the risk of inadvertent release of private 3508 information via properties, servers are encouraged to develop access 3509 control mechanisms that separate read access to the resource body 3510 and read access to the resource's properties. This allows a user to 3511 control the dissemination of their property data without overly 3512 restricting access to the resource's contents. 3514 16.6 Reduction of Security due to Source Link 3516 HTTP/1.1 warns against providing read access to script code because 3517 it may contain sensitive information. Yet WebDAV, via its source 3518 link facility, can potentially provide a URL for script resources so 3519 they may be authored. For HTTP/1.1, a server could reasonably 3520 prevent access to source resources due to the predominance of read- 3521 only access. WebDAV, with its emphasis on authoring, encourages 3522 read and write access to source resources, and provides the source 3523 link facility to identify the source. This reduces the security 3524 benefits of eliminating access to source resources. Users and 3525 administrators of WebDAV servers should be very cautious when 3526 allowing remote authoring of scripts, limiting read and write access 3527 to the source resources to authorized principals. 3529 17 IANA Considerations 3531 This document defines two namespaces, the namespace of property 3532 names, and the namespace of WebDAV-specific XML elements used within 3533 property values. 3535 URLs are used for both names, for several reasons. Assignment of a 3536 URL does not require a request to a central naming authority, and 3537 hence allow WebDAV property names and XML elements to be quickly 3538 defined by any WebDAV user or application. URLs also provide a 3539 unique address space, ensuring that the distributed users of WebDAV 3540 will not have collisions among the property names and XML elements 3541 they create. 3543 This specification defines a distinguished set of property names and 3544 XML elements that are understood by all WebDAV applications. The 3545 property names and XML elements in this specification are all 3546 derived from the base URI DAV: by adding a suffix to this URI, for 3547 example, DAV:creationdate for the "creationdate" property. 3549 This specification also defines a URI scheme for the encoding of 3550 lock tokens, the opaquelocktoken URI scheme described in section 3551 5.4. 3553 To ensure correct interoperation based on this specification, IANA 3554 must reserve the URI namespaces starting with "DAV:" and with 3555 "opaquelocktoken:" for use by this specification, its revisions, and 3556 related WebDAV specifications. 3558 18 Terminology 3560 Collection - A resource that contains member resources and meets the 3561 requirements in section 4 of this specification. 3563 Member Resource - A resource contained by a collection. 3565 Internal Member Resource - A member resource of a collection whose 3566 URI is relative to the URI of the collection. 3568 Property - A name/value pair that contains descriptive information 3569 about a resource. 3571 Live Property - A property whose semantics and syntax are enforced 3572 by the server. For example, a live "content-length" property would 3573 have its value, the length of the entity returned by a GET request, 3574 automatically calculated by the server. 3576 Dead Property - A property whose semantics and syntax are not 3577 enforced by the server. The server only records the value of a dead 3578 property; the client is responsible for maintaining the consistency 3579 of the syntax and semantics of a dead property. 3581 19 Copyright 3583 The following copyright notice is copied from RFC 2026 [Bradner, 3584 1996], section 10.4, and describes the applicable copyright for this 3585 document. 3587 Copyright (C) The Internet Society March 6, 1998. All Rights 3588 Reserved. 3590 This document and translations of it may be copied and furnished to 3591 others, and derivative works that comment on or otherwise explain it 3592 or assist in its implementation may be prepared, copied, published 3593 and distributed, in whole or in part, without restriction of any 3594 kind, provided that the above copyright notice and this paragraph 3595 are included on all such copies and derivative works. However, this 3596 document itself may not be modified in any way, such as by removing 3597 the copyright notice or references to the Internet Society or other 3598 Internet organizations, except as needed for the purpose of 3600 developing Internet standards in which case the procedures for 3601 copyrights defined in the Internet Standards process must be 3602 followed, or as required to translate it into languages other than 3603 English. 3605 The limited permissions granted above are perpetual and will not be 3606 revoked by the Internet Society or its successors or assignees. 3608 This document and the information contained herein is provided on an 3609 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3610 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3611 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3612 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3613 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3615 20 Intellectual Property 3617 The following notice is copied from RFC 2026 [Bradner, 1996], 3618 section 10.4, and describes the position of the IETF concerning 3619 intellectual property claims made against this document. 3621 The IETF takes no position regarding the validity or scope of any 3622 intellectual property or other rights that might be claimed to 3623 pertain to the implementation or use other technology described in 3624 this document or the extent to which any license under such rights 3625 might or might not be available; neither does it represent that it 3626 has made any effort to identify any such rights. Information on the 3627 IETF's procedures with respect to rights in standards-track and 3628 standards-related documentation can be found in BCP-11. Copies of 3629 claims of rights made available for publication and any assurances 3630 of licenses to be made available, or the result of an attempt made 3631 to obtain a general license or permission for the use of such 3632 proprietary rights by implementors or users of this specification 3633 can be obtained from the IETF Secretariat. 3635 The IETF invites any interested party to bring to its attention any 3636 copyrights, patents or patent applications, or other proprietary 3637 rights which may cover technology that may be required to practice 3638 this standard. Please address the information to the IETF Executive 3639 Director. 3641 21 Acknowledgements 3643 A specification such as this thrives on piercing critical review and 3644 withers from apathetic neglect. The authors gratefully acknowledge 3645 the contributions of the following people, whose insights were so 3646 valuable at every stage of our work. 3648 Terry Allen, Harald Alvestrand, Alan Babich, Sanford Barr, Dylan 3649 Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim 3650 Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, 3651 Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Roy 3652 Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, 3653 Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Alex Hopmann, 3654 Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen 3655 MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith 3656 Moore, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon 3657 Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith 3658 Slein, Mike Spreitzer, Einar Stefferud, Ralph Swick, Kenji 3659 Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar 3660 Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood. 3662 Two from this list deserve special mention. The contributions by 3663 Larry Masinter have been invaluable, both in helping the formation 3664 of the working group and in patiently coaching the authors along the 3665 way. In so many ways he has set high standards we have toiled to 3666 meet. The contributions of Judith Slein in clarifying the 3667 requirements, and in patiently reviewing draft after draft, both 3668 improved this specification and expanded our minds on document 3669 management. 3671 We would also like to thank John Turner for developing the XML DTD. 3673 22 References 3675 [Alvestrand, 1995] H. T. Alvestrand, "Tags for the Identification of 3676 Languages." RFC 1766. Uninett. March, 1995. 3678 [Alvestrand, 1998] H. T. Alvestrand, "IETF Policy on Character Sets 3679 and Languages." RFC 2277, BCP 18. Uninett. January, 1998. 3681 [Bradner, 1996] S. Bradner, "The Internet Standards Process - 3682 Revision 3." RFC 2026, BCP 9. Harvard University. October, 1996. 3684 [Bradner, 1997] S. Bradner, "Key words for use in RFCs to Indicate 3685 Requirement Levels." RFC 2119, BCP 14. Harvard University. March, 3686 1997. 3688 [Bray, Hollander, Layman, 1998] T. Bray, D. Hollander, A. Layman, 3689 "Name Spaces in XML" World Wide Web Consortium Note, 3690 http://www.w3.org/TR/1998/NOTE-xml-names. 3692 [Bray, Paoli, Sperberg-McQueen, 1998] T. Bray, J. Paoli, C. M. 3693 Sperberg-McQueen, "Extensible Markup Language (XML)." World Wide Web 3694 Consortium Recommendation REC-xml-19980210. 3695 http://www.w3.org/TR/1998/REC-xml-19980210. 3697 [Franks et al., 1997] J. Franks, P. Hallam-Baker, J. Hostetler, P. 3698 Leach, A. Luotonen, E. Sink, and L. Stewart. "An Extension to HTTP : 3699 Digest Access Authentication" RFC 2069. Northwestern University, 3700 CERN, Spyglass Inc., Microsoft Corp., Netscape Communications Corp., 3701 Spyglass Inc., Open Market Inc. January 1997. 3703 [Fielding et al., 1997] R. Fielding, J. Gettys, J. Mogul, H. 3704 Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." 3705 RFC 2068. U.C. Irvine, DEC, MIT/LCS. January, 1997. 3707 [ISO-639] ISO (International Organization for Standardization). ISO 3708 639:1988. "Code for the representation of names of languages." 3710 [ISO-8601] ISO (International Organization for Standardization). ISO 3711 8601:1988. "Data elements and interchange formats - Information 3712 interchange - Representation of dates and times." 3714 [Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for 3715 Bibliographic Records," RFC 1807. Stanford, Myricom. June, 1995. 3717 [Leach, Salz, 1998] P. J. Leach, R. Salz, "UUIDs and GUIDs." 3718 Internet-draft, work-in-progress, February, 1998. 3719 ftp://ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt 3721 [MARC, 1994] Network Development and MARC Standards, Office, ed. 3722 1994. "USMARC Format for Bibliographic Data", 1994. Washington, DC: 3723 Cataloging Distribution Service, Library of Congress. 3725 [Miller et al., 1996] J. Miller, T. Krauskopf, P. Resnick, W. 3726 Treese, "PICS Label Distribution Label Syntax and Communication 3727 Protocols" Version 1.1, World Wide Web Consortium Recommendation 3728 REC-PICS-labels-961031. http://www.w3.org/pub/WWW/TR/REC-PICS- 3729 labels-961031.html. 3731 [Slein et al., 1998] J. A. Slein, F. Vitali, E. J. Whitehead, Jr., 3732 D. Durand, "Requirements for Distributed Authoring and Versioning 3733 Protocol for the World Wide Web." RFC 2291. Xerox, Univ. of Bologna, 3734 U.C. Irvine, Boston Univ. February, 1998. 3736 [Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel, 3737 "OCLC/NCSA Metadata Workshop Report." 3738 http://purl.oclc.org/metadata/dublin_core_report. 3740 [Yergeau, 1998] F. Yergeau, "UTF-8, a transformation format of 3741 Unicode and ISO 10646." RFC 2279. Alis Technologies. January, 1998. 3743 23 Authors' Addresses 3745 Y. Y. Goland 3746 Microsoft Corporation 3747 One Microsoft Way 3748 Redmond, WA 98052-6399 3749 Email: yarong@microsoft.com 3751 E. J. Whitehead, Jr. 3752 Dept. Of Information and Computer Science 3753 University of California, Irvine 3754 Irvine, CA 92697-3425 3755 Email: ejw@ics.uci.edu 3757 A. Faizi 3758 Netscape 3759 685 East Middlefield Road 3760 Mountain View, CA 94043 3761 Email: asad@netscape.com 3763 S. R. Carter 3764 Novell 3765 1555 N. Technology Way 3766 M/S ORM F111 3767 Orem, UT 84097-2399 3768 Email: srcarter@novell.com 3770 D. Jensen 3771 Novell 3772 1555 N. Technology Way 3773 M/S ORM F111 3774 Orem, UT 84097-2399 3775 Email: dcjensen@novell.com 3777 24 Appendices 3779 24.1 Appendix 1 - WebDAV Document Type Definition 3781 This section provides a document type definition, following the 3782 rules in [Bray, Paoli, Sperberg-McQueen, 1998], for the XML elements 3783 used in the protocol stream and in the values of properties. It 3784 collects the element definitions given in sections 11 and 12. 3786 3790 3793 3794 3796 3797 3799 3800 3801 3803 3805 3807 3809 3811 3813 3814 3815 3817 3819 3821 3822 3823 3825 3827 3828 3829 3831 3832 3833 3835 3836 3837 3839 3841 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3855 ]> 3857 24.2 Appendix 2 - ISO 8601 Date and Time Profile 3859 The creationdate property specifies the use of the ISO 8601 date 3860 format [ISO-8601]. This section defines a profile of the ISO 8601 3861 date format for use with this specification. This profile is quoted 3862 verbatim from draft-newman-datetime-01.txt (expired). 3864 date-time = full-date "T" full-time 3866 full-date = date-fullyear "-" date-month "-" date-mday 3867 full-time = partial-time time-offset 3869 date-fullyear = 4DIGIT 3870 date-month = 2DIGIT ; 01-12 3871 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on 3872 month/year 3873 time-hour = 2DIGIT ; 00-23 3874 time-minute = 2DIGIT ; 00-59 3875 time-second = 2DIGIT ; 00-59, 00-60 based on leap second rules 3876 time-secfrac = "." 1*DIGIT 3877 time-numoffset = ("+" / "-") time-hour ":" time-minute 3878 time-offset = "Z" / time-numoffset 3879 partial-time = time-hour ":" time-minute ":" time-second 3880 [time-secfrac] 3882 Numeric offsets are calculated as local time minus UTC (Coordinated 3883 Universal Time). So the equivalent time in UTC can be determined by 3884 subtracting the offset from the local time. For example, 18:50:00- 3885 04:00 is the same time as 22:58:00Z. 3887 If the time in UTC is known, but the offset to local time is 3888 unknown, this can be represented with an offset of "-00:00". This 3889 differs from an offset of "Z" which implies that UTC is the 3890 preferred reference point for the specified time. 3892 24.3 Appendix 3 - Notes on Processing XML Elements 3894 XML is a flexible data format that makes it easy to submit data that 3895 appears legal but in fact is not. The philosophy of "Be flexible in 3896 what you accept and strict in what you send" still applies, but it 3897 must not be applied inappropriately. XML is extremely flexible in 3898 dealing with issues of white space, element ordering, inserting new 3899 elements, etc. This flexibility does not require extension, 3900 especially not in the area of the meaning of elements. 3902 There is no kindness in accepting illegal combinations of XML 3903 elements. At best it will cause an unwanted result and at worst it 3904 can cause real damage. 3906 24.3.1 XML Syntax Error Example 3908 The following request body for a PROPFIND method is illegal. 3910 3911 3912 3913 3914 3915 3917 The definition of the propfind element only allows for the allprop 3918 or the propname element, not both. Thus the above is an error and 3919 must be responded to with a 400 Bad Request. 3921 Imagine, however, that a server wanted to be "kind" and decided to 3922 pick the allprop element as the true element and respond to it. A 3923 client running over a bandwidth limited line who intended to execute 3924 a propname would be in for a big surprise if the server treated the 3925 command as an allprop. 3927 Additionally, if a server were lenient and decided to reply to this 3928 request, the results would vary randomly from server to server, with 3929 some servers executing the allprop directive, and others executing 3930 the propname directive. This reduces interoperability rather than 3931 increasing it. 3933 24.3.2 Unknown XML Element Example 3935 The previous example was illegal because it contained two elements 3936 that were explicitly banned from appearing together in the propfind 3937 element. However, XML is an extensible language, so one can imagine 3938 new elements being defined for use with propfind. Below is the 3939 request body of a PROPFIND and, like the previous example, must be 3940 rejected with a 400 Bad Request by a server that does not understand 3941 the expired-props element. 3943 3944 3945 3946 3947 3948 3950 To understand why a 400 Bad Request is returned let us look at the 3951 request body as the server unfamiliar with expired-props sees it. 3953 3954 3955 3956 3957 3959 As the server does not understand the expired-props element, by the 3960 rules of XML, it must ignore it. Thus the server sees an empty 3961 propfind, which by the definition of the propfind element is 3962 illegal. 3964 Please note that had the extension been additive it would not 3965 necessarily have resulted in a 400 Bad Request. For example, 3966 imagine the following request body for a PROPFIND: 3968 3969 3970 3971 3972 3973 *boss* 3974 3976 The previous example contains the fictitious element leave-out. Its 3977 purpose is to prevent the return of any property whose name matches 3978 the submitted pattern. If the previous example were submitted to a 3979 server unfamiliar with leave-out, the only result would be that the 3980 leave-out element would be ignored and a propname would be executed. 3982 24.4 Appendix 4 -- XML Namespaces for WebDAV 3984 [NOTE TO RFC EDITOR: If, as expected, the World Wide Web Consortium 3985 issues XML namespaces as a W3C Recommendation before this document 3986 is published as an RFC (i.e., after approval by the IESG, but before 3987 appearing in the rfc directory), then the text of this appendix must 3988 be changed to read: 3990 XML namespace functionality in this specification MUST conform to 3991 W3C Recommendation, "Name Spaces in XML" REC-XML-NAMES-1998????. 3992 ] 3994 24.4.1 Introduction 3996 To provide a unique space of XML element names which has 3997 decentralized extensibility, this specification uses a feature of 3998 XML known as XML "namespaces". This appendix provides a normative 3999 reference for XML namespace functionality for implementations of 4000 this specification. All DAV compliant systems MUST support the XML 4001 namespace extension as specified in this appendix." 4003 The remainder of this appendix is intended to match, as closely as 4004 needed, the text in Note-xml-names-19980119, "Name Spaces in XML", 4005 edited by Tim Bray, Dave Hollander, and Andrew Layman, 4006 http://www.w3.org/TR/1998/NOTE-xml-names. To meet this goal, the 4007 text in this appendix is mostly quoted verbatim from this source. 4008 As future drafts of the XML namespace proposal are generated, this 4009 appendix will be updated. To ensure this appendix reflects the 4010 exact XML namespace proposal, the notational conventions and BNF 4011 productions in this appendix match those of the XML specification 4012 [Bray, Paoli, Sperberg-McQueen, 1998]. 4014 XML Namespaces are based on the use of qualified names. Names are 4015 permitted to contain a colon, separating the name into two parts, 4016 the namespace name and the local name. The namespace name identifies 4017 a schema's URI. The combination of the universally-managed URI 4018 namespace and the local schema namespace produces names that are 4019 guaranteed universally unique. 4021 XML syntax does not allow direct use of a URI as a namespace name, 4022 because URIs can contain characters not allowed in XML element 4023 names. Consequently, the namespace name serves as a proxy for a URI. 4024 A special processing instruction described below is used to declare 4025 the association of the namespace name with a URI; software that 4026 supports this namespace proposal MUST recognize and act on namespace 4027 processing instructions. 4029 A namespace is declared using a reserved processing instruction. 4031 24.4.2 Namespace Declaration PI 4033 [1] NamespacePI ::= '' 4035 [2] NSName ::= ' Name ' | " Name " 4037 The "name" SystemLiteral is a URI which uniquely identifies the 4038 namespace. The "href" SystemLiteral is an optional URI which may be 4039 used to retrieve the schema, if one is provided. Some namespaces 4040 need no schemas; this specification does not depend on their 4041 existence, or on the use of any particular machine- or human- 4042 readable syntax in the schema. 4044 The NSName gives the namespace name which will be used as a link to 4045 associate names in an XML document with this schema. 4047 To accomplish this, the production for prolog is replaced as 4048 follows: 4050 24.4.3 Prolog with Namespace Declarations 4052 [3] prolog ::= XMLDecl? S? NamespacePI* Misc* (doctypedecl Misc*)? 4053 [ wfc: Unique Namespace Names ] 4055 24.4.4 Well-Formedness Constraint - Unique Namespace Names 4057 No namespace name may be declared more than once. 4059 24.4.5 Qualified Names 4061 Within the document, some names (constructs corresponding to the 4062 nonterminal Name) are replaced by qualified names, defined as 4063 follows: 4065 [4] QName ::= (NSPart ':')? LocalPart 4066 [5] NSPart ::= Name [ wfc: Namespace Name Declared ] 4067 [6] LocalPart ::= Name 4069 The NSPart provides the namespace name part of the qualified name, 4070 and may be associated with defining schema through the URI in the 4071 applicable namespace declaration. 4073 The LocalPart provides the local name part of the qualified name. 4075 24.4.6 Well-Formedness Constraint - Namespace Name Declared 4077 The namespace name, unless it is "xml", must have been declared in a 4078 namespace declaration. The namespace name xml is reserved, and 4079 considered to have been implicitly declared. 4081 24.4.7 Using Qualified Names 4083 To enable the proper use of qualified names, it is necessary to 4084 banish colons from all Names which are not qualified; two 4085 productions are replaced as follows: 4087 [7] Name ::= (Letter | '_' ) (NameChar)* 4088 [8] MiscName ::= '.' | '-' | '_' | CombiningChar | Ignorable | 4089 Extender 4091 24.4.8 Element Names 4093 Element types may be given as qualified names. To do this, the 4094 productions for start-, end-, and empty-element tags (STag, ETag, 4095 and EmptyElement) are replaced as follows: 4097 [9] STag ::= '<' QName (S Attribute)* S? '>' 4098 [10] ETag ::= '' 4099 [11] EmptyElement ::= '<' QName (S Attribute)* S? '/>' 4101 24.4.9 Scope and Meaning of Qualified Names 4103 [Note to the reader: This section does not appear in NOTE-xml-names, 4104 but is necessary to avoid ambiguity for WebDAV XML processors.] 4106 WebDAV compliant XML processors MUST interpret a qualified name as a 4107 URI constructed by appending the LocalPart to the schema URI of the 4108 namespace. The scope of a namespace in a qualified name is limited 4109 to a single element tag. Every start tag, end tag, or empty XML 4110 element from a namespace MUST include the namespace name in the tag. 4112 Scope Example 4114 4115 4116 4117 Johnny Updraft 4118 4119 4120 4122 In this example, the qualified element name "del:glider" is 4123 interpreted as the URL "http://www.del.jensen.org/glider". Since 4124 the scope of a namespace is limited to a single element, each start 4125 tag, end tag, and empty element tag in the example includes the 4126 short name of the namespace, "del" as part of the qualified name. 4128 4129 4130 4131 Johnny Updraft 4132 4133 4134 4136 Even though this example is syntactically different from the 4137 previous example, it is semantically identical. Each instance of 4138 the namespace name "bar" is replaced with 4139 "http://www.del.jensen.org/" and then appended to the local name for 4140 each element tag. The resulting tag names in this example are 4141 exactly the same as for the previous example. 4143 4144 4145 4146 Johnny Updraft 4147 4148 4149 4151 This example is semantically identical to the two previous ones. 4152 Each instance of the namespace name "foo" is replaced with 4153 "http://www.del.jensen.org/glide" which is then appended to the 4154 local name for each element tag, the resulting tag names are 4155 identical to those in the previous examples.