rfc2518.txt   draft-ietf-webdav-rfc2518bis-latest.txt 
Network Working Group Y. Goland WebDAV Working Group L. Dusseault, Ed.
Request for Comments: 2518 Microsoft Internet-Draft CommerceNet
Category: Standards Track E. Whitehead Obsoletes: 2518 (if approved) February 15, 2007
UC Irvine Intended status: Standards Track
A. Faizi Expires: August 19, 2007
Netscape
S. Carter
D. Jensen
Novell
February 1999
HTTP Extensions for Distributed Authoring -- WEBDAV HTTP Extensions for Distributed Authoring - WebDAV
draft-ietf-webdav-rfc2518bis-18
Status of this Memo Status of this Memo
This document specifies an Internet standards track protocol for the By submitting this Internet-Draft, each author represents that any
Internet community, and requests discussion and suggestions for applicable patent or other IPR claims of which he or she is aware
improvements. Please refer to the current edition of the "Internet have been or will be disclosed, and any of which he or she becomes
Official Protocol Standards" (STD 1) for the standardization state aware will be disclosed, in accordance with Section 6 of BCP 79.
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Copyright (C) The Internet Society (1999). All Rights Reserved. Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 19, 2007.
Abstract Abstract
This document specifies a set of methods, headers, and content-types WebDAV consists of a set of methods, headers, and content-types
ancillary to HTTP/1.1 for the management of resource properties, ancillary to HTTP/1.1 for the management of resource properties,
creation and management of resource collections, namespace creation and management of resource collections, URL namespace
manipulation, and resource locking (collision avoidance). manipulation, and resource locking (collision avoidance).
Table of Contents RFC2518 was published in February 1999, and this specification makes
minor revisions mostly due to interoperability experience.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 Table of Contents
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 7
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Data Model for Resource Properties . . . . . . . . . . . . . 8
4.1. The Resource Property Model . . . . . . . . . . . . . . 8
4.2. Existing Metadata Proposals . . . . . . . . . . . . . . 9
4.3. Properties and HTTP Headers . . . . . . . . . . . . . . 9
4.4. Property Values . . . . . . . . . . . . . . . . . . . . 10
4.5. Property Names . . . . . . . . . . . . . . . . . . . . . 10
4.6. Media Independent Links . . . . . . . . . . . . . . . . 11
5. Collections of Web Resources . . . . . . . . . . . . . . . . 11
5.1. HTTP URL Namespace Model . . . . . . . . . . . . . . . . 11
5.2. Collection Resources . . . . . . . . . . . . . . . . . . 11
5.3. Creation and Retrieval of Collection Resources . . . . . 13
5.4. Source Resources and Output Resources . . . . . . . . . 13
6. Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Exclusive Vs. Shared Locks . . . . . . . . . . . . . . . 15
6.2. Required Support . . . . . . . . . . . . . . . . . . . . 16
6.3. Lock Tokens . . . . . . . . . . . . . . . . . . . . . . 16
6.4. opaquelocktoken Lock Token URI Scheme . . . . . . . . . 16
6.4.1. Node Field Generation Without the IEEE 802 Address . 17
6.5. Lock Capability Discovery . . . . . . . . . . . . . . . 19
6.6. Active Lock Discovery . . . . . . . . . . . . . . . . . 19
6.7. Usage Considerations . . . . . . . . . . . . . . . . . . 20
7. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Methods Restricted by Write Locks . . . . . . . . . . . 21
7.2. Write Locks and Lock Tokens . . . . . . . . . . . . . . 21
7.3. Write Locks and Properties . . . . . . . . . . . . . . . 21
7.4. Write Locks and Null Resources . . . . . . . . . . . . . 21
7.5. Write Locks and Collections . . . . . . . . . . . . . . 22
7.6. Write Locks and the If Request Header . . . . . . . . . 22
7.6.1. Example - Write Lock . . . . . . . . . . . . . . . . 23
7.7. Write Locks and COPY/MOVE . . . . . . . . . . . . . . . 23
7.8. Refreshing Write Locks . . . . . . . . . . . . . . . . . 24
8. HTTP Methods for Distributed Authoring . . . . . . . . . . . 24
8.1. PROPFIND . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1.1. Example - Retrieving Named Properties . . . . . . . 26
8.1.2. Example - Using allprop to Retrieve All Properties . 28
8.1.3. Example - Using propname to Retrieve all Property
Names . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. PROPPATCH . . . . . . . . . . . . . . . . . . . . . . . 33
8.2.1. Status Codes for use with 207 (Multi-Status) . . . . 33
8.2.2. Example - PROPPATCH . . . . . . . . . . . . . . . . 34
8.3. MKCOL Method . . . . . . . . . . . . . . . . . . . . . . 35
8.3.1. Request . . . . . . . . . . . . . . . . . . . . . . 35
8.3.2. Status Codes . . . . . . . . . . . . . . . . . . . . 36
8.3.3. Example - MKCOL . . . . . . . . . . . . . . . . . . 36
8.4. GET, HEAD for Collections . . . . . . . . . . . . . . . 37
8.5. POST for Collections . . . . . . . . . . . . . . . . . . 37
8.6. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.6.1. DELETE for Non-Collection Resources . . . . . . . . 37
8.6.2. DELETE for Collections . . . . . . . . . . . . . . . 37
8.7. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.7.1. PUT for Non-Collection Resources . . . . . . . . . . 39
8.7.2. PUT for Collections . . . . . . . . . . . . . . . . 39
8.8. COPY Method . . . . . . . . . . . . . . . . . . . . . . 39
8.8.1. COPY for HTTP/1.1 resources . . . . . . . . . . . . 40
8.8.2. COPY for Properties . . . . . . . . . . . . . . . . 40
8.8.3. COPY for Collections . . . . . . . . . . . . . . . . 40
8.8.4. COPY and the Overwrite Header . . . . . . . . . . . 42
8.8.5. Status Codes . . . . . . . . . . . . . . . . . . . . 42
8.8.6. Example - COPY with Overwrite . . . . . . . . . . . 42
8.8.7. Example - COPY with No Overwrite . . . . . . . . . . 43
8.8.8. Example - COPY of a Collection . . . . . . . . . . . 43
8.9. MOVE Method . . . . . . . . . . . . . . . . . . . . . . 44
8.9.1. MOVE for Properties . . . . . . . . . . . . . . . . 45
8.9.2. MOVE for Collections . . . . . . . . . . . . . . . . 45
8.9.3. MOVE and the Overwrite Header . . . . . . . . . . . 46
8.9.4. Status Codes . . . . . . . . . . . . . . . . . . . . 46
8.9.5. Example - MOVE of a Non-Collection . . . . . . . . . 46
8.9.6. Example - MOVE of a Collection . . . . . . . . . . . 47
8.10. LOCK Method . . . . . . . . . . . . . . . . . . . . . . 48
8.10.1. Operation . . . . . . . . . . . . . . . . . . . . . 48
8.10.2. The Effect of Locks on Properties and Collections . 48
8.10.3. Locking Replicated Resources . . . . . . . . . . . . 49
8.10.4. Depth and Locking . . . . . . . . . . . . . . . . . 49
8.10.5. Interaction with other Methods . . . . . . . . . . . 49
8.10.6. Lock Compatibility Table . . . . . . . . . . . . . . 50
8.10.7. Status Codes . . . . . . . . . . . . . . . . . . . . 50
8.10.8. Example - Simple Lock Request . . . . . . . . . . . 51
8.10.9. Example - Refreshing a Write Lock . . . . . . . . . 53
8.10.10. Example - Multi-Resource Lock Request . . . . . . . 54
8.11. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . 55
8.11.1. Example - UNLOCK . . . . . . . . . . . . . . . . . . 55
9. HTTP Headers for Distributed Authoring . . . . . . . . . . . 56
9.1. DAV Header . . . . . . . . . . . . . . . . . . . . . . . 56
9.2. Depth Header . . . . . . . . . . . . . . . . . . . . . . 56
9.3. Destination Header . . . . . . . . . . . . . . . . . . . 57
9.4. If Header . . . . . . . . . . . . . . . . . . . . . . . 57
9.4.1. No-tag-list Production . . . . . . . . . . . . . . . 58
9.4.2. Tagged-list Production . . . . . . . . . . . . . . . 58
9.4.3. not Production . . . . . . . . . . . . . . . . . . . 59
9.4.4. Matching Function . . . . . . . . . . . . . . . . . 60
9.4.5. If Header and Non-DAV Compliant Proxies . . . . . . 60
9.5. Lock-Token Header . . . . . . . . . . . . . . . . . . . 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
9.6. Overwrite Header . . . . . . . . . . . . . . . . . . . . 60 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 10
9.7. Status-URI Response Header . . . . . . . . . . . . . . . 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.8. Timeout Request Header . . . . . . . . . . . . . . . . . 61 4. Data Model for Resource Properties . . . . . . . . . . . . . 13
10. Status Code Extensions to HTTP/1.1 . . . . . . . . . . . . . 62 4.1. The Resource Property Model . . . . . . . . . . . . . . 13
10.1. 102 Processing . . . . . . . . . . . . . . . . . . . . . 62 4.2. Properties and HTTP Headers . . . . . . . . . . . . . . 13
10.2. 207 Multi-Status . . . . . . . . . . . . . . . . . . . . 63 4.3. Property Values . . . . . . . . . . . . . . . . . . . . 13
10.3. 422 Unprocessable Entity . . . . . . . . . . . . . . . . 63 4.3.1. Example - Property with Mixed Content . . . . . . . 15
10.4. 423 Locked . . . . . . . . . . . . . . . . . . . . . . . 63 4.4. Property Names . . . . . . . . . . . . . . . . . . . . . 17
10.5. 424 Failed Dependency . . . . . . . . . . . . . . . . . 63 4.5. Source Resources and Output Resources . . . . . . . . . 17
10.6. 507 Insufficient Storage . . . . . . . . . . . . . . . . 63 5. Collections of Web Resources . . . . . . . . . . . . . . . . 18
11. Multi-Status Response . . . . . . . . . . . . . . . . . . . . 64 5.1. HTTP URL Namespace Model . . . . . . . . . . . . . . . . 18
12. XML Element Definitions . . . . . . . . . . . . . . . . . . . 64 5.2. Collection Resources . . . . . . . . . . . . . . . . . . 18
12.1. activelock XML Element . . . . . . . . . . . . . . . . . 64 6. Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1.1. depth XML Element . . . . . . . . . . . . . . . . . 64 6.1. Lock Model . . . . . . . . . . . . . . . . . . . . . . . 21
12.1.2. locktoken XML Element . . . . . . . . . . . . . . . 65 6.2. Exclusive Vs. Shared Locks . . . . . . . . . . . . . . . 22
12.1.3. timeout XML Element . . . . . . . . . . . . . . . . 65 6.3. Required Support . . . . . . . . . . . . . . . . . . . . 23
12.2. collection XML Element . . . . . . . . . . . . . . . . . 65 6.4. Lock Creator and Privileges . . . . . . . . . . . . . . 23
12.3. href XML Element . . . . . . . . . . . . . . . . . . . . 65 6.5. Lock Tokens . . . . . . . . . . . . . . . . . . . . . . 24
12.4. link XML Element . . . . . . . . . . . . . . . . . . . . 66 6.6. Lock Timeout . . . . . . . . . . . . . . . . . . . . . . 25
12.4.1. dst XML Element . . . . . . . . . . . . . . . . . . 66 6.7. Lock Capability Discovery . . . . . . . . . . . . . . . 25
12.4.2. src XML Element . . . . . . . . . . . . . . . . . . 66 6.8. Active Lock Discovery . . . . . . . . . . . . . . . . . 26
12.5. lockentry XML Element . . . . . . . . . . . . . . . . . 67 7. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.6. lockinfo XML Element . . . . . . . . . . . . . . . . . . 67 7.1. Write Locks and Properties . . . . . . . . . . . . . . . 27
12.7. lockscope XML Element . . . . . . . . . . . . . . . . . 67 7.2. Avoiding Lost Updates . . . . . . . . . . . . . . . . . 28
12.7.1. exclusive XML Element . . . . . . . . . . . . . . . 68 7.3. Write Locks and Unmapped URLs . . . . . . . . . . . . . 29
12.7.2. shared XML Element . . . . . . . . . . . . . . . . . 68 7.4. Write Locks and Collections . . . . . . . . . . . . . . 30
12.8. locktype XML Element . . . . . . . . . . . . . . . . . . 68 7.5. Write Locks and the If Request Header . . . . . . . . . 31
12.8.1. write XML Element . . . . . . . . . . . . . . . . . 68 7.5.1. Example - Write Lock and COPY . . . . . . . . . . . 32
12.9. multistatus XML Element . . . . . . . . . . . . . . . . 69 7.5.2. Example - Deleting a Member of a Locked Collection . 32
12.9.1. response XML Element . . . . . . . . . . . . . . . . 69 7.6. Write Locks and COPY/MOVE . . . . . . . . . . . . . . . 33
12.9.2. responsedescription XML Element . . . . . . . . . . 70 7.7. Refreshing Write Locks . . . . . . . . . . . . . . . . . 34
12.10. owner XML Element . . . . . . . . . . . . . . . . . . . 70 8. General Request and Response Handling . . . . . . . . . . . . 35
12.11. prop XML element . . . . . . . . . . . . . . . . . . . . 71 8.1. Precedence in Error Handling . . . . . . . . . . . . . . 35
12.12. propertybehavior XML element . . . . . . . . . . . . . . 71 8.2. Use of XML . . . . . . . . . . . . . . . . . . . . . . . 35
12.12.1. keepalive XML element . . . . . . . . . . . . . . . 71 8.3. URL Handling . . . . . . . . . . . . . . . . . . . . . . 36
12.12.2. omit XML element . . . . . . . . . . . . . . . . . . 72 8.3.1. Example - Correct URL Handling . . . . . . . . . . . 36
12.13. propertyupdate XML element . . . . . . . . . . . . . . . 72 8.4. Required Bodies in Requests . . . . . . . . . . . . . . 37
12.13.1. remove XML element . . . . . . . . . . . . . . . . . 73 8.5. HTTP Headers for use in WebDAV . . . . . . . . . . . . . 37
12.13.2. set XML element . . . . . . . . . . . . . . . . . . 73 8.6. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.14. propfind XML Element . . . . . . . . . . . . . . . . . . 74 8.7. Including Error Response Bodies . . . . . . . . . . . . 38
12.14.1. allprop XML Element . . . . . . . . . . . . . . . . 74 8.8. Impact of Namespace Operations on Cache Validators . . . 38
12.14.2. propname XML Element . . . . . . . . . . . . . . . . 74 9. HTTP Methods for Distributed Authoring . . . . . . . . . . . 40
13. DAV Properties . . . . . . . . . . . . . . . . . . . . . . . 74 9.1. PROPFIND Method . . . . . . . . . . . . . . . . . . . . 40
13.1. creationdate Property . . . . . . . . . . . . . . . . . 75 9.1.1. PROPFIND Status Codes . . . . . . . . . . . . . . . 41
13.2. displayname Property . . . . . . . . . . . . . . . . . . 75 9.1.2. Status Codes for Use in 'propstat' Element . . . . . 42
13.3. getcontentlanguage Property . . . . . . . . . . . . . . 75 9.1.3. Example - Retrieving Named Properties . . . . . . . 42
13.4. getcontentlength Property . . . . . . . . . . . . . . . 76 9.1.4. Example - Using 'propname' to Retrieve All
13.5. getcontenttype Property . . . . . . . . . . . . . . . . 76 Property Names . . . . . . . . . . . . . . . . . . . 44
13.6. getetag Property . . . . . . . . . . . . . . . . . . . . 76 9.1.5. Example - Using So-called 'allprop' . . . . . . . . 46
13.7. getlastmodified Property . . . . . . . . . . . . . . . . 77 9.1.6. Example - Using 'allprop' with 'include' . . . . . . 49
13.8. lockdiscovery Property . . . . . . . . . . . . . . . . . 77 9.2. PROPPATCH Method . . . . . . . . . . . . . . . . . . . . 49
13.8.1. Example - Retrieving the lockdiscovery Property . . 78 9.2.1. Status Codes for Use in 'propstat' Element . . . . . 50
13.9. resourcetype Property . . . . . . . . . . . . . . . . . 79 9.2.2. Example - PROPPATCH . . . . . . . . . . . . . . . . 51
13.10. source Property . . . . . . . . . . . . . . . . . . . . 80 9.3. MKCOL Method . . . . . . . . . . . . . . . . . . . . . . 52
13.10.1. Example - A source Property . . . . . . . . . . . . 80 9.3.1. MKCOL Status Codes . . . . . . . . . . . . . . . . . 53
13.11. supportedlock Property . . . . . . . . . . . . . . . . . 81 9.3.2. Example - MKCOL . . . . . . . . . . . . . . . . . . 53
13.11.1. Example - Retrieving the supportedlock Property . . 81 9.4. GET, HEAD for Collections . . . . . . . . . . . . . . . 54
14. Instructions for Processing XML in DAV . . . . . . . . . . . 82 9.5. POST for Collections . . . . . . . . . . . . . . . . . . 54
15. DAV Compliance Classes . . . . . . . . . . . . . . . . . . . 83 9.6. DELETE Requirements . . . . . . . . . . . . . . . . . . 54
15.1. Class 1 . . . . . . . . . . . . . . . . . . . . . . . . 83 9.6.1. DELETE for Collections . . . . . . . . . . . . . . . 55
15.2. Class 2 . . . . . . . . . . . . . . . . . . . . . . . . 83 9.6.2. Example - DELETE . . . . . . . . . . . . . . . . . . 56
16. Internationalization Considerations . . . . . . . . . . . . . 83 9.7. PUT Requirements . . . . . . . . . . . . . . . . . . . . 56
17. Security Considerations . . . . . . . . . . . . . . . . . . . 85 9.7.1. PUT for Non-Collection Resources . . . . . . . . . . 56
17.1. Authentication of Clients . . . . . . . . . . . . . . . 85 9.7.2. PUT for Collections . . . . . . . . . . . . . . . . 57
17.2. Denial of Service . . . . . . . . . . . . . . . . . . . 86 9.8. COPY Method . . . . . . . . . . . . . . . . . . . . . . 57
17.3. Security through Obscurity . . . . . . . . . . . . . . . 86 9.8.1. COPY for Non-collection Resources . . . . . . . . . 57
17.4. Privacy Issues Connected to Locks . . . . . . . . . . . 86 9.8.2. COPY for Properties . . . . . . . . . . . . . . . . 58
17.5. Privacy Issues Connected to Properties . . . . . . . . . 86 9.8.3. COPY for Collections . . . . . . . . . . . . . . . . 58
17.6. Reduction of Security due to Source Link . . . . . . . . 87 9.8.4. COPY and Overwriting Destination Resources . . . . . 59
17.7. Implications of XML External Entities . . . . . . . . . 87 9.8.5. Status Codes . . . . . . . . . . . . . . . . . . . . 60
17.8. Risks Connected with Lock Tokens . . . . . . . . . . . . 88 9.8.6. Example - COPY with Overwrite . . . . . . . . . . . 61
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88 9.8.7. Example - COPY with No Overwrite . . . . . . . . . . 61
19. Intellectual Property . . . . . . . . . . . . . . . . . . . . 89 9.8.8. Example - COPY of a Collection . . . . . . . . . . . 62
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 89 9.9. MOVE Method . . . . . . . . . . . . . . . . . . . . . . 63
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 9.9.1. MOVE for Properties . . . . . . . . . . . . . . . . 63
21.1. Normative References . . . . . . . . . . . . . . . . . . 90 9.9.2. MOVE for Collections . . . . . . . . . . . . . . . . 64
21.2. Informational References . . . . . . . . . . . . . . . . 91 9.9.3. MOVE and the Overwrite Header . . . . . . . . . . . 65
Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 92 9.9.4. Status Codes . . . . . . . . . . . . . . . . . . . . 65
A.1. Appendix 1 - WebDAV Document Type Definition . . . . . . 92 9.9.5. Example - MOVE of a Non-Collection . . . . . . . . . 66
A.2. Appendix 2 - ISO 8601 Date and Time Profile . . . . . . 94 9.9.6. Example - MOVE of a Collection . . . . . . . . . . . 66
A.3. Appendix 3 - Notes on Processing XML Elements . . . . . 94 9.10. LOCK Method . . . . . . . . . . . . . . . . . . . . . . 67
A.3.1. Notes on Empty XML Elements . . . . . . . . . . . . 94 9.10.1. Creating a Lock on an Existing Resource . . . . . . 67
A.3.2. Notes on Illegal XML Processing . . . . . . . . . . 95 9.10.2. Refreshing Locks . . . . . . . . . . . . . . . . . . 68
A.4. Appendix 4 -- XML Namespaces for WebDAV . . . . . . . . 97 9.10.3. Depth and Locking . . . . . . . . . . . . . . . . . 68
A.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 97 9.10.4. Locking Unmapped URLs . . . . . . . . . . . . . . . 69
A.4.2. Meaning of Qualified Names . . . . . . . . . . . . . 97 9.10.5. Lock Compatibility Table . . . . . . . . . . . . . . 69
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 9.10.6. LOCK Responses . . . . . . . . . . . . . . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 102 9.10.7. Example - Simple Lock Request . . . . . . . . . . . 71
Intellectual Property and Copyright Statements . . . . . . . . . 104 9.10.8. Example - Refreshing a Write Lock . . . . . . . . . 73
9.10.9. Example - Multi-Resource Lock Request . . . . . . . 74
9.11. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . 75
9.11.1. Status Codes . . . . . . . . . . . . . . . . . . . . 75
9.11.2. Example - UNLOCK . . . . . . . . . . . . . . . . . . 76
10. HTTP Headers for Distributed Authoring . . . . . . . . . . . 77
10.1. DAV Header . . . . . . . . . . . . . . . . . . . . . . . 77
10.2. Depth Header . . . . . . . . . . . . . . . . . . . . . . 78
10.3. Destination Header . . . . . . . . . . . . . . . . . . . 79
10.4. If Header . . . . . . . . . . . . . . . . . . . . . . . 79
10.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 79
10.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 80
10.4.3. List Evaluation . . . . . . . . . . . . . . . . . . 81
10.4.4. Matching State Tokens and ETags . . . . . . . . . . 81
10.4.5. If Header and Non-DAV Aware Proxies . . . . . . . . 82
10.4.6. Example - No-tag Production . . . . . . . . . . . . 82
10.4.7. Example - using "Not" with No-tag Production . . . . 82
10.4.8. Example - causing a Condition to always evaluate
to True . . . . . . . . . . . . . . . . . . . . . . 83
10.4.9. Example - Tagged List If header in COPY . . . . . . 83
10.4.10. Example - Matching lock tokens with collection
locks . . . . . . . . . . . . . . . . . . . . . . . 84
10.4.11. Example - Matching ETags on unmapped URLs . . . . . 84
10.5. Lock-Token Header . . . . . . . . . . . . . . . . . . . 84
10.6. Overwrite Header . . . . . . . . . . . . . . . . . . . . 85
10.7. Timeout Request Header . . . . . . . . . . . . . . . . . 85
11. Status Code Extensions to HTTP/1.1 . . . . . . . . . . . . . 86
11.1. 207 Multi-Status . . . . . . . . . . . . . . . . . . . . 86
11.2. 422 Unprocessable Entity . . . . . . . . . . . . . . . . 86
11.3. 423 Locked . . . . . . . . . . . . . . . . . . . . . . . 86
11.4. 424 Failed Dependency . . . . . . . . . . . . . . . . . 86
11.5. 507 Insufficient Storage . . . . . . . . . . . . . . . . 86
12. Use of HTTP Status Codes . . . . . . . . . . . . . . . . . . 87
12.1. 412 Precondition Failed . . . . . . . . . . . . . . . . 87
12.2. 414 Request-URI Too Long . . . . . . . . . . . . . . . . 87
13. Multi-Status Response . . . . . . . . . . . . . . . . . . . . 88
13.1. Response Headers . . . . . . . . . . . . . . . . . . . . 88
13.2. Handling Redirected Child Resources . . . . . . . . . . 89
13.3. Internal Status Codes . . . . . . . . . . . . . . . . . 89
14. XML Element Definitions . . . . . . . . . . . . . . . . . . . 90
14.1. activelock XML Element . . . . . . . . . . . . . . . . . 90
14.2. allprop XML Element . . . . . . . . . . . . . . . . . . 90
14.3. collection XML Element . . . . . . . . . . . . . . . . . 90
14.4. depth XML Element . . . . . . . . . . . . . . . . . . . 90
14.5. error XML Element . . . . . . . . . . . . . . . . . . . 91
14.6. exclusive XML Element . . . . . . . . . . . . . . . . . 91
14.7. href XML Element . . . . . . . . . . . . . . . . . . . . 91
14.8. include XML Element . . . . . . . . . . . . . . . . . . 92
14.9. location XML Element . . . . . . . . . . . . . . . . . . 92
14.10. lockentry XML Element . . . . . . . . . . . . . . . . . 92
14.11. lockinfo XML Element . . . . . . . . . . . . . . . . . . 93
14.12. lockroot XML Element . . . . . . . . . . . . . . . . . . 93
14.13. lockscope XML Element . . . . . . . . . . . . . . . . . 93
14.14. locktoken XML Element . . . . . . . . . . . . . . . . . 93
14.15. locktype XML Element . . . . . . . . . . . . . . . . . . 94
14.16. multistatus XML Element . . . . . . . . . . . . . . . . 94
14.17. owner XML Element . . . . . . . . . . . . . . . . . . . 94
14.18. prop XML Element . . . . . . . . . . . . . . . . . . . . 95
14.19. propertyupdate XML Element . . . . . . . . . . . . . . . 95
14.20. propfind XML Element . . . . . . . . . . . . . . . . . . 95
14.21. propname XML Element . . . . . . . . . . . . . . . . . . 95
14.22. propstat XML Element . . . . . . . . . . . . . . . . . . 96
14.23. remove XML Element . . . . . . . . . . . . . . . . . . . 96
14.24. response XML Element . . . . . . . . . . . . . . . . . . 96
14.25. responsedescription XML Element . . . . . . . . . . . . 97
14.26. set XML Element . . . . . . . . . . . . . . . . . . . . 97
14.27. shared XML Element . . . . . . . . . . . . . . . . . . . 97
14.28. status XML Element . . . . . . . . . . . . . . . . . . . 98
14.29. timeout XML Element . . . . . . . . . . . . . . . . . . 98
14.30. write XML Element . . . . . . . . . . . . . . . . . . . 98
15. DAV Properties . . . . . . . . . . . . . . . . . . . . . . . 99
15.1. creationdate Property . . . . . . . . . . . . . . . . . 99
15.2. displayname Property . . . . . . . . . . . . . . . . . . 100
15.3. getcontentlanguage Property . . . . . . . . . . . . . . 100
15.4. getcontentlength Property . . . . . . . . . . . . . . . 101
15.5. getcontenttype Property . . . . . . . . . . . . . . . . 101
15.6. getetag Property . . . . . . . . . . . . . . . . . . . . 102
15.7. getlastmodified Property . . . . . . . . . . . . . . . . 102
15.8. lockdiscovery Property . . . . . . . . . . . . . . . . . 103
15.8.1. Example - Retrieving DAV:lockdiscovery . . . . . . . 104
15.9. resourcetype Property . . . . . . . . . . . . . . . . . 105
15.10. supportedlock Property . . . . . . . . . . . . . . . . . 106
15.10.1. Example - Retrieving DAV:supportedlock . . . . . . . 107
16. Precondition/Postcondition XML Elements . . . . . . . . . . . 108
17. XML Extensibility in DAV . . . . . . . . . . . . . . . . . . 112
18. DAV Compliance Classes . . . . . . . . . . . . . . . . . . . 114
18.1. Class 1 . . . . . . . . . . . . . . . . . . . . . . . . 114
18.2. Class 2 . . . . . . . . . . . . . . . . . . . . . . . . 114
18.3. Class 3 . . . . . . . . . . . . . . . . . . . . . . . . 114
19. Internationalization Considerations . . . . . . . . . . . . . 116
20. Security Considerations . . . . . . . . . . . . . . . . . . . 118
20.1. Authentication of Clients . . . . . . . . . . . . . . . 118
20.2. Denial of Service . . . . . . . . . . . . . . . . . . . 118
20.3. Security through Obscurity . . . . . . . . . . . . . . . 119
20.4. Privacy Issues Connected to Locks . . . . . . . . . . . 119
20.5. Privacy Issues Connected to Properties . . . . . . . . . 119
20.6. Implications of XML Entities . . . . . . . . . . . . . . 120
20.7. Risks Connected with Lock Tokens . . . . . . . . . . . . 120
20.8. Hosting Malicious Content . . . . . . . . . . . . . . . 121
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122
21.1. New URI Schemes . . . . . . . . . . . . . . . . . . . . 122
21.2. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 122
21.3. Message Header Fields . . . . . . . . . . . . . . . . . 122
21.3.1. DAV . . . . . . . . . . . . . . . . . . . . . . . . 122
21.3.2. Depth . . . . . . . . . . . . . . . . . . . . . . . 122
21.3.3. Destination . . . . . . . . . . . . . . . . . . . . 123
21.3.4. If . . . . . . . . . . . . . . . . . . . . . . . . . 123
21.3.5. Lock-Token . . . . . . . . . . . . . . . . . . . . . 123
21.3.6. Overwrite . . . . . . . . . . . . . . . . . . . . . 123
21.3.7. Timeout . . . . . . . . . . . . . . . . . . . . . . 124
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 125
23. Contributors to This Specification . . . . . . . . . . . . . 127
24. Authors of RFC2518 . . . . . . . . . . . . . . . . . . . . . 128
25. References . . . . . . . . . . . . . . . . . . . . . . . . . 129
25.1. Normative References . . . . . . . . . . . . . . . . . . 129
25.2. Informational References . . . . . . . . . . . . . . . . 130
Appendix A. Notes on Processing XML Elements . . . . . . . . . . 131
A.1. Notes on Empty XML Elements . . . . . . . . . . . . . . 131
A.2. Notes on Illegal XML Processing . . . . . . . . . . . . 131
A.3. Example - XML Syntax Error . . . . . . . . . . . . . . . 131
A.4. Example - Unexpected XML Element . . . . . . . . . . . . 132
Appendix B. Notes on HTTP Client Compatibility . . . . . . . . . 134
Appendix C. The 'opaquelocktoken' Scheme and URIs . . . . . . . 135
Appendix D. Lock-null Resources . . . . . . . . . . . . . . . . 136
D.1. Guidance for Clients Using LOCK to Create Resources . . 136
Appendix E. Guidance for Clients Desiring to Authenticate . . . 138
Appendix F. Summary of changes from RFC2518 . . . . . . . . . . 140
F.1. Changes for both Client and Server Implementations . . . 140
F.2. Changes for Server Implementations . . . . . . . . . . . 141
F.3. Other Changes . . . . . . . . . . . . . . . . . . . . . 142
Appendix G. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 144
G.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . 144
G.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 144
G.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 145
G.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 146
G.5. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 147
G.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 147
G.7. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 147
G.8. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 148
G.9. Changes in -14 . . . . . . . . . . . . . . . . . . . . . 148
G.10. Changes in -15 . . . . . . . . . . . . . . . . . . . . . 148
G.11. Changes in -16 . . . . . . . . . . . . . . . . . . . . . 148
G.12. Changes in -17 . . . . . . . . . . . . . . . . . . . . . 149
G.13. Changes in -18 . . . . . . . . . . . . . . . . . . . . . 149
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 150
Intellectual Property and Copyright Statements . . . . . . . . . 151
1. Introduction 1. Introduction
This document describes an extension to the HTTP/1.1 protocol that This document describes an extension to the HTTP/1.1 protocol that
allows clients to perform remote web content authoring operations. allows clients to perform remote web content authoring operations.
This extension provides a coherent set of methods, headers, request This extension provides a coherent set of methods, headers, request
entity body formats, and response entity body formats that provide entity body formats, and response entity body formats that provide
operations for: operations for:
Properties: The ability to create, remove, and query information Properties: The ability to create, remove, and query information
about Web pages, such as their authors, creation dates, etc. Also, about Web pages, such as their authors, creation dates, etc.
the ability to link pages of any media type to related pages.
Collections: The ability to create sets of documents and to retrieve Collections: The ability to create sets of documents and to retrieve
a hierarchical membership listing (like a directory listing in a file a hierarchical membership listing (like a directory listing in a file
system). system).
Locking: The ability to keep more than one person from working on a Locking: The ability to keep more than one person from working on a
document at the same time. This prevents the "lost update problem," document at the same time. This prevents the "lost update problem",
in which modifications are lost as first one author then another in which modifications are lost as first one author then another
writes changes without merging the other author's changes. writes changes without merging the other author's changes.
Namespace Operations: The ability to instruct the server to copy and Namespace Operations: The ability to instruct the server to copy and
move Web resources. move Web resources, operations which change the mapping from URLs to
resources.
Requirements and rationale for these operations are described in a Requirements and rationale for these operations are described in a
companion document, "Requirements for a Distributed Authoring and companion document, "Requirements for a Distributed Authoring and
Versioning Protocol for the World Wide Web" [RFC2291]. Versioning Protocol for the World Wide Web" [RFC2291].
The sections below provide a detailed introduction to resource This document does not specify the versioning operations suggested by
properties (Section 4), collections of resources (Section 5), and [RFC2291]. That work was done in a separate document, "Versioning
locking operations (Section 6). These sections introduce the Extensions to WebDAV" [RFC3253].
abstractions manipulated by the WebDAV-specific HTTP methods
described in Section 8, "HTTP Methods for Distributed Authoring".
In HTTP/1.1, method parameter information was exclusively encoded in
HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter
information either in an Extensible Markup Language (XML) [REC-XML]
request entity body, or in an HTTP header. The use of XML to encode
method parameters was motivated by the ability to add extra XML
elements to existing structures, providing extensibility; and by
XML's ability to encode information in ISO 10646 character sets,
providing internationalization support. As a rule of thumb,
parameters are encoded in XML entity bodies when they have unbounded
length, or when they may be shown to a human user and hence require
encoding in an ISO 10646 character set. Otherwise, parameters are
encoded within HTTP headers. Section 9 describes the new HTTP
headers used with WebDAV methods.
In addition to encoding method parameters, XML is used in WebDAV to
encode the responses from methods, providing the extensibility and
internationalization advantages of XML for method output, as well as
input.
XML elements used in this specification are defined in Section 12. The sections below provide a detailed introduction to various WebDAV
abstractions: resource properties (Section 4), collections of
resources (Section 5), locks (Section 6) in general and write locks
(Section 7) specifically.
The XML namespace extension (Appendix A.4) is also used in this These abstractions are manipulated by the WebDAV-specific HTTP
specification in order to allow for new XML elements to be added methods (Section 9) and the extra HTTP headers (Section 10) used with
without fear of colliding with other element names. WebDAV methods. General considerations for handling HTTP requests
and responses in WebDAV are found in Section 8.
While the status codes provided by HTTP/1.1 are sufficient to While the status codes provided by HTTP/1.1 are sufficient to
describe most error conditions encountered by WebDAV methods, there describe most error conditions encountered by WebDAV methods, there
are some errors that do not fall neatly into the existing categories. are some errors that do not fall neatly into the existing categories.
New status codes developed for the WebDAV methods are defined in This specification defines extra status codes developed for WebDAV
Section 10. Since some WebDAV methods may operate over many methods (Section 11) and describes existing HTTP status codes
resources, the Multi-Status response has been introduced to return (Section 12) as used in WebDAV. Since some WebDAV methods may
status information for multiple resources. The Multi-Status response operate over many resources, the Multi-Status response (Section 13)
is described in Section 11. has been introduced to return status information for multiple
resources. Finally, this version of WebDAV introduces precondition
and postcondition (Section 16) XML elements in error response bodies.
WebDAV employs the property mechanism to store information about the WebDAV uses XML ([REC-XML]) for property names and some values, and
current state of the resource. For example, when a lock is taken out also uses XML to marshal complicated requests and responses. This
on a resource, a lock information property describes the current specification contains DTD and text definitions of all all properties
state of the lock. Section 13 defines the properties used within the (Section 15) and all other XML elements (Section 14) used in
WebDAV specification. marshalling. WebDAV includes a few special rules on extending
WebDAV XML marshalling in backwards-compatible ways (Section 17).
Finishing off the specification are sections on what it means to be Finishing off the specification are sections on what it means for a
compliant with this specification (Section 15), on resource to be compliant with this specification (Section 18), on
internationalization support (Section 16), and on security internationalization support (Section 19), and on security
(Section 17). (Section 20).
2. Notational Conventions 2. Notational Conventions
Since this document describes a set of extensions to the HTTP/1.1 Since this document describes a set of extensions to the HTTP/1.1
protocol, the augmented BNF used herein to describe protocol elements protocol, the augmented BNF used herein to describe protocol elements
is exactly the same as described in section 2.1 of [RFC2068]. Since is exactly the same as described in Section 2.1 of [RFC2616],
this augmented BNF uses the basic production rules provided in including the rules about implied linear white-space. Since this
section 2.2 of [RFC2068], these rules apply to this document as well. augmented BNF uses the basic production rules provided in Section 2.2
of [RFC2616], these rules apply to this document as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in [RFC2119].
Note that in natural language, a property like the "creationdate"
property in the "DAV:" XML namespace is sometimes referred to as
"DAV:creationdate" for brevity.
3. Terminology 3. Terminology
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, URI/URL - A Uniform Resource Identifier and Uniform Resource Locator,
respectively. These terms (and the distinction between them) are respectively. These terms (and the distinction between them) are
defined in [RFC2396]. defined in [RFC3986].
Collection - A resource that contains a set of URIs, termed member URI/URL Mapping - A relation between an absolute URI and a resource.
URIs, which identify member resources and meets the requirements in Since a resource can represent items that are not network
Section 5 of this specification. retrievable, as well as those that are, it is possible for a resource
to have zero, one, or many URI mappings. Mapping a resource to an
"http" scheme URI makes it possible to submit HTTP protocol requests
to the resource using the URI.
Member URI - A URI which is a member of the set of URIs contained by Path Segment - Informally, the characters found between slashes ("/")
a collection. in a URI. Formally, as defined in Section 3.3 of [RFC3986].
Internal Member URI - A Member URI that is immediately relative to Collection - Informally, a resource that also acts as a container of
the URI of the collection (the definition of immediately relative is references to child resources. Formally, a resource that contains a
given in Section 5.2). set of mappings between path segments and resources and meets the
requirements defined in Section 5.
Internal Member (of a Collection) - Informally, a child resource of a
collection. Formally, a resource referenced by a path segment
mapping contained in the collection.
Internal Member URL (of a Collection) - A URL of an internal member,
consisting of the URL of the collection (including trailing slash)
plus the path segment identifying the internal member.
Member (of a Collection) - Informally, a "descendant" of a
collection. Formally, an internal member of the collection, or,
recursively, a member of an internal member.
Member URL (of a Collection) - A URL that is either an internal
member URL of the collection itself, or is an internal member URL of
a member of that collection.
Property - A name/value pair that contains descriptive information Property - A name/value pair that contains descriptive information
about a resource. about a resource.
Live Property - A property whose semantics and syntax are enforced by Live Property - A property whose semantics and syntax are enforced by
the server. For example, the live "getcontentlength" property has the server. For example, the live property DAV:getcontentlength has
its value, the length of the entity returned by a GET request, its value, the length of the entity returned by a GET request,
automatically calculated by the server. automatically calculated by the server.
Dead Property - A property whose semantics and syntax are not Dead Property - A property whose semantics and syntax are not
enforced by the server. The server only records the value of a dead enforced by the server. The server only records the value of a dead
property; the client is responsible for maintaining the consistency property; the client is responsible for maintaining the consistency
of the syntax and semantics of a dead property. of the syntax and semantics of a dead property.
Null Resource - A resource which responds with a 404 (Not Found) to Principal - A "principal" is a distinct human or computational actor
any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK. that initiates access to network resources.
A NULL resource MUST NOT appear as a member of its parent collection.
State Token - A URI which represents a state of a resource. Lock
tokens are the only state tokens defined in this specification.
4. Data Model for Resource Properties 4. Data Model for Resource Properties
4.1. The Resource Property Model 4.1. The Resource Property Model
Properties are pieces of data that describe the state of a resource. Properties are pieces of data that describe the state of a resource.
Properties are data about data. Properties are data about data.
Properties are used in distributed authoring environments to provide Properties are used in distributed authoring environments to provide
for efficient discovery and management of resources. For example, a for efficient discovery and management of resources. For example, a
'subject' property might allow for the indexing of all resources by 'subject' property might allow for the indexing of all resources by
their subject, and an 'author' property might allow for the discovery their subject, and an 'author' property might allow for the discovery
of what authors have written which documents. of what authors have written which documents.
The DAV property model consists of name/value pairs. The name of a The DAV property model consists of name/value pairs. The name of a
property identifies the property's syntax and semantics, and provides property identifies the property's syntax and semantics, and provides
an address by which to refer to its syntax and semantics. an address by which to refer to its syntax and semantics.
There are two categories of properties: "live" and "dead". A live There are two categories of properties: "live" and "dead". A live
property has its syntax and semantics enforced by the server. Live property has its syntax and semantics enforced by the server. Live
properties include cases where a) the value of a property is read- properties include cases where a) the value of a property is
only, maintained by the server, and b) the value of the property is protected, maintained by the server, and b) the value of the property
maintained by the client, but the server performs syntax checking on is maintained by the client, but the server performs syntax checking
submitted values. All instances of a given live property MUST comply on submitted values. All instances of a given live property MUST
with the definition associated with that property name. A dead comply with the definition associated with that property name. A
property has its syntax and semantics enforced by the client; the dead property has its syntax and semantics enforced by the client;
server merely records the value of the property verbatim. the server merely records the value of the property verbatim.
4.2. Existing Metadata Proposals
Properties have long played an essential role in the maintenance of
large document repositories, and many current proposals contain some
notion of a property, or discuss web metadata more generally. These
include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several
proposals on representing relationships within HTML. Work on PICS-NG
and Web Collections has been subsumed by the Resource Description
Framework (RDF) metadata activity of the World Wide Web Consortium.
RDF consists of a network-based data model and an XML representation
of that model.
Some proposals come from a digital library perspective. These
include the Dublin Core [RFC2413] metadata set and the Warwick
Framework [WF], a container architecture for different metadata
schemas. The literature includes many examples of metadata,
including MARC [USMARC], a bibliographic metadata format, and a
technical report bibliographic format employed by the Dienst system
[RFC1807]. Additionally, the proceedings from the first IEEE
Metadata conference describe many community-specific metadata sets.
Participants of the 1996 Metadata II Workshop in Warwick, UK [WF],
noted that "new metadata sets will develop as the networked
infrastructure matures" and "different communities will propose,
design, and be responsible for different types of metadata." These
observations can be corroborated by noting that many community-
specific sets of metadata already exist, and there is significant
motivation for the development of new forms of metadata as many
communities increasingly make their data available in digital form,
requiring a metadata format to assist data location and cataloging.
4.3. Properties and HTTP Headers 4.2. Properties and HTTP Headers
Properties already exist, in a limited sense, in HTTP message Properties already exist, in a limited sense, in HTTP message
headers. However, in distributed authoring environments a relatively headers. However, in distributed authoring environments a relatively
large number of properties are needed to describe the state of a large number of properties are needed to describe the state of a
resource, and setting/returning them all through HTTP headers is resource, and setting/returning them all through HTTP headers is
inefficient. Thus a mechanism is needed which allows a principal to inefficient. Thus a mechanism is needed which allows a principal to
identify a set of properties in which the principal is interested and identify a set of properties in which the principal is interested and
to set or retrieve just those properties. to set or retrieve just those properties.
4.4. Property Values 4.3. Property Values
The value of a property when expressed in XML MUST be well formed. The value of a property is always a (well-formed) XML fragment.
XML has been chosen because it is a flexible, self-describing, XML has been chosen because it is a flexible, self-describing,
structured data format that supports rich schema definitions, and structured data format that supports rich schema definitions, and
because of its support for multiple character sets. XML's self- because of its support for multiple character sets. XML's self-
describing nature allows any property's value to be extended by describing nature allows any property's value to be extended by
adding new elements. Older clients will not break when they adding elements. Clients will not break when they encounter
encounter extensions because they will still have the data specified extensions because they will still have the data specified in the
in the original schema and will ignore elements they do not original schema and MUST ignore elements they do not understand.
understand. XML's support for multiple character sets allows any
human-readable property to be encoded and read in a character set
familiar to the user. XML's support for multiple human languages,
using the "xml:lang" attribute, handles cases where the same
character set is employed by multiple human languages.
4.5. Property Names XML's support for multiple character sets allows any human-readable
property to be encoded and read in a character set familiar to the
user. XML's support for multiple human languages, using the "xml:
lang" attribute, handles cases where the same character set is
employed by multiple human languages. Note that xml:lang scope is
recursive, so an xml:lang attribute on any element containing a
property name element applies to the property value unless it has
been overridden by a more locally scoped attribute. Note that a
property only has one value, in one language (or language MAY be left
undefined), not multiple values in different languages or a single
value in multiple languages.
A property is always represented with an XML element consisting of
the property name, called the "property name element". The simplest
example is an empty property, which is different from a property that
does not exist:
<R:title xmlns:R="http://www.example.com/ns/"></R:title>
The value of the property appears inside the property name element.
The value may be any kind of well-formed XML content, including both
text-only and mixed content. Servers MUST preserve the following XML
Information Items (using the terminology from [REC-XML-INFOSET]) in
storage and transmission of dead properties:
For the property name Element Information Item itself:
[namespace name]
[local name]
[attributes] named "xml:lang" or any such attribute in scope
[children] of type element or character
On all Element Information Items in the property value:
[namespace name]
[local name]
[attributes]
[children] of type element or character
On Attribute Information Items in the property value:
[namespace name]
[local name]
[normalized value]
On Character Information Items in the property value:
[character code]
Since prefixes are used in some XML vocabularies (XPath and XML
Schema, for example), servers SHOULD preserve, for any Information
Item in the value:
[prefix]
XML Infoset attributes not listed above MAY be preserved by the
server, but clients MUST NOT rely on them being preserved. The above
rules would also apply by default to live properties, unless defined
otherwise.
Servers MUST ignore the XML attribute xml:space if present and never
use it to change white space handling. White space in property
values is significant.
4.3.1. Example - Property with Mixed Content
Consider a dead property 'author' created by the client as follows:
<D:prop xml:lang="en" xmlns:D="DAV:">
<x:author xmlns:x='http://example.com/ns'>
<x:name>Jane Doe</x:name>
<!-- Jane's contact info -->
<x:uri type='email'
added='2005-11-26'>mailto:jane.doe@example.com</x:uri>
<x:uri type='web'
added='2005-11-27'>http://www.example.com</x:uri>
<x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <![CDATA[<RFC2518>]]>.
</x:notes>
</x:author>
</D:prop>
When this property is requested, a server might return:
<D:prop xmlns:D='DAV:'><author
xml:lang='en'
xmlns:x='http://example.com/ns'
xmlns='http://example.com/ns'
xmlns:h='http://www.w3.org/1999/xhtml'>
<x:name>Jane Doe</x:name>
<x:uri added="2005-11-26" type="email"
>mailto:jane.doe@example.com</x:uri>
<x:uri added="2005-11-27" type="web"
>http://www.example.com</x:uri>
<x:notes>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of &lt;RFC2518&gt;.
</x:notes>
</author>
</D:prop>
Note in this example:
o The [prefix] for the property name itself was not preserved, being
non-significant, all other [prefix] values have been preserved,
o attribute values have been rewritten with double quotes instead of
single quotes (quoting style is not significant), and attribute
order has not been preserved,
o the xml:lang attribute has been returned on the property name
element itself (it was in scope when the property was set, but the
exact position in the response is not considered significant as
long as it is in scope),
o whitespace between tags has been preserved everywhere (whitespace
between attributes not so),
o CDATA encapsulation was replaced with character escaping (the
reverse would also be legal),
o the comment item was stripped (as would have been a processing
instruction item).
Implementation note: there are cases such as editing scenarios where
clients may require that XML content is preserved character-by-
character (such as attribute ordering or quoting style). In this
case, clients should consider using a text-only property value by
escaping all characters that have a special meaning in XML parsing.
4.4. Property Names
A property name is a universally unique identifier that is associated A property name is a universally unique identifier that is associated
with a schema that provides information about the syntax and with a schema that provides information about the syntax and
semantics of the property. semantics of the property.
Because a property's name is universally unique, clients can depend Because a property's name is universally unique, clients can depend
upon consistent behavior for a particular property across multiple upon consistent behavior for a particular property across multiple
resources, on the same and across different servers, so long as that resources, on the same and across different servers, so long as that
property is "live" on the resources in question, and the property is "live" on the resources in question, and the
implementation of the live property is faithful to its definition. implementation of the live property is faithful to its definition.
The XML namespace mechanism, which is based on URIs [RFC2396], is The XML namespace mechanism, which is based on URIs ([RFC3986]), is
used to name properties because it prevents namespace collisions and used to name properties because it prevents namespace collisions and
provides for varying degrees of administrative control. provides for varying degrees of administrative control.
The property namespace is flat; that is, no hierarchy of properties The property namespace is flat; that is, no hierarchy of properties
is explicitly recognized. Thus, if a property A and a property A/B is explicitly recognized. Thus, if a property A and a property A/B
exist on a resource, there is no recognition of any relationship exist on a resource, there is no recognition of any relationship
between the two properties. It is expected that a separate between the two properties. It is expected that a separate
specification will eventually be produced which will address issues specification will eventually be produced which will address issues
relating to hierarchical properties. relating to hierarchical properties.
Finally, it is not possible to define the same property twice on a Finally, it is not possible to define the same property twice on a
single resource, as this would cause a collision in the resource's single resource, as this would cause a collision in the resource's
property namespace. property namespace.
4.6. Media Independent Links 4.5. Source Resources and Output Resources
Although HTML resources support links to other resources, the Web Some HTTP resources are dynamically generated by the server. For
needs more general support for links between resources of any media these resources, there presumably exists source code somewhere
type (media types are also known as MIME types, or content types). governing how that resource is generated. The relationship of source
WebDAV provides such links. A WebDAV link is a special type of files to output HTTP resources may be one to one, one to many, many
property value, formally defined in Section 12.4, that allows typed to one or many to many. There is no mechanism in HTTP to determine
connections to be established between resources of any media type. whether a resource is even dynamic, let alone where its source files
The property value consists of source and destination Uniform exist or how to author them. Although this problem would usefully be
Resource Identifiers (URIs); the property name identifies the link solved, interoperable WebDAV implementations have been widely
type. deployed without actually solving this problem, by dealing only with
static resources. Thus, the source vs. output problem is not solved
in this specification and has been deferred to a separate document.
5. Collections of Web Resources 5. Collections of Web Resources
This section provides a description of a new type of Web resource, This section provides a description of a type of Web resource, the
the collection, and discusses its interactions with the HTTP URL collection, and discusses its interactions with the HTTP URL
namespace. The purpose of a collection resource is to model namespace and with HTTP methods. The purpose of a collection
collection-like objects (e.g., file system directories) within a resource is to model collection-like objects (e.g., file system
server's namespace. directories) within a server's namespace.
All DAV compliant resources MUST support the HTTP URL namespace model All DAV compliant resources MUST support the HTTP URL namespace model
specified herein. specified herein.
5.1. HTTP URL Namespace Model 5.1. HTTP URL Namespace Model
The HTTP URL namespace is a hierarchical namespace where the The HTTP URL namespace is a hierarchical namespace where the
hierarchy is delimited with the "/" character. hierarchy is delimited with the "/" character.
An HTTP URL namespace is said to be consistent if it meets the An HTTP URL namespace is said to be consistent if it meets the
following conditions: for every URL in the HTTP hierarchy there following conditions: for every URL in the HTTP hierarchy there
exists a collection that contains that URL as an internal member. exists a collection that contains that URL as an internal member URL.
The root, or top-level collection of the namespace under The root, or top-level collection of the namespace under
consideration is exempt from the previous rule. consideration, is exempt from the previous rule. The top-level
collection of the namespace under consideration is not necessarily
the collection identified by the absolute path '/', it may be
identified by one or more path segments (e.g. /servlets/webdav/...)
Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL
namespace be consistent. However, certain WebDAV methods are namespace be consistent -- a WebDAV-compatible resource may not have
prohibited from producing results that cause namespace a parent collection. However, certain WebDAV methods are prohibited
inconsistencies. from producing results that cause namespace inconsistencies.
Although implicit in [RFC2068] and [RFC2396], any resource, including As is implicit in [RFC2616] and [RFC3986], any resource, including
collection resources, MAY be identified by more than one URI. For collection resources, MAY be identified by more than one URI. For
example, a resource could be identified by multiple HTTP URLs. example, a resource could be identified by multiple HTTP URLs.
5.2. Collection Resources 5.2. Collection Resources
A collection is a resource whose state consists of at least a list of Collection resources differ from other resources in that they also
internal member URIs and a set of properties, but which may have act as containers. Some HTTP methods apply only to a collection, but
additional state such as entity bodies returned by GET. An internal some apply to some or all of the resources inside the container
member URI MUST be immediately relative to a base URI of the defined by the collection. When the scope of a method is not clear,
collection. That is, the internal member URI is equal to a the client can specify what depth to apply. Depth can be either zero
containing collection's URI plus an additional segment for non- levels in (only the collection), one level (the collection and
collection resources, or additional segment plus trailing slash "/" directly contained resources) or infinite levels (the collection and
for collection resources, where segment is defined in section 3.3 of all contained resources recursively).
[RFC2396].
Any given internal member URI MUST only belong to the collection
once, i.e., it is illegal to have multiple instances of the same URI
in a collection. Properties defined on collections behave exactly as
do properties on non-collection resources.
For all WebDAV compliant resources A and B, identified by URIs U and
V, for which U is immediately relative to V, B MUST be a collection
that has U as an internal member URI. So, if the resource with URL
http://foo.com/bar/blah is WebDAV compliant and if the resource with
URL http://foo.com/bar/ is WebDAV compliant then the resource with
URL http://foo.com/bar/ must be a collection and must contain URL
http://foo.com/bar/blah as an internal member.
Collection resources MAY list the URLs of non-WebDAV compliant
children in the HTTP URL namespace hierarchy as internal members but
are not required to do so. For example, if the resource with URL
http://foo.com/bar/blah is not WebDAV compliant and the URL
http://foo.com/bar/ identifies a collection then URL
http://foo.com/bar/blah may or may not be an internal member of the
collection with URL http://foo.com/bar/.
If a WebDAV compliant resource has no WebDAV compliant children in
the HTTP URL namespace hierarchy then the WebDAV compliant resource
is not required to be a collection.
There is a standing convention that when a collection is referred to
by its name without a trailing slash, the trailing slash is
automatically appended. Due to this, a resource may accept a URI
without a trailing "/" to point to a collection. In this case it
SHOULD return a content-location header in the response pointing to
the URI ending with the "/". For example, if a client invokes a
method on http://foo.bar/blah (no trailing slash), the resource
http://foo.bar/blah/ (trailing slash) may respond as if the operation
were invoked on it, and should return a content-location header with
http://foo.bar/blah/ in it. In general clients SHOULD use the "/"
form of collection names.
A resource MAY be a collection but not be WebDAV compliant. That is,
the resource may comply with all the rules set out in this
specification regarding how a collection is to behave without
necessarily supporting all methods that a WebDAV compliant resource
is required to support. In such a case the resource may return the
DAV:resourcetype property with the value DAV:collection but MUST NOT
return a DAV header containing the value "1" on an OPTIONS response.
5.3. Creation and Retrieval of Collection Resources
This document specifies the MKCOL method to create new collection A collection's state consists of at least a set of mappings between
resources, rather than using the existing HTTP/1.1 PUT or POST path segments and resources, and a set of properties on the
method, for the following reasons: collection itself. In this document, a resource B will be said to be
contained in the collection resource A if there is a path segment
mapping which maps to B and which is contained in A. A collection
MUST contain at most one mapping for a given path segment, i.e., it
is illegal to have the same path segment mapped to more than one
resource.
 End of changes. 44 change blocks. 
394 lines changed or deleted 541 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/