draft-ietf-webdav-rfc2518bis-latest.txt   draft-reschke-webdav-rfc2518bis-latest.txt 
WebDAV Working Group L. Dusseault, Ed. WebDAV L. Dusseault, Ed.
Internet-Draft CommerceNet Internet-Draft CommerceNet
Obsoletes: 2518 (if approved) February 15, 2007 Obsoletes: 2518 (if approved) April 2008
Updates: 3253 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: August 19, 2007 Expires: October 3, 2008
HTTP Extensions for Distributed Authoring - WebDAV HTTP Extensions for Distributed Authoring - WebDAV
draft-ietf-webdav-rfc2518bis-18 draft-reschke-webdav-rfc2518bis-latest
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 19, 2007. This Internet-Draft will expire on October 3, 2008.
Abstract Abstract
WebDAV consists of 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, URL namespace creation and management of resource collections, URL namespace
manipulation, and resource locking (collision avoidance). manipulation, and resource locking (collision avoidance).
RFC2518 was published in February 1999, and this specification makes RFC2518 was published in February 1999, and this specification makes
minor revisions mostly due to interoperability experience. minor revisions mostly due to interoperability experience.
Status
This is an experimental edit of the WebDAV working group's draft (as
of 2007-02-15), see Appendix G.14 for details. All changes have been
made by Julian Reschke; if a problem was introduced by these changes,
please blame Julian Reschke
(<mailto:julian.reschke@greenbytes.de?subject=rfc2518bis>) and not
the authors of the working group draft. A diff to the latest WG
draft can be found at
<http://greenbytes.de/tech/webdav/draft-reschke-from-ietf.diff.html>.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 10 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 11
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Data Model for Resource Properties . . . . . . . . . . . . . 13 4. Data Model for Resource Properties . . . . . . . . . . . . . 14
4.1. The Resource Property Model . . . . . . . . . . . . . . 13 4.1. The Resource Property Model . . . . . . . . . . . . . . 14
4.2. Properties and HTTP Headers . . . . . . . . . . . . . . 13 4.2. Properties and HTTP Headers . . . . . . . . . . . . . . 14
4.3. Property Values . . . . . . . . . . . . . . . . . . . . 13 4.3. Property Values . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Example - Property with Mixed Content . . . . . . . 15 4.3.1. Example - Property with Mixed Content . . . . . . . 16
4.4. Property Names . . . . . . . . . . . . . . . . . . . . . 17 4.4. Property Names . . . . . . . . . . . . . . . . . . . . . 18
4.5. Source Resources and Output Resources . . . . . . . . . 17 4.5. Source Resources and Output Resources . . . . . . . . . 18
5. Collections of Web Resources . . . . . . . . . . . . . . . . 18 5. Collections of Web Resources . . . . . . . . . . . . . . . . 19
5.1. HTTP URL Namespace Model . . . . . . . . . . . . . . . . 18 5.1. HTTP URL Namespace Model . . . . . . . . . . . . . . . . 19
5.2. Collection Resources . . . . . . . . . . . . . . . . . . 18 5.2. Collection Resources . . . . . . . . . . . . . . . . . . 19
6. Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.1. Example - non WebDAV-compliant Resource in
6.1. Lock Model . . . . . . . . . . . . . . . . . . . . . . . 21 Collection . . . . . . . . . . . . . . . . . . . . . 21
6.2. Exclusive Vs. Shared Locks . . . . . . . . . . . . . . . 22 5.2.2. Example - URL of WebDAV-compliant Resource not
6.3. Required Support . . . . . . . . . . . . . . . . . . . . 23 appearing in Parent Collection . . . . . . . . . . . 21
6.4. Lock Creator and Privileges . . . . . . . . . . . . . . 23 6. Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.5. Lock Tokens . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Lock Model . . . . . . . . . . . . . . . . . . . . . . . 22
6.6. Lock Timeout . . . . . . . . . . . . . . . . . . . . . . 25 6.2. Exclusive Vs. Shared Locks . . . . . . . . . . . . . . . 23
6.7. Lock Capability Discovery . . . . . . . . . . . . . . . 25 6.3. Required Support . . . . . . . . . . . . . . . . . . . . 24
6.8. Active Lock Discovery . . . . . . . . . . . . . . . . . 26 6.4. Lock Creator and Privileges . . . . . . . . . . . . . . 24
7. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.5. Lock Tokens . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Write Locks and Properties . . . . . . . . . . . . . . . 27 6.6. Lock Timeout . . . . . . . . . . . . . . . . . . . . . . 26
7.2. Avoiding Lost Updates . . . . . . . . . . . . . . . . . 28 6.7. Lock Capability Discovery . . . . . . . . . . . . . . . 26
7.3. Write Locks and Unmapped URLs . . . . . . . . . . . . . 29 6.8. Active Lock Discovery . . . . . . . . . . . . . . . . . 27
6.9. Locks and Multiple Bindings . . . . . . . . . . . . . . 27
7. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Write Locks and Properties . . . . . . . . . . . . . . . 29
7.2. Avoiding Lost Updates . . . . . . . . . . . . . . . . . 29
7.3. Write Locks and Unmapped URLs . . . . . . . . . . . . . 30
7.4. Write Locks and Collections . . . . . . . . . . . . . . 30 7.4. Write Locks and Collections . . . . . . . . . . . . . . 30
7.5. Write Locks and the If Request Header . . . . . . . . . 31 7.5. Write Locks and the If Request Header . . . . . . . . . 32
7.5.1. Example - Write Lock and COPY . . . . . . . . . . . 32 7.5.1. Example - Write Lock and COPY . . . . . . . . . . . 33
7.5.2. Example - Deleting a Member of a Locked Collection . 32 7.5.2. Example - Deleting a Member of a Locked Collection . 33
7.6. Write Locks and COPY/MOVE . . . . . . . . . . . . . . . 33 7.6. Write Locks and COPY/MOVE . . . . . . . . . . . . . . . 34
7.7. Refreshing Write Locks . . . . . . . . . . . . . . . . . 34 7.7. Refreshing Write Locks . . . . . . . . . . . . . . . . . 34
8. General Request and Response Handling . . . . . . . . . . . . 35 8. General Request and Response Handling . . . . . . . . . . . . 36
8.1. Precedence in Error Handling . . . . . . . . . . . . . . 35 8.1. Precedence in Error Handling . . . . . . . . . . . . . . 36
8.2. Use of XML . . . . . . . . . . . . . . . . . . . . . . . 35 8.2. Use of XML . . . . . . . . . . . . . . . . . . . . . . . 36
8.3. URL Handling . . . . . . . . . . . . . . . . . . . . . . 36 8.3. URL Handling . . . . . . . . . . . . . . . . . . . . . . 37
8.3.1. Example - Correct URL Handling . . . . . . . . . . . 36 8.3.1. Example - Correct URL Handling . . . . . . . . . . . 37
8.4. Required Bodies in Requests . . . . . . . . . . . . . . 37 8.4. Required Bodies in Requests . . . . . . . . . . . . . . 38
8.5. HTTP Headers for use in WebDAV . . . . . . . . . . . . . 37 8.5. HTTP Headers for use in WebDAV . . . . . . . . . . . . . 38
8.6. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.6. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.7. Including Error Response Bodies . . . . . . . . . . . . 38 8.7. Including Error Response Bodies . . . . . . . . . . . . 39
8.8. Impact of Namespace Operations on Cache Validators . . . 38 8.8. Impact of Namespace Operations on Cache Validators . . . 39
9. HTTP Methods for Distributed Authoring . . . . . . . . . . . 40 9. HTTP Methods for Distributed Authoring . . . . . . . . . . . 41
9.1. PROPFIND Method . . . . . . . . . . . . . . . . . . . . 40 9.1. PROPFIND Method . . . . . . . . . . . . . . . . . . . . 41
9.1.1. PROPFIND Status Codes . . . . . . . . . . . . . . . 41 9.1.1. PROPFIND Status Codes . . . . . . . . . . . . . . . 42
9.1.2. Status Codes for Use in 'propstat' Element . . . . . 42 9.1.2. Status Codes for Use in 'propstat' Element . . . . . 43
9.1.3. Example - Retrieving Named Properties . . . . . . . 42 9.1.3. Example - Retrieving Named Properties . . . . . . . 43
9.1.4. Example - Using 'propname' to Retrieve All 9.1.4. Example - Using 'propname' to Retrieve All
Property Names . . . . . . . . . . . . . . . . . . . 44 Property Names . . . . . . . . . . . . . . . . . . . 45
9.1.5. Example - Using So-called 'allprop' . . . . . . . . 46 9.1.5. Example - Using So-called 'allprop' . . . . . . . . 47
9.1.6. Example - Using 'allprop' with 'include' . . . . . . 49 9.1.6. Example - Using 'allprop' with 'include' . . . . . . 50
9.2. PROPPATCH Method . . . . . . . . . . . . . . . . . . . . 49 9.2. PROPPATCH Method . . . . . . . . . . . . . . . . . . . . 50
9.2.1. Status Codes for Use in 'propstat' Element . . . . . 50 9.2.1. Status Codes for Use in 'propstat' Element . . . . . 51
9.2.2. Example - PROPPATCH . . . . . . . . . . . . . . . . 51 9.2.2. Example - PROPPATCH . . . . . . . . . . . . . . . . 52
9.3. MKCOL Method . . . . . . . . . . . . . . . . . . . . . . 52 9.3. MKCOL Method . . . . . . . . . . . . . . . . . . . . . . 53
9.3.1. MKCOL Status Codes . . . . . . . . . . . . . . . . . 53 9.3.1. MKCOL Status Codes . . . . . . . . . . . . . . . . . 54
9.3.2. Example - MKCOL . . . . . . . . . . . . . . . . . . 53 9.3.2. Example - MKCOL . . . . . . . . . . . . . . . . . . 54
9.4. GET, HEAD for Collections . . . . . . . . . . . . . . . 54 9.4. GET, HEAD for Collections . . . . . . . . . . . . . . . 55
9.5. POST for Collections . . . . . . . . . . . . . . . . . . 54 9.5. POST for Collections . . . . . . . . . . . . . . . . . . 55
9.6. DELETE Requirements . . . . . . . . . . . . . . . . . . 54 9.6. DELETE Requirements . . . . . . . . . . . . . . . . . . 55
9.6.1. DELETE for Collections . . . . . . . . . . . . . . . 55 9.6.1. DELETE for Collections . . . . . . . . . . . . . . . 56
9.6.2. Example - DELETE . . . . . . . . . . . . . . . . . . 55 9.6.2. Example - DELETE . . . . . . . . . . . . . . . . . . 56
9.7. PUT Requirements . . . . . . . . . . . . . . . . . . . . 56 9.7. PUT Requirements . . . . . . . . . . . . . . . . . . . . 57
9.7.1. PUT for Non-Collection Resources . . . . . . . . . . 56 9.7.1. PUT for Non-Collection Resources . . . . . . . . . . 57
9.7.2. PUT for Collections . . . . . . . . . . . . . . . . 57 9.7.2. PUT for Collections . . . . . . . . . . . . . . . . 58
9.8. COPY Method . . . . . . . . . . . . . . . . . . . . . . 57 9.8. COPY Method . . . . . . . . . . . . . . . . . . . . . . 58
9.8.1. COPY for Non-collection Resources . . . . . . . . . 57 9.8.1. COPY for Non-collection Resources . . . . . . . . . 58
9.8.2. COPY for Properties . . . . . . . . . . . . . . . . 58 9.8.2. COPY for Properties . . . . . . . . . . . . . . . . 59
9.8.3. COPY for Collections . . . . . . . . . . . . . . . . 58 9.8.3. COPY for Collections . . . . . . . . . . . . . . . . 59
9.8.4. COPY and Overwriting Destination Resources . . . . . 59 9.8.4. COPY and Overwriting Destination Resources . . . . . 60
9.8.5. Status Codes . . . . . . . . . . . . . . . . . . . . 60 9.8.5. Status Codes . . . . . . . . . . . . . . . . . . . . 61
9.8.6. Example - COPY with Overwrite . . . . . . . . . . . 61 9.8.6. Example - COPY with Overwrite . . . . . . . . . . . 62
9.8.7. Example - COPY with No Overwrite . . . . . . . . . . 61 9.8.7. Example - COPY with No Overwrite . . . . . . . . . . 62
9.8.8. Example - COPY of a Collection . . . . . . . . . . . 62 9.8.8. Example - COPY of a Collection . . . . . . . . . . . 63
9.9. MOVE Method . . . . . . . . . . . . . . . . . . . . . . 62 9.9. MOVE Method . . . . . . . . . . . . . . . . . . . . . . 63
9.9.1. MOVE for Properties . . . . . . . . . . . . . . . . 63 9.9.1. MOVE for Properties . . . . . . . . . . . . . . . . 64
9.9.2. MOVE for Collections . . . . . . . . . . . . . . . . 63 9.9.2. MOVE for Collections . . . . . . . . . . . . . . . . 64
9.9.3. MOVE and the Overwrite Header . . . . . . . . . . . 64 9.9.3. MOVE and the Overwrite Header . . . . . . . . . . . 65
9.9.4. Status Codes . . . . . . . . . . . . . . . . . . . . 64 9.9.4. Status Codes . . . . . . . . . . . . . . . . . . . . 65
9.9.5. Example - MOVE of a Non-Collection . . . . . . . . . 65 9.9.5. Example - MOVE of a Non-Collection . . . . . . . . . 66
9.9.6. Example - MOVE of a Collection . . . . . . . . . . . 66 9.9.6. Example - MOVE of a Collection . . . . . . . . . . . 67
9.10. LOCK Method . . . . . . . . . . . . . . . . . . . . . . 67 9.10. LOCK Method . . . . . . . . . . . . . . . . . . . . . . 68
9.10.1. Creating a Lock on an Existing Resource . . . . . . 67 9.10.1. Creating a Lock on an Existing Resource . . . . . . 68
9.10.2. Refreshing Locks . . . . . . . . . . . . . . . . . . 67 9.10.2. Refreshing Locks . . . . . . . . . . . . . . . . . . 68
9.10.3. Depth and Locking . . . . . . . . . . . . . . . . . 68 9.10.3. Depth and Locking . . . . . . . . . . . . . . . . . 69
9.10.4. Locking Unmapped URLs . . . . . . . . . . . . . . . 68 9.10.4. Locking Unmapped URLs . . . . . . . . . . . . . . . 69
9.10.5. Lock Compatibility Table . . . . . . . . . . . . . . 69 9.10.5. Lock Compatibility Table . . . . . . . . . . . . . . 69
9.10.6. LOCK Responses . . . . . . . . . . . . . . . . . . . 69 9.10.6. LOCK Responses . . . . . . . . . . . . . . . . . . . 70
9.10.7. Example - Simple Lock Request . . . . . . . . . . . 70 9.10.7. Example - Simple Lock Request . . . . . . . . . . . 71
9.10.8. Example - Refreshing a Write Lock . . . . . . . . . 72 9.10.8. Example - Refreshing a Write Lock . . . . . . . . . 73
9.10.9. Example - Multi-Resource Lock Request . . . . . . . 73 9.10.9. Example - Multi-Resource Lock Request . . . . . . . 74
9.11. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . 74 9.11. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . 75
9.11.1. Status Codes . . . . . . . . . . . . . . . . . . . . 74 9.11.1. Status Codes . . . . . . . . . . . . . . . . . . . . 75
9.11.2. Example - UNLOCK . . . . . . . . . . . . . . . . . . 75 9.11.2. Example - UNLOCK . . . . . . . . . . . . . . . . . . 76
10. HTTP Headers for Distributed Authoring . . . . . . . . . . . 76 10. HTTP Headers for Distributed Authoring . . . . . . . . . . . 77
10.1. DAV Header . . . . . . . . . . . . . . . . . . . . . . . 76 10.1. DAV Header . . . . . . . . . . . . . . . . . . . . . . . 77
10.2. Depth Header . . . . . . . . . . . . . . . . . . . . . . 77 10.2. Depth Header . . . . . . . . . . . . . . . . . . . . . . 78
10.3. Destination Header . . . . . . . . . . . . . . . . . . . 78 10.3. Destination Header . . . . . . . . . . . . . . . . . . . 79
10.4. If Header . . . . . . . . . . . . . . . . . . . . . . . 78 10.4. If Header . . . . . . . . . . . . . . . . . . . . . . . 79
10.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 78 10.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 79
10.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 79 10.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 80
10.4.3. List Evaluation . . . . . . . . . . . . . . . . . . 80 10.4.3. Evaluation . . . . . . . . . . . . . . . . . . . . . 80
10.4.4. Matching State Tokens and ETags . . . . . . . . . . 80 10.4.4. Matching State Tokens and ETags . . . . . . . . . . 81
10.4.5. If Header and Non-DAV Aware Proxies . . . . . . . . 81 10.4.5. If Header and Non-DAV Aware Proxies . . . . . . . . 81
10.4.6. Example - No-tag Production . . . . . . . . . . . . 81 10.4.6. Example - No-tag Production . . . . . . . . . . . . 82
10.4.7. Example - using "Not" with No-tag Production . . . . 81 10.4.7. Example - using "Not" with No-tag Production . . . . 82
10.4.8. Example - causing a Condition to always evaluate 10.4.8. Example - causing a Condition to always evaluate
to True . . . . . . . . . . . . . . . . . . . . . . 82 to True . . . . . . . . . . . . . . . . . . . . . . 82
10.4.9. Example - Tagged List If header in COPY . . . . . . 82 10.4.9. Example - Tagged List If header in COPY . . . . . . 83
10.4.10. Example - Matching lock tokens with collection 10.4.10. Example - Matching lock tokens with collection
locks . . . . . . . . . . . . . . . . . . . . . . . 82 locks . . . . . . . . . . . . . . . . . . . . . . . 83
10.4.11. Example - Matching ETags on unmapped URLs . . . . . 83 10.4.11. Example - Matching ETags on unmapped URLs . . . . . 84
10.5. Lock-Token Header . . . . . . . . . . . . . . . . . . . 83 10.5. Lock-Token Header . . . . . . . . . . . . . . . . . . . 84
10.6. Overwrite Header . . . . . . . . . . . . . . . . . . . . 83 10.6. Overwrite Header . . . . . . . . . . . . . . . . . . . . 84
10.7. Timeout Request Header . . . . . . . . . . . . . . . . . 84 10.7. Timeout Request Header . . . . . . . . . . . . . . . . . 85
11. Status Code Extensions to HTTP/1.1 . . . . . . . . . . . . . 85 11. Status Code Extensions to HTTP/1.1 . . . . . . . . . . . . . 86
11.1. 207 Multi-Status . . . . . . . . . . . . . . . . . . . . 85 11.1. 207 Multi-Status . . . . . . . . . . . . . . . . . . . . 86
11.2. 422 Unprocessable Entity . . . . . . . . . . . . . . . . 85 11.2. 422 Unprocessable Entity . . . . . . . . . . . . . . . . 86
11.3. 423 Locked . . . . . . . . . . . . . . . . . . . . . . . 85 11.3. 423 Locked . . . . . . . . . . . . . . . . . . . . . . . 86
11.4. 424 Failed Dependency . . . . . . . . . . . . . . . . . 85 11.4. 424 Failed Dependency . . . . . . . . . . . . . . . . . 86
11.5. 507 Insufficient Storage . . . . . . . . . . . . . . . . 85 11.5. 507 Insufficient Storage . . . . . . . . . . . . . . . . 86
12. Use of HTTP Status Codes . . . . . . . . . . . . . . . . . . 86 12. Use of HTTP Status Codes . . . . . . . . . . . . . . . . . . 87
12.1. 412 Precondition Failed . . . . . . . . . . . . . . . . 86 12.1. 412 Precondition Failed . . . . . . . . . . . . . . . . 87
12.2. 414 Request-URI Too Long . . . . . . . . . . . . . . . . 86 13. Multi-Status Response . . . . . . . . . . . . . . . . . . . . 88
13. Multi-Status Response . . . . . . . . . . . . . . . . . . . . 87 13.1. Response Headers . . . . . . . . . . . . . . . . . . . . 88
13.1. Response Headers . . . . . . . . . . . . . . . . . . . . 87 13.2. Handling Redirected Child Resources . . . . . . . . . . 89
13.2. Handling Redirected Child Resources . . . . . . . . . . 88 14. XML Element Definitions . . . . . . . . . . . . . . . . . . . 90
13.3. Internal Status Codes . . . . . . . . . . . . . . . . . 88 14.1. activelock XML Element . . . . . . . . . . . . . . . . . 90
14. XML Element Definitions . . . . . . . . . . . . . . . . . . . 89 14.2. allprop XML Element . . . . . . . . . . . . . . . . . . 90
14.1. activelock XML Element . . . . . . . . . . . . . . . . . 89 14.3. collection XML Element . . . . . . . . . . . . . . . . . 90
14.2. allprop XML Element . . . . . . . . . . . . . . . . . . 89 14.4. depth XML Element . . . . . . . . . . . . . . . . . . . 90
14.3. collection XML Element . . . . . . . . . . . . . . . . . 89 14.5. error XML Element . . . . . . . . . . . . . . . . . . . 91
14.4. depth XML Element . . . . . . . . . . . . . . . . . . . 89 14.6. exclusive XML Element . . . . . . . . . . . . . . . . . 91
14.5. error XML Element . . . . . . . . . . . . . . . . . . . 90 14.7. href XML Element . . . . . . . . . . . . . . . . . . . . 91
14.6. exclusive XML Element . . . . . . . . . . . . . . . . . 90 14.8. include XML Element . . . . . . . . . . . . . . . . . . 92
14.7. href XML Element . . . . . . . . . . . . . . . . . . . . 90 14.9. location XML Element . . . . . . . . . . . . . . . . . . 92
14.8. include XML Element . . . . . . . . . . . . . . . . . . 91 14.10. lockentry XML Element . . . . . . . . . . . . . . . . . 92
14.9. location XML Element . . . . . . . . . . . . . . . . . . 91 14.11. lockinfo XML Element . . . . . . . . . . . . . . . . . . 92
14.10. lockentry XML Element . . . . . . . . . . . . . . . . . 91 14.12. lockroot XML Element . . . . . . . . . . . . . . . . . . 93
14.11. lockinfo XML Element . . . . . . . . . . . . . . . . . . 91 14.13. lockscope XML Element . . . . . . . . . . . . . . . . . 93
14.12. lockroot XML Element . . . . . . . . . . . . . . . . . . 92 14.14. locktoken XML Element . . . . . . . . . . . . . . . . . 93
14.13. lockscope XML Element . . . . . . . . . . . . . . . . . 92 14.15. locktype XML Element . . . . . . . . . . . . . . . . . . 93
14.14. locktoken XML Element . . . . . . . . . . . . . . . . . 92 14.16. multistatus XML Element . . . . . . . . . . . . . . . . 94
14.15. locktype XML Element . . . . . . . . . . . . . . . . . . 92 14.17. owner XML Element . . . . . . . . . . . . . . . . . . . 94
14.16. multistatus XML Element . . . . . . . . . . . . . . . . 93 14.18. prop XML Element . . . . . . . . . . . . . . . . . . . . 94
14.17. owner XML Element . . . . . . . . . . . . . . . . . . . 93 14.19. propertyupdate XML Element . . . . . . . . . . . . . . . 95
14.18. prop XML Element . . . . . . . . . . . . . . . . . . . . 93 14.20. propfind XML Element . . . . . . . . . . . . . . . . . . 95
14.19. propertyupdate XML Element . . . . . . . . . . . . . . . 94 14.21. propname XML Element . . . . . . . . . . . . . . . . . . 95
14.20. propfind XML Element . . . . . . . . . . . . . . . . . . 94 14.22. propstat XML Element . . . . . . . . . . . . . . . . . . 95
14.21. propname XML Element . . . . . . . . . . . . . . . . . . 94 14.23. remove XML Element . . . . . . . . . . . . . . . . . . . 96
14.22. propstat XML Element . . . . . . . . . . . . . . . . . . 94 14.24. response XML Element . . . . . . . . . . . . . . . . . . 96
14.23. remove XML Element . . . . . . . . . . . . . . . . . . . 95 14.25. responsedescription XML Element . . . . . . . . . . . . 97
14.24. response XML Element . . . . . . . . . . . . . . . . . . 95 14.26. set XML Element . . . . . . . . . . . . . . . . . . . . 97
14.25. responsedescription XML Element . . . . . . . . . . . . 96 14.27. shared XML Element . . . . . . . . . . . . . . . . . . . 97
14.26. set XML Element . . . . . . . . . . . . . . . . . . . . 96 14.28. status XML Element . . . . . . . . . . . . . . . . . . . 98
14.27. shared XML Element . . . . . . . . . . . . . . . . . . . 96 14.29. timeout XML Element . . . . . . . . . . . . . . . . . . 98
14.28. status XML Element . . . . . . . . . . . . . . . . . . . 96 14.30. write XML Element . . . . . . . . . . . . . . . . . . . 98
14.29. timeout XML Element . . . . . . . . . . . . . . . . . . 97 15. DAV Properties . . . . . . . . . . . . . . . . . . . . . . . 99
14.30. write XML Element . . . . . . . . . . . . . . . . . . . 97 15.1. creationdate Property . . . . . . . . . . . . . . . . . 99
15. DAV Properties . . . . . . . . . . . . . . . . . . . . . . . 98 15.2. displayname Property . . . . . . . . . . . . . . . . . . 100
15.1. creationdate Property . . . . . . . . . . . . . . . . . 98 15.3. getcontentlanguage Property . . . . . . . . . . . . . . 100
15.2. displayname Property . . . . . . . . . . . . . . . . . . 99 15.4. getcontentlength Property . . . . . . . . . . . . . . . 101
15.3. getcontentlanguage Property . . . . . . . . . . . . . . 99 15.5. getcontenttype Property . . . . . . . . . . . . . . . . 101
15.4. getcontentlength Property . . . . . . . . . . . . . . . 100 15.6. getetag Property . . . . . . . . . . . . . . . . . . . . 102
15.5. getcontenttype Property . . . . . . . . . . . . . . . . 100 15.7. getlastmodified Property . . . . . . . . . . . . . . . . 102
15.6. getetag Property . . . . . . . . . . . . . . . . . . . . 101 15.8. lockdiscovery Property . . . . . . . . . . . . . . . . . 103
15.7. getlastmodified Property . . . . . . . . . . . . . . . . 101 15.8.1. Example - Retrieving DAV:lockdiscovery . . . . . . . 104
15.8. lockdiscovery Property . . . . . . . . . . . . . . . . . 102 15.9. resourcetype Property . . . . . . . . . . . . . . . . . 105
15.8.1. Example - Retrieving DAV:lockdiscovery . . . . . . . 103 15.10. supportedlock Property . . . . . . . . . . . . . . . . . 106
15.9. resourcetype Property . . . . . . . . . . . . . . . . . 104 15.10.1. Example - Retrieving DAV:supportedlock . . . . . . . 107
15.10. supportedlock Property . . . . . . . . . . . . . . . . . 105 16. Precondition/Postcondition XML Elements . . . . . . . . . . . 108
15.10.1. Example - Retrieving DAV:supportedlock . . . . . . . 106 16.1. DAV:lock-token-matches-request-uri (Precondition) . . . 109
16. Precondition/Postcondition XML Elements . . . . . . . . . . . 107 16.2. DAV:lock-token-submitted (Precondition) . . . . . . . . 109
16.3. DAV:no-conflicting-lock (Precondition) . . . . . . . . . 110
16.4. DAV:no-external-entities (Precondition) . . . . . . . . 110
16.5. DAV:preserved-live-properties (postcondition) . . . . . 110
16.6. DAV:propfind-finite-depth (Precondition) . . . . . . . . 110
16.7. DAV:cannot-modify-protected-property (Precondition) . . 110
17. XML Extensibility in DAV . . . . . . . . . . . . . . . . . . 111 17. XML Extensibility in DAV . . . . . . . . . . . . . . . . . . 111
18. DAV Compliance Classes . . . . . . . . . . . . . . . . . . . 113 18. DAV Compliance Classes . . . . . . . . . . . . . . . . . . . 113
18.1. Class 1 . . . . . . . . . . . . . . . . . . . . . . . . 113 18.1. Class 1 . . . . . . . . . . . . . . . . . . . . . . . . 113
18.2. Class 2 . . . . . . . . . . . . . . . . . . . . . . . . 113 18.2. Class 2 . . . . . . . . . . . . . . . . . . . . . . . . 113
18.3. Class 3 . . . . . . . . . . . . . . . . . . . . . . . . 113 18.3. Class 3 . . . . . . . . . . . . . . . . . . . . . . . . 113
19. Internationalization Considerations . . . . . . . . . . . . . 115 19. Internationalization Considerations . . . . . . . . . . . . . 115
20. Security Considerations . . . . . . . . . . . . . . . . . . . 117 20. Security Considerations . . . . . . . . . . . . . . . . . . . 117
20.1. Authentication of Clients . . . . . . . . . . . . . . . 117 20.1. Authentication of Clients . . . . . . . . . . . . . . . 117
20.2. Denial of Service . . . . . . . . . . . . . . . . . . . 117 20.2. Denial of Service . . . . . . . . . . . . . . . . . . . 117
20.3. Security through Obscurity . . . . . . . . . . . . . . . 118 20.3. Security through Obscurity . . . . . . . . . . . . . . . 118
20.4. Privacy Issues Connected to Locks . . . . . . . . . . . 118 20.4. Privacy Issues Connected to Locks . . . . . . . . . . . 118
20.5. Privacy Issues Connected to Properties . . . . . . . . . 118 20.5. Privacy Issues Connected to Properties . . . . . . . . . 118
20.6. Implications of XML Entities . . . . . . . . . . . . . . 119 20.6. Implications of XML Entities . . . . . . . . . . . . . . 119
20.7. Risks Connected with Lock Tokens . . . . . . . . . . . . 119 20.7. Risks Connected with Lock Tokens . . . . . . . . . . . . 119
20.8. Hosting Malicious Content . . . . . . . . . . . . . . . 120 20.8. Hosting Malicious Content . . . . . . . . . . . . . . . 120
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 121 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122
21.1. New URI Schemes . . . . . . . . . . . . . . . . . . . . 121 21.1. New URI Schemes . . . . . . . . . . . . . . . . . . . . 122
21.2. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 121 21.2. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 122
21.3. Message Header Fields . . . . . . . . . . . . . . . . . 121 21.3. Message Header Fields . . . . . . . . . . . . . . . . . 122
21.3.1. DAV . . . . . . . . . . . . . . . . . . . . . . . . 121 21.3.1. DAV . . . . . . . . . . . . . . . . . . . . . . . . 122
21.3.2. Depth . . . . . . . . . . . . . . . . . . . . . . . 121 21.3.2. Depth . . . . . . . . . . . . . . . . . . . . . . . 123
21.3.3. Destination . . . . . . . . . . . . . . . . . . . . 122 21.3.3. Destination . . . . . . . . . . . . . . . . . . . . 123
21.3.4. If . . . . . . . . . . . . . . . . . . . . . . . . . 122 21.3.4. If . . . . . . . . . . . . . . . . . . . . . . . . . 123
21.3.5. Lock-Token . . . . . . . . . . . . . . . . . . . . . 122 21.3.5. Lock-Token . . . . . . . . . . . . . . . . . . . . . 123
21.3.6. Overwrite . . . . . . . . . . . . . . . . . . . . . 122 21.3.6. Overwrite . . . . . . . . . . . . . . . . . . . . . 124
21.3.7. Timeout . . . . . . . . . . . . . . . . . . . . . . 123 21.3.7. Timeout . . . . . . . . . . . . . . . . . . . . . . 124
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 124 21.4. HTTP Status Codes . . . . . . . . . . . . . . . . . . . 124
23. Contributors to This Specification . . . . . . . . . . . . . 126 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 125
24. Authors of RFC2518 . . . . . . . . . . . . . . . . . . . . . 127 23. Contributors to This Specification . . . . . . . . . . . . . 127
25. References . . . . . . . . . . . . . . . . . . . . . . . . . 128 24. Authors of RFC2518 . . . . . . . . . . . . . . . . . . . . . 128
25.1. Normative References . . . . . . . . . . . . . . . . . . 128 25. References . . . . . . . . . . . . . . . . . . . . . . . . . 129
25.2. Informational References . . . . . . . . . . . . . . . . 129 25.1. Normative References . . . . . . . . . . . . . . . . . . 129
Appendix A. Notes on Processing XML Elements . . . . . . . . . . 130 25.2. Informational References . . . . . . . . . . . . . . . . 130
A.1. Notes on Empty XML Elements . . . . . . . . . . . . . . 130 Appendix A. Notes on Processing XML Elements . . . . . . . . . . 132
A.2. Notes on Illegal XML Processing . . . . . . . . . . . . 130 A.1. Notes on Empty XML Elements . . . . . . . . . . . . . . 132
A.3. Example - XML Syntax Error . . . . . . . . . . . . . . . 130 A.2. Notes on Illegal XML Processing . . . . . . . . . . . . 132
A.4. Example - Unexpected XML Element . . . . . . . . . . . . 131 A.3. Example - XML Syntax Error . . . . . . . . . . . . . . . 132
Appendix B. Notes on HTTP Client Compatibility . . . . . . . . . 132 A.4. Example - Unexpected XML Element . . . . . . . . . . . . 133
Appendix C. The 'opaquelocktoken' Scheme and URIs . . . . . . . 133 Appendix B. Notes on HTTP Client Compatibility . . . . . . . . . 134
Appendix D. Lock-null Resources . . . . . . . . . . . . . . . . 134 Appendix C. The 'opaquelocktoken' Scheme and URIs . . . . . . . 135
D.1. Guidance for Clients Using LOCK to Create Resources . . 134 Appendix D. Lock-Null Resources . . . . . . . . . . . . . . . . 136
Appendix E. Guidance for Clients Desiring to Authenticate . . . 136 D.1. Guidance for Clients Using LOCK to Create Resources . . 136
Appendix F. Summary of changes from RFC2518 . . . . . . . . . . 138 Appendix E. Guidance for Clients Desiring to Authenticate . . . 138
F.1. Changes for both Client and Server Implementations . . . 138 Appendix F. Summary of changes from RFC2518 . . . . . . . . . . 140
F.2. Changes for Server Implementations . . . . . . . . . . . 139 F.1. Changes for both Client and Server Implementations . . . 140
F.3. Other Changes . . . . . . . . . . . . . . . . . . . . . 140 F.2. Changes for Server Implementations . . . . . . . . . . . 141
F.3. Other Changes . . . . . . . . . . . . . . . . . . . . . 142
Appendix G. Change Log (to be removed by RFC Editor before Appendix G. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 142 publication) . . . . . . . . . . . . . . . . . . . . 143
G.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . 142 G.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . 143
G.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 142 G.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 143
G.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 143 G.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 144
G.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 144 G.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 145
G.5. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 145 G.5. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 146
G.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 145 G.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 146
G.7. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 145 G.7. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 146
G.8. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 146 G.8. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 147
G.9. Changes in -14 . . . . . . . . . . . . . . . . . . . . . 146 G.9. Changes in -14 . . . . . . . . . . . . . . . . . . . . . 147
G.10. Changes in -15 . . . . . . . . . . . . . . . . . . . . . 146 G.10. Changes in -15 . . . . . . . . . . . . . . . . . . . . . 147
G.11. Changes in -16 . . . . . . . . . . . . . . . . . . . . . 146 G.11. Changes in -16 . . . . . . . . . . . . . . . . . . . . . 147
G.12. Changes in -17 . . . . . . . . . . . . . . . . . . . . . 147 G.12. Changes in -17 . . . . . . . . . . . . . . . . . . . . . 148
G.13. Changes in -18 . . . . . . . . . . . . . . . . . . . . . 147 G.13. Changes in -18 . . . . . . . . . . . . . . . . . . . . . 148
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 148 G.14. Changes compared to RFC2518bis, dated 2007-02-15 . . . . 149
Intellectual Property and Copyright Statements . . . . . . . . . 149 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 153
Intellectual Property and Copyright Statements . . . . . . . . . 154
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
skipping to change at page 8, line 43 skipping to change at page 9, line 43
This document does not specify the versioning operations suggested by This document does not specify the versioning operations suggested by
[RFC2291]. That work was done in a separate document, "Versioning [RFC2291]. That work was done in a separate document, "Versioning
Extensions to WebDAV" [RFC3253]. Extensions to WebDAV" [RFC3253].
The sections below provide a detailed introduction to various WebDAV The sections below provide a detailed introduction to various WebDAV
abstractions: resource properties (Section 4), collections of abstractions: resource properties (Section 4), collections of
resources (Section 5), locks (Section 6) in general and write locks resources (Section 5), locks (Section 6) in general and write locks
(Section 7) specifically. (Section 7) specifically.
These abstractions are manipulated by the WebDAV-specific HTTP These abstractions are manipulated by the WebDAV-specific HTTP
methods (Section 9) and the extra HTTP headers (Section 10) used with methods and the extra HTTP headers, defined in Section 8 (generic
WebDAV methods. General considerations for handling HTTP requests method handling), Section 9 (method definitions) and Section 10
and responses in WebDAV are found in Section 8. (header definitions).
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.
This specification defines extra status codes developed for WebDAV This specification defines extra status codes developed for WebDAV
methods (Section 11) and describes existing HTTP status codes methods (Section 11) and describes existing HTTP status codes
(Section 12) as used in WebDAV. Since some WebDAV methods may (Section 12) as used in WebDAV. Since some WebDAV methods may
operate over many resources, the Multi-Status response (Section 13) operate over many resources, the Multi-Status response (Section 13)
has been introduced to return status information for multiple has been introduced to return status information for multiple
resources. Finally, this version of WebDAV introduces precondition resources. Finally, this version of WebDAV introduces precondition
and postcondition (Section 16) XML elements in error response bodies. and postcondition (Section 16) XML elements in error response bodies.
WebDAV uses XML ([REC-XML]) for property names and some values, and WebDAV uses XML ([REC-XML]) for property names and some values, and
also uses XML to marshal complicated requests and responses. This also uses XML to marshal complicated requests and responses. This
specification contains DTD and text definitions of all all properties specification contains DTD and text definitions of all all properties
(Section 15) and all other XML elements (Section 14) used in (Section 15) and other XML elements (Section 14) used in marshalling.
marshalling. WebDAV includes a few special rules on extending WebDAV includes a few special rules on extending WebDAV XML
WebDAV XML marshalling in backwards-compatible ways (Section 17). marshalling in backwards-compatible ways (Section 17).
Finishing off the specification are sections on what it means for a Finishing off the specification are sections on what it means for a
resource to be compliant with this specification (Section 18), on resource to be compliant with this specification (Section 18), on
internationalization support (Section 19), and on security internationalization support (Section 19), and on security
(Section 20). (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
skipping to change at page 14, line 14 skipping to change at page 15, line 14
XML's support for multiple character sets allows any human-readable XML's support for multiple character sets allows any human-readable
property to be encoded and read in a character set familiar to the property to be encoded and read in a character set familiar to the
user. XML's support for multiple human languages, using the "xml: user. XML's support for multiple human languages, using the "xml:
lang" attribute, handles cases where the same character set is lang" attribute, handles cases where the same character set is
employed by multiple human languages. Note that xml:lang scope is employed by multiple human languages. Note that xml:lang scope is
recursive, so an xml:lang attribute on any element containing a recursive, so an xml:lang attribute on any element containing a
property name element applies to the property value unless it has property name element applies to the property value unless it has
been overridden by a more locally scoped attribute. Note that a been overridden by a more locally scoped attribute. Note that a
property only has one value, in one language (or language MAY be left property only has one value, in one language (or language MAY be left
undefined), not multiple values in different languages or a single undefined); it does not have multiple values in different languages
value in multiple languages. or a single value in multiple languages.
A property is always represented with an XML element consisting of A property is always represented with an XML element consisting of
the property name, called the "property name element". The simplest the property name, called the "property name element". The simplest
example is an empty property, which is different from a property that example is an empty property, which is different from a property that
does not exist: does not exist:
<R:title xmlns:R="http://www.example.com/ns/"></R:title> <R:title xmlns:R="http://www.example.com/ns/"></R:title>
The value of the property appears inside the property name element. The value of the property appears inside the property name element.
The value may be any kind of well-formed XML content, including both The value may be any kind of well-formed XML content, including both
skipping to change at page 19, line 32 skipping to change at page 20, line 32
Although commonly a mapping consists of a single segment and a Although commonly a mapping consists of a single segment and a
resource, in general, a mapping consists of a set of segments and a resource, in general, a mapping consists of a set of segments and a
resource. This allows a server to treat a set of segments as resource. This allows a server to treat a set of segments as
equivalent (i.e. either all of the segments are mapped to the same equivalent (i.e. either all of the segments are mapped to the same
resource, or none of the segments are mapped to a resource). For resource, or none of the segments are mapped to a resource). For
example, a server that performs case-folding on segments will treat example, a server that performs case-folding on segments will treat
the segments "ab", "Ab", "aB", and "AB" as equivalent. A client can the segments "ab", "Ab", "aB", and "AB" as equivalent. A client can
then use any of these segments to identify the resource. Note that a then use any of these segments to identify the resource. Note that a
PROPFIND result will select one of these equivalent segments to PROPFIND result will select one of these equivalent segments to
identify the mapping, so there will be one PROPFIND response element identify the mapping, so there will be one PROPFIND response element
per mapping, not one per segment in the mapping. per mapping, not one per segment in the mapping. Servers SHOULD
consistently use the same segment in PROPFIND responses.
Collection resources MAY have mappings to non-WebDAV compliant Collection resources MAY have mappings to non-WebDAV compliant
resources in the HTTP URL namespace hierarchy but are not required to resources in the HTTP URL namespace hierarchy but are not required to
do so. For example, if resource X with URL do so. For example, if resource X with URL
"http://example.com/bar/blah" is not WebDAV compliant and resource A "http://example.com/bar/blah" is not WebDAV compliant and resource A
with "URL http://example.com/bar/" identifies a WebDAV collection, with "URL http://example.com/bar/" identifies a WebDAV collection,
then A may or may not have a mapping from "blah" to X. then A may or may not have a mapping from "blah" to X.
If a WebDAV compliant resource has no WebDAV compliant internal If a WebDAV compliant resource has no WebDAV compliant internal
members in the HTTP URL namespace hierarchy then the WebDAV compliant members in the HTTP URL namespace hierarchy then the WebDAV compliant
skipping to change at page 20, line 20 skipping to change at page 21, line 21
find the DAV:resourcetype property more reliable than the URL to find find the DAV:resourcetype property more reliable than the URL to find
out if a resource is a collection. out if a resource is a collection.
Clients MUST be able to support the case where WebDAV resources are Clients MUST be able to support the case where WebDAV resources are
contained inside non-WebDAV resources. For example, if a OPTIONS contained inside non-WebDAV resources. For example, if a OPTIONS
response from "http://example.com/servlet/dav/collection" indicates response from "http://example.com/servlet/dav/collection" indicates
WebDAV support, the client cannot assume that WebDAV support, the client cannot assume that
"http://example.com/servlet/dav/" or its parent necessarily are "http://example.com/servlet/dav/" or its parent necessarily are
WebDAV collections. WebDAV collections.
5.2.1. Example - non WebDAV-compliant Resource in Collection
A typical scenario in which mapped URLs do not appear as members of A typical scenario in which mapped URLs do not appear as members of
their parent collection is the case where a server allows links or their parent collection is the case where a server allows links or
redirects to non-WebDAV resources. For instance, "/col/link" might redirects to non-WebDAV resources. For instance, "/col/link" might
not appear as a member of "/col/", although the server would respond not appear as a member of "/col/", although the server would respond
with a 302 status to a GET request to "/col/link", thus the URL with a 302 status to a GET request to "/col/link", thus the URL
"/col/link" would indeed be mapped. Similarly, a dynamically- "/col/link" would indeed be mapped. Similarly, a dynamically-
generated page might have a URL mapping from "/col/index.html", thus generated page might have a URL mapping from "/col/index.html", thus
this resource might respond with a 200 OK to a GET request yet not this resource might respond with a 200 OK to a GET request yet not
appear as a member of "/col/". appear as a member of "/col/".
5.2.2. Example - URL of WebDAV-compliant Resource not appearing in
Parent Collection
Some mappings to even WebDAV-compliant resources might not appear in Some mappings to even WebDAV-compliant resources might not appear in
the parent collection. An example for this case are servers that the parent collection. An example for this case are servers that
support multiple alias URLs for each WebDAV compliant resource. A support multiple alias URLs for each WebDAV compliant resource. A
server may implement case-insensitive URLs, thus "/col/a" and server may implement case-insensitive URLs, thus "/col/a" and
"/col/A" identify the same resource, yet only either "a" or "A" are "/col/A" identify the same resource, yet only either "a" or "A" are
reported upon listing the members of "/col". In cases where a server reported upon listing the members of "/col". In cases where a server
treats a set of segments as equivalent, the server MUST expose only treats a set of segments as equivalent, the server MUST expose only
one preferred segment per mapping, consistently chosen, in PROPFIND one preferred segment per mapping, consistently chosen, in PROPFIND
responses. responses.
skipping to change at page 21, line 50 skipping to change at page 22, line 50
resource. resource.
4. For a collection that is locked with a depth-infinity lock L, all 4. For a collection that is locked with a depth-infinity lock L, all
member resources are indirectly locked. Changes in membership of member resources are indirectly locked. Changes in membership of
a such a collection affect the set of indirectly locked a such a collection affect the set of indirectly locked
resources: resources:
* If a member resource is added to the collection, the new * If a member resource is added to the collection, the new
member resource MUST NOT already have a conflicting lock, member resource MUST NOT already have a conflicting lock,
because the new resource MUST become indirectly locked by L. because the new resource MUST become indirectly locked by L.
[[anchor9: So what happens if it has a conflicting lock?]]
[[anchor10: Language?]]
* If a member resource stops being a member of the collection, * If a member resource stops being a member of the collection,
then the resource MUST no longer be indirectly locked by L. then the resource MUST no longer be indirectly locked by L.
5. Each lock is identified by a single globally unique lock token 5. Each lock is identified by a single globally unique lock token
(Section 6.5). (Section 6.5).
6. An UNLOCK request deletes the lock with the specified lock token. 6. An UNLOCK request deletes the lock with the specified lock token.
After a lock is deleted, no resource is locked by that lock. After a lock is deleted, no resource is locked by that lock.
skipping to change at page 22, line 29 skipping to change at page 23, line 32
The most basic form of lock is an exclusive lock. Exclusive locks The most basic form of lock is an exclusive lock. Exclusive locks
avoid having to deal with content change conflicts, without requiring avoid having to deal with content change conflicts, without requiring
any coordination other than the methods described in this any coordination other than the methods described in this
specification. specification.
However, there are times when the goal of a lock is not to exclude However, there are times when the goal of a lock is not to exclude
others from exercising an access right but rather to provide a others from exercising an access right but rather to provide a
mechanism for principals to indicate that they intend to exercise mechanism for principals to indicate that they intend to exercise
their access rights. Shared locks are provided for this case. A their access rights. Shared locks are provided for this case. A
shared lock allows multiple principals to receive a lock. Hence any shared lock allows multiple principals to receive a distinct lock.
principal that has both access privileges and a valid lock can use Hence any principal that has both access privileges and a valid lock
the locked resource. can use the locked resource.
With shared locks there are two trust sets that affect a resource. With shared locks there are two trust sets that affect a resource.
The first trust set is created by access permissions. Principals who The first trust set is created by access permissions. Principals who
are trusted, for example, may have permission to write to the are trusted, for example, may have permission to write to the
resource. Among those who have access permission to write to the resource. Among those who have access permission to write to the
resource, the set of principals who have taken out a shared lock also resource, the set of principals who have taken out a shared lock also
must trust each other, creating a (typically) smaller trust set must trust each other, creating a (typically) smaller trust set
within the access permission write set. within the access permission write set.
Starting with every possible principal on the Internet, in most Starting with every possible principal on the Internet, in most
skipping to change at page 25, line 19 skipping to change at page 26, line 19
ultimately chooses the timeout value. Timeout is measured in seconds ultimately chooses the timeout value. Timeout is measured in seconds
remaining until lock expiration. remaining until lock expiration.
The timeout counter MUST be restarted if a refresh lock request is The timeout counter MUST be restarted if a refresh lock request is
successful (see Section 9.10.2). The timeout counter SHOULD NOT be successful (see Section 9.10.2). The timeout counter SHOULD NOT be
restarted at any other time. restarted at any other time.
If the timeout expires then the lock SHOULD be removed. In this case If the timeout expires then the lock SHOULD be removed. In this case
the server SHOULD act as if an UNLOCK method was executed by the the server SHOULD act as if an UNLOCK method was executed by the
server on the resource using the lock token of the timed-out lock, server on the resource using the lock token of the timed-out lock,
performed with its override authority. performed with its override authority. For instance, if the server
implements some sort of logging and notification system for locking-
related events, a lock timeout should be treated similar to an UNLOCK
request.
Servers are advised to pay close attention to the values submitted by Servers are advised to pay close attention to the values submitted by
clients, as they will be indicative of the type of activity the clients, as they will be indicative of the type of activity the
client intends to perform. For example, an applet running in a client intends to perform. For example, an applet running in a
browser may need to lock a resource, but because of the instability browser may need to lock a resource, but because of the instability
of the environment within which the applet is running, the applet may of the environment within which the applet is running, the applet may
be turned off without warning. As a result, the applet is likely to be turned off without warning. As a result, the applet is likely to
ask for a relatively small timeout value so that if the applet dies, ask for a relatively small timeout value so that if the applet dies,
the lock can be quickly harvested. However, a document management the lock can be quickly harvested. However, a document management
system is likely to ask for an extremely long timeout because its system is likely to ask for an extremely long timeout because its
skipping to change at page 27, line 5 skipping to change at page 27, line 21
If another principal locks a resource that a principal wishes to If another principal locks a resource that a principal wishes to
access, it is useful for the second principal to be able to find out access, it is useful for the second principal to be able to find out
who the first principal is. For this purpose the DAV:lockdiscovery who the first principal is. For this purpose the DAV:lockdiscovery
property is provided. This property lists all outstanding locks, property is provided. This property lists all outstanding locks,
describes their type, and MAY even provide the lock tokens. describes their type, and MAY even provide the lock tokens.
Any DAV compliant resource that supports the LOCK method MUST support Any DAV compliant resource that supports the LOCK method MUST support
the DAV:lockdiscovery property. the DAV:lockdiscovery property.
6.9. Locks and Multiple Bindings
A resource may be made available through more than one URI. A lock
MUST cover the resource as well as the URI to which the LOCK request
was addressed. The lock MAY cover other URIs mapped to the same
resource as well.
[[anchor15: Section was removed in draft 15. Why?]]
7. Write Lock 7. Write Lock
This section describes the semantics specific to the write lock type. This section describes the semantics specific to the write lock type.
The write lock is a specific instance of a lock type, and is the only The write lock is a specific instance of a lock type, and is the only
lock type described in this specification. lock type described in this specification.
An exclusive write lock protects a resource: it prevents changes by An exclusive write lock protects a resource: it prevents changes by
any principal other than the lock creator and in any case where the any principal other than the lock creator and in any case where the
lock token is not submitted (e.g. by a client process other than the lock token is not submitted (e.g. by a client process other than the
one holding the lock). one holding the lock). [[anchor16: All of this is repeated in the
next paragraph. Optimally remove this one.]]
Clients MUST submit a lock-token they are authorized to use in any Clients MUST submit a lock-token they are authorized to use in any
request which modifies a write-locked resource. The list of request which modifies a write-locked resource. The list of
modifications covered by a write-lock include: modifications covered by a write-lock include:
1. A change to any of the following aspects of any write-locked 1. A change to any of the following aspects of any write-locked
resource: resource:
* any variant, * any variant,
* any dead property, * any dead property,
* any live property which is lockable (a live property is * any live property which is lockable (a live property is
lockable unless otherwise defined.) lockable unless otherwise defined.)
[[anchor17: So there are live properties which are lockable and
may change their values while they are locked, and there are live
properties which respect locks and must not change their values
while they are locked? Is this really intended or is this
section historical and should be dropped? --Manfred Baedke]]
2. For collections, any modification of an internal member URI. An 2. For collections, any modification of an internal member URI. An
internal member URI of a collection is considered to be modified internal member URI of a collection is considered to be modified
if it is added, removed, or identifies a different resource. if it is added, removed, or identifies a different resource.
More discussion on write locks and collections is found in More discussion on write locks and collections is found in
Section 7.4. Section 7.4.
3. A modification of the mapping of the root of the write lock, 3. A modification of the mapping of the root of the write lock,
either to another resource or to no resource (e.g. DELETE). either to another resource or to no resource (e.g. DELETE).
Of the methods defined in HTTP and WebDAV, PUT, POST, PROPPATCH, Of the methods defined in HTTP and WebDAV, PUT, POST, PROPPATCH,
skipping to change at page 28, line 4 skipping to change at page 29, line 11
lock. lock.
The next few sections describe in more specific terms how write locks The next few sections describe in more specific terms how write locks
interact with various operations. interact with various operations.
7.1. Write Locks and Properties 7.1. Write Locks and Properties
While those without a write lock may not alter a property on a While those without a write lock may not alter a property on a
resource it is still possible for the values of live properties to resource it is still possible for the values of live properties to
change, even while locked, due to the requirements of their schemas. change, even while locked, due to the requirements of their schemas.
Only dead properties and live properties defined as lockable are Only dead properties and live properties defined as lockable are
guaranteed not to change while write locked. guaranteed not to change while write locked. [[anchor19: The whole
paragraph doesn't seem to make sense anymore, because it seems to say
the same thing as the previous section, but uses different
terminology.]]
7.2. Avoiding Lost Updates 7.2. Avoiding Lost Updates
Although the write locks provide some help in preventing lost Although the write locks provide some help in preventing lost
updates, they cannot guarantee that updates will never be lost. updates, they cannot guarantee that updates will never be lost.
Consider the following scenario: Consider the following scenario:
Two clients A and B are interested in editing the resource Two clients A and B are interested in editing the resource
'index.html'. Client A is an HTTP client rather than a WebDAV 'index.html'. Client A is an HTTP client rather than a WebDAV
client, and so does not know how to perform locking. client, and so does not know how to perform locking.
skipping to change at page 29, line 30 skipping to change at page 30, line 40
atomic operation there's no guarantee this will work). atomic operation there's no guarantee this will work).
A successful lock request to an unmapped URL MUST result in the A successful lock request to an unmapped URL MUST result in the
creation of a locked (non-collection) resource with empty content. creation of a locked (non-collection) resource with empty content.
Subsequently, a successful PUT request (with the correct lock token) Subsequently, a successful PUT request (with the correct lock token)
provides the content for the resource. Note that the LOCK request provides the content for the resource. Note that the LOCK request
has no mechanism for the client to provide Content-Type or Content- has no mechanism for the client to provide Content-Type or Content-
Language, thus the server will use defaults or empty values and rely Language, thus the server will use defaults or empty values and rely
on the subsequent PUT request for correct values. on the subsequent PUT request for correct values.
A resource created with a LOCK is empty but otherwise behaves in
every way as a normal resource. It behaves the same way as a
resource created by a PUT request with an empty body (and where a
Content-Type and Content-Language was not specified), followed by a
LOCK request to the same resource. Following from this model, a
locked empty resource:
o Can be read, deleted, moved, copied, and in all ways behave as a
regular non-collection resource.
o Appears as a member of its parent collection.
o SHOULD NOT disappear when its lock goes away (clients must
therefore be responsible for cleaning up their own mess, as with
any other operation or any non-empty resource)
o MAY NOT have values for properties like DAV:getcontentlanguage
which haven't been specified yet by the client.
o Can be updated (have content added) with a PUT request.
o MUST NOT be converted into a collection. The server MUST fail a
MKCOL request (as it would with a MKCOL request to any existing
non-collection resource).
o MUST have defined values for DAV:lockdiscovery and DAV:
supportedlock properties.
o The response MUST indicate that a resource was created, by use of
the "201 Created" response code (a LOCK request to an existing
resource instead will result in 200 OK). The body must still
include the DAV:lockdiscovery property, as with a LOCK request to
an existing resource.
The client is expected to update the locked empty resource shortly
after locking it, using PUT and possibly PROPPATCH.
Alternatively and for backwards compatibility to [RFC2518], servers Alternatively and for backwards compatibility to [RFC2518], servers
MAY implement Lock-Null Resources (LNRs) instead (see definition in MAY implement Lock-Null Resources (LNRs) instead (see definition in
Appendix D). Clients can easily interoperate both with servers that Appendix D). Clients can easily interoperate both with servers that
support the old model LNRs and the recommended model of "locked empty support the old model LNRs and the recommended model of "locked empty
resources" by only attempting PUT after a LOCK to an unmapped URL, resources" by only attempting PUT after a LOCK to an unmapped URL,
not MKCOL or GET, and by not relying on specific properties of LNRs. not MKCOL or GET, and by not relying on specific properties of LNRs.
7.4. Write Locks and Collections 7.4. Write Locks and Collections
There are two kinds of collection write locks. A depth-0 write lock There are two kinds of collection write locks. A depth-0 write lock
on a collection protects the collection properties plus the internal on a collection protects the collection properties plus the internal
member URLs of that one collection, while not protecting the content member URLs of that one collection, while not protecting the content
or properties of member resources (if the collection itself has any or properties of member resources (if the collection itself has any
entity bodies, those are also protected). A depth-infinity write entity bodies, those are also protected). A depth-infinity write
lock on a collection provides the same protection on that collection lock on a collection provides the same protection on that collection
and also provides write lock protection on every member resource. and also provides write lock protection on every member resource.
Expressed otherwise, a write lock protects any request that would Expressed otherwise, a write lock of either kind protects any request
create a new resource in a write locked collection, any request that that would create a new resource in a write locked collection, any
would remove an internal member URL of a write locked collection, and request that would remove an internal member URL of a write locked
any request that would change the segment name of any internal collection, and any request that would change the segment name of any
member. internal member.
Thus, a collection write lock protects all the following actions: Thus, a collection write lock protects all the following actions:
o DELETE a collection's direct internal member, o DELETE a collection's direct internal member,
o MOVE an internal member out of the collection, o MOVE an internal member out of the collection,
o MOVE an internal member into the collection, o MOVE an internal member into the collection,
o MOVE to rename an internal member within a collection, o MOVE to rename an internal member within a collection,
skipping to change at page 31, line 4 skipping to change at page 31, line 24
Thus, a collection write lock protects all the following actions: Thus, a collection write lock protects all the following actions:
o DELETE a collection's direct internal member, o DELETE a collection's direct internal member,
o MOVE an internal member out of the collection, o MOVE an internal member out of the collection,
o MOVE an internal member into the collection, o MOVE an internal member into the collection,
o MOVE to rename an internal member within a collection, o MOVE to rename an internal member within a collection,
o COPY an internal member into a collection, and o COPY an internal member into a collection, and
o PUT or MKCOL request which would create a new internal member. o PUT or MKCOL request which would create a new internal member.
[[anchor21: ... (or simply drop the list, since it does not contain
anything new). --Manfred Baedke]]
The collection's lock token is required in addition to the lock token The collection's lock token is required in addition to the lock token
on the internal member itself, if it is locked separately. on the internal member itself, if it is locked separately.
In addition, a depth-infinity lock affects all write operations to In addition, a depth-infinity lock affects all write operations to
all members of the locked collection. With a depth-infinity lock, all members of the locked collection. With a depth-infinity lock,
the resource identified by the root of the lock is directly locked, the resource identified by the root of the lock is directly locked,
and all its members are indirectly locked. and all its members are indirectly locked.
o Any new resource added as a descendent of a depth-infinity locked o Any new resource added as a descendent of a depth-infinity locked
collection becomes indirectly locked. collection becomes indirectly locked.
skipping to change at page 34, line 13 skipping to change at page 34, line 47
the resource will be added to that collection's lock. Additionally, the resource will be added to that collection's lock. Additionally,
if a resource with a depth-infinity lock is moved to a destination if a resource with a depth-infinity lock is moved to a destination
that is within the scope of the same lock (e.g., within the URL that is within the scope of the same lock (e.g., within the URL
namespace tree covered by the lock), the moved resource will again be namespace tree covered by the lock), the moved resource will again be
a added to the lock. In both these examples, as specified in a added to the lock. In both these examples, as specified in
Section 7.5, an If header must be submitted containing a lock token Section 7.5, an If header must be submitted containing a lock token
for both the source and destination. for both the source and destination.
7.7. Refreshing Write Locks 7.7. Refreshing Write Locks
A client MUST NOT submit the same write lock request twice. Note [[anchor26: IMHO all of this can go. This paragraph is just
that a client is always aware it is resubmitting the same lock misleading; repeating a LOCK request with an existing lock token in
request because it must include the lock token in the If header in the If header is going to fail for an exclusive lock anway.]]
order to make the request for a resource that is already locked.
However, a client may submit a LOCK request with an If header but
without a body. A server receiving a LOCK request with no body MUST
NOT create a new lock -- this form of the LOCK request is only to be
used to "refresh" an existing lock (meaning, at minimum, that any
timers associated with the lock MUST be re-set).
Clients may submit Timeout headers of arbitrary value with their lock
refresh requests. Servers, as always, may ignore Timeout headers
submitted by the client, and a server MAY refresh a lock with a
timeout period that is different than the previous timeout period
used for the lock, provided it advertises the new value in the LOCK
refresh response.
If an error is received in response to a refresh LOCK request the [[anchor27: Just point to the paragraph in the LOCK definition
client MUST NOT assume that the lock was refreshed. here.]]
8. General Request and Response Handling 8. General Request and Response Handling
8.1. Precedence in Error Handling 8.1. Precedence in Error Handling
Servers MUST return authorization errors in preference to other Servers MUST return authorization errors in preference to other
errors. This avoids leaking information about protected resources errors. This avoids leaking information about protected resources
(e.g. a client that finds that a hidden resource exists by seeing a (e.g. a client that finds that a hidden resource exists by seeing a
423 Locked response to an anonymous request to the resource). 423 Locked response to an anonymous request to the resource).
skipping to change at page 37, line 29 skipping to change at page 38, line 29
where a request body is present but would be ignored by a server, the where a request body is present but would be ignored by a server, the
server MUST reject the request with 415 (Unsupported Media Type). server MUST reject the request with 415 (Unsupported Media Type).
This informs the client (which may have been attempting to use an This informs the client (which may have been attempting to use an
extension) that the body could not be processed as the client extension) that the body could not be processed as the client
intended. intended.
8.5. HTTP Headers for use in WebDAV 8.5. HTTP Headers for use in WebDAV
HTTP defines many headers that can be used in WebDAV requests and HTTP defines many headers that can be used in WebDAV requests and
responses. Not all of these are appropriate in all situations and responses. Not all of these are appropriate in all situations and
some interactions may be undefined. Note that HTTP 1.1 requires the some interactions may be undefined.
Date header in all responses if possible (see Section 14.18,
[RFC2616]).
The server MUST do authorization checks before checking any HTTP The server MUST do authorization checks before checking any HTTP
conditional header. conditional header.
8.6. ETag 8.6. ETag
HTTP 1.1 recommends the use of ETags rather than modification dates, HTTP 1.1 recommends the use of ETags rather than modification dates,
for cache-control, and there are even stronger reasons to prefer for cache-control, and there are even stronger reasons to prefer
ETags for authoring. Correct use of ETags is even more important in ETags for authoring. Correct use of ETags is even more important in
a distributed authoring environment, because ETags are necessary a distributed authoring environment, because ETags are necessary
skipping to change at page 38, line 24 skipping to change at page 39, line 23
Note that the meaning of an ETag in a PUT response is not clearly Note that the meaning of an ETag in a PUT response is not clearly
defined either in this document or in RFC2616 (i.e., whether the ETag defined either in this document or in RFC2616 (i.e., whether the ETag
means that the resource is octet-for-octet equivalent to the body of means that the resource is octet-for-octet equivalent to the body of
the PUT request, or whether the server could have made minor changes the PUT request, or whether the server could have made minor changes
in the formatting or content of the document upon storage). This is in the formatting or content of the document upon storage). This is
an HTTP issue, not purely a WebDAV issue. an HTTP issue, not purely a WebDAV issue.
Because clients may be forced to prompt users or throw away changed Because clients may be forced to prompt users or throw away changed
content if the ETag changes, a WebDAV server SHOULD NOT change the content if the ETag changes, a WebDAV server SHOULD NOT change the
ETag (or the Last-Modified time) for a resource that has an unchanged ETag (or the Last-Modified time) for a resource that has an unchanged
body and location. The ETag represents the state of the body or body and location. The ETag represents the state of the entity body
contents of the resource. There is no similar way to tell if of the resource. There is no similar way to tell if properties have
properties have changed. changed.
8.7. Including Error Response Bodies 8.7. Including Error Response Bodies
HTTP and WebDAV did not use the bodies of most error responses for HTTP and WebDAV did not use the bodies of most error responses for
machine-parsable information until the specification for Versioning machine-parsable information until the specification for Versioning
Extensions to WebDAV introduced a mechanism to include more specific Extensions to WebDAV introduced a mechanism to include more specific
information in the body of an error response (Section 1.6 of information in the body of an error response (Section 1.6 of
[RFC3253]). The error body mechanism is appropriate to use with any [RFC3253]). The error body mechanism is appropriate to use with any
error response that may take a body but does not already have a body error response that may take a body but does not already have a body
defined. The mechanism is particularly appropriate when a status defined. The mechanism is particularly appropriate when a status
skipping to change at page 40, line 18 skipping to change at page 41, line 18
The PROPFIND method retrieves properties defined on the resource The PROPFIND method retrieves properties defined on the resource
identified by the Request-URI, if the resource does not have any identified by the Request-URI, if the resource does not have any
internal members, or on the resource identified by the Request-URI internal members, or on the resource identified by the Request-URI
and potentially its member resources, if the resource is a collection and potentially its member resources, if the resource is a collection
that has internal member URLs. All DAV compliant resources MUST that has internal member URLs. All DAV compliant resources MUST
support the PROPFIND method and the propfind XML element support the PROPFIND method and the propfind XML element
(Section 14.20) along with all XML elements defined for use with that (Section 14.20) along with all XML elements defined for use with that
element. element.
A client MUST submit a Depth header with a value of "0", "1", or A client may submit a Depth header with a value of "0", "1", or
"infinity" with a PROPFIND request. Servers MUST support "0" and "1" "infinity" with a PROPFIND request. Servers MUST support "0" and "1"
depth requests on WebDAV-compliant resources and SHOULD support depth requests on WebDAV-compliant resources and SHOULD support
"infinity" requests. In practice, support for infinite depth "infinity" requests. In practice, support for infinite depth
requests MAY be disabled, due to the performance and security requests MAY be disabled, due to the performance and security
concerns associated with this behavior. Since clients weren't concerns associated with this behavior. By default, the PROPFIND
required to include the Depth header in [RFC2518], servers SHOULD method without a Depth header MUST act as if a "Depth: infinity"
treat such a request as if a "Depth: infinity" header was included. header was included.
A client may submit a 'propfind' XML element in the body of the A client may submit a 'propfind' XML element in the body of the
request method describing what information is being requested. It is request method describing what information is being requested. It is
possible to: possible to:
o Request particular property values, by naming the properties o Request particular property values, by naming the properties
desired within the 'prop' element (the ordering of properties in desired within the 'prop' element (the ordering of properties in
here MAY be ignored by server), here MAY be ignored by server),
o Request property values for those properties defined in this o Request property values for those properties defined in this
skipping to change at page 41, line 45 skipping to change at page 42, line 45
validation mechanism for most properties. This method is both safe validation mechanism for most properties. This method is both safe
and idempotent (see Section 9.1 of [RFC2616]). and idempotent (see Section 9.1 of [RFC2616]).
9.1.1. PROPFIND Status Codes 9.1.1. PROPFIND Status Codes
This section, as with similar sections for other methods, provides This section, as with similar sections for other methods, provides
some guidance on error codes and preconditions or postconditions some guidance on error codes and preconditions or postconditions
(defined in Section 16) that might be particularly useful with (defined in Section 16) that might be particularly useful with
PROPFIND. PROPFIND.
403 Forbidden - A server MAY reject PROPFIND requests on collections 403 Forbidden (with the condition code 'propfind-finite-depth'
with depth header of "Infinity", in which case it SHOULD use this defined in Section 16) - A server MAY reject PROPFIND requests with
error with the precondition code 'propfind-finite-depth' inside the depth header of "Infinity".
error body.
9.1.2. Status Codes for Use in 'propstat' Element 9.1.2. Status Codes for Use in 'propstat' Element
In PROPFIND responses, information about individual properties is In PROPFIND responses, information about individual properties is
returned inside 'propstat' elements (see Section 14.22), each returned inside 'propstat' elements (see Section 14.22), each
containing an individual 'status' element containing information containing an individual 'status' element containing information
about the properties appearing in it. The list below summarizes the about the properties appearing in it. The list below summarizes the
most common status codes used inside 'propstat', however clients most common status codes used inside 'propstat', however clients
should be prepared to handle other 2/3/4/5xx series status codes as should be prepared to handle other 2/3/4/5xx series status codes as
well. well.
skipping to change at page 49, line 46 skipping to change at page 50, line 46
All DAV compliant resources MUST support the PROPPATCH method and All DAV compliant resources MUST support the PROPPATCH method and
MUST process instructions that are specified using the MUST process instructions that are specified using the
propertyupdate, set, and remove XML elements. Execution of the propertyupdate, set, and remove XML elements. Execution of the
directives in this method is, of course, subject to access control directives in this method is, of course, subject to access control
constraints. DAV compliant resources SHOULD support the setting of constraints. DAV compliant resources SHOULD support the setting of
arbitrary dead properties. arbitrary dead properties.
The request message body of a PROPPATCH method MUST contain the The request message body of a PROPPATCH method MUST contain the
propertyupdate XML element. propertyupdate XML element.
Servers MUST process PROPPATCH instructions in document order (an Servers MUST process the child elements of the propertyupdate XML
exception to the normal rule that ordering is irrelevant). element in the order they appear in the request body (an exception to
Instructions MUST either all be executed or none executed. Thus if the normal rule that ordering is irrelevant). Instructions MUST
any error occurs during processing all executed instructions MUST be either all be executed or none executed. Thus if any error occurs
undone and a proper error result returned. Instruction processing during processing all executed instructions MUST be undone and a
details can be found in the definition of the set and remove proper error result returned. Instruction processing details can be
instructions in Section 14.23 and Section 14.26. found in the definition of the set and remove instructions in
Section 14.23 and Section 14.26.
If a server attempts to make any of the property changes in a The response to a PROPPATCH request can be in two different formats:
PROPPATCH request (i.e. the request is not rejected for high-level should the server reject the request altogether (because of missing
errors before processing the body), the response MUST be a Multi- access rights, failed conditional headers, malformed request syntax,
Status response as described in Section 9.2.1. etc.), the status SHOULD be non-2xx HTTP status. On the other hand,
if the server did attempt the property modification, the response
status SHOULD be 207 Multistatus, using the 'multistatus' response
body format defined below (Section 9.2.1).
This method is idempotent, but not safe (see Section 9.1 of This method is idempotent, but not safe (see Section 9.1 of
[RFC2616]). Responses to this method MUST NOT be cached. [RFC2616]). Responses to this method MUST NOT be cached.
9.2.1. Status Codes for Use in 'propstat' Element 9.2.1. Status Codes for Use in 'propstat' Element
In PROPPATCH responses, information about individual properties is In PROPPATCH responses, information about individual properties is
returned inside 'propstat' elements (see Section 14.22), each returned inside 'propstat' elements (see Section 14.22), each
containing an individual 'status' element containing information containing an individual 'status' element containing information
about the properties appearing in it. The list below summarizes the about the properties appearing in it. The list below summarizes the
skipping to change at page 50, line 30 skipping to change at page 51, line 34
should be prepared to handle other 2/3/4/5xx series status codes as should be prepared to handle other 2/3/4/5xx series status codes as
well. well.
200 (OK) - The property set or change succeeded. Note that if this 200 (OK) - The property set or change succeeded. Note that if this
appears for one property, it appears for every property in the appears for one property, it appears for every property in the
response, due to the atomicity of PROPPATCH. response, due to the atomicity of PROPPATCH.
403 (Forbidden) - The client, for reasons the server chooses not to 403 (Forbidden) - The client, for reasons the server chooses not to
specify, cannot alter one of the properties. specify, cannot alter one of the properties.
403 (Forbidden): The client has attempted to set a protected 403 (Forbidden) (with the condition code 'cannot-modify-protected-
property, such as DAV:getetag. If returning this error, the server property' defined in Section 16) - The client has attempted to set a
SHOULD use the precondition code 'cannot-modify-protected-property' protected property, such as DAV:getetag.
inside the response body.
409 (Conflict) - The client has provided a value whose semantics are 409 (Conflict) - The client has provided a value whose semantics are
not appropriate for the property. not appropriate for the property.
424 (Failed Dependency) - The property change could not be made 424 (Failed Dependency) - The property change could not be made
because of another property change that failed. because of another property change that failed.
507 (Insufficient Storage) - The server did not have sufficient space 507 (Insufficient Storage) - The server did not have sufficient space
to record the property. to record the property.
skipping to change at page 53, line 28 skipping to change at page 54, line 28
9.3.1. MKCOL Status Codes 9.3.1. MKCOL Status Codes
In addition to the general status codes possible, the following In addition to the general status codes possible, the following
status codes have specific applicability to MKCOL: status codes have specific applicability to MKCOL:
201 (Created) - The collection was created. 201 (Created) - The collection was created.
403 (Forbidden) - This indicates at least one of two conditions: 1) 403 (Forbidden) - This indicates at least one of two conditions: 1)
the server does not allow the creation of collections at the given the server does not allow the creation of collections at the given
location in its URL namespace, or 2) the parent collection of the location in its URL namespace, or 2) the parent collection of the
Request-URI exists but cannot accept members. Request-URI exists but cannot accept members. [[anchor36: Language?
I think it can indicate lots of other things.]]
405 (Method Not Allowed) - MKCOL can only be executed on an unmapped 405 (Method Not Allowed) - MKCOL can only be executed on an unmapped
URL. URL.
409 (Conflict) - A collection cannot be made at the Request-URI until 409 (Conflict) - A collection cannot be made at the Request-URI until
one or more intermediate collections have been created. The server one or more intermediate collections have been created. The server
MUST NOT create those intermediate collections automatically. MUST NOT create those intermediate collections automatically.
415 (Unsupported Media Type) - The server does not support the
request body type (although bodies are legal on MKCOL requests, since
this specification doesn't define any, the server is likely not to
support any given body type).
507 (Insufficient Storage) - The resource does not have sufficient 507 (Insufficient Storage) - The resource does not have sufficient
space to record the state of the resource after the execution of this space to record the state of the resource after the execution of this
method. method.
9.3.2. Example - MKCOL 9.3.2. Example - MKCOL
This example creates a collection called /webdisc/xfiles/ on the This example creates a collection called /webdisc/xfiles/ on the
server www.example.com. server www.example.com.
>>Request >>Request
skipping to change at page 54, line 36 skipping to change at page 55, line 31
message body, the semantics of HEAD are unmodified when applied to message body, the semantics of HEAD are unmodified when applied to
collection resources. collection resources.
9.5. POST for Collections 9.5. POST for Collections
Since by definition the actual function performed by POST is Since by definition the actual function performed by POST is
determined by the server and often depends on the particular determined by the server and often depends on the particular
resource, the behavior of POST when applied to collections cannot be resource, the behavior of POST when applied to collections cannot be
meaningfully modified because it is largely undefined. Thus the meaningfully modified because it is largely undefined. Thus the
semantics of POST are unmodified when applied to a collection. semantics of POST are unmodified when applied to a collection.
[[anchor40: The fact that it's undefined in RF2616 really wouldn't
stop us to define it, I think.]]
9.6. DELETE Requirements 9.6. DELETE Requirements
DELETE is defined in [RFC2616], Section 9.7, to "delete the resource DELETE is defined in [RFC2616], Section 9.7, to "delete the resource
identified by the Request-URI". However, WebDAV changes some DELETE identified by the Request-URI". However, WebDAV changes some DELETE
handling requirements. handling requirements.
A server processing a successful DELETE request: A server processing a successful DELETE request:
MUST destroy locks rooted on the deleted resource o MUST destroy those locks where the lock root is the Request-URI.
MUST remove the mapping from the Request-URI to any resource. o MUST remove the mapping from the Request-URI to any resource.
Thus, after a successful DELETE operation (and in the absence of Thus, after a successful DELETE operation (and in the absence of
other actions) a subsequent GET/HEAD/PROPFIND request to the target other actions) a subsequent GET/HEAD/PROPFIND request to the target
Request-URI MUST return 404 (Not Found). Request-URI MUST return 404 (Not Found).
9.6.1. DELETE for Collections 9.6.1. DELETE for Collections
The DELETE method on a collection MUST act as if a "Depth: infinity" The DELETE method on a collection MUST act as if a "Depth: infinity"
header was used on it. A client MUST NOT submit a Depth header with header was used on it. A client MUST NOT submit a Depth header with
a DELETE on a collection with any value but infinity. a DELETE on a collection with any value but infinity.
skipping to change at page 55, line 29 skipping to change at page 56, line 29
Any headers included with DELETE MUST be applied in processing every Any headers included with DELETE MUST be applied in processing every
resource to be deleted. resource to be deleted.
When the DELETE method has completed processing it MUST result in a When the DELETE method has completed processing it MUST result in a
consistent URL namespace. consistent URL namespace.
If an error occurs deleting a member resource (a resource other than If an error occurs deleting a member resource (a resource other than
the resource identified in the Request-URI) then the response can be the resource identified in the Request-URI) then the response can be
a 207 (Multi-Status). Multi-Status is used here to indicate which a 207 (Multi-Status). Multi-Status is used here to indicate which
internal resources could NOT be deleted, including an error code internal resources could NOT be deleted, including an error code
which should help the client understand which resources caused the which should help the client understand what caused the failure. For
failure. For example, the Multi-Status body could include a response example, the Multi-Status body could include a response with status
with status 423 (Locked) if an internal resource was locked. 423 (Locked) if an internal resource was locked.
The server MAY return a 4xx status response, rather than a 207, if The server MAY return a 4xx status response, rather than a 207, if
the request failed completely. the request failed completely.
424 (Failed Dependency) status codes SHOULD NOT be in the 207 (Multi- 424 (Failed Dependency) status codes SHOULD NOT be in the 207 (Multi-
Status) response for DELETE. They can be safely left out because the Status) response for DELETE. They can be safely left out because the
client will know that the ancestors of a resource could not be client will know that the ancestors of a resource could not be
deleted when the client receives an error for the ancestor's progeny. deleted when the client receives an error for the ancestor's progeny.
Additionally 204 (No Content) errors SHOULD NOT be returned in the Additionally 204 (No Content) errors SHOULD NOT be returned in the
207 (Multi-Status). The reason for this prohibition is that 204 (No 207 (Multi-Status). The reason for this prohibition is that 204 (No
skipping to change at page 56, line 43 skipping to change at page 57, line 43
A PUT performed on an existing resource replaces the GET response A PUT performed on an existing resource replaces the GET response
entity of the resource. Properties defined on the resource may be entity of the resource. Properties defined on the resource may be
recomputed during PUT processing but are not otherwise affected. For recomputed during PUT processing but are not otherwise affected. For
example, if a server recognizes the content type of the request body, example, if a server recognizes the content type of the request body,
it may be able to automatically extract information that could be it may be able to automatically extract information that could be
profitably exposed as properties. profitably exposed as properties.
A PUT that would result in the creation of a resource without an A PUT that would result in the creation of a resource without an
appropriately scoped parent collection MUST fail with a 409 appropriately scoped parent collection MUST fail with a 409
(Conflict). (Conflict). [[anchor43: What does 'appropiately scoped' mean here.
Since there is the defined term 'namespace consistency', it should be
used here. --Manfred Baedke]]
A PUT request allows a client to indicate what media type an entity A PUT request allows a client to indicate what media type an entity
body has, and whether it should change if overwritten. Thus, a body has, and whether it should change if overwritten. Thus, a
client SHOULD provide a Content-Type for a new resource if any is client SHOULD provide a Content-Type for a new resource if any is
known. If the client does not provide a Content-Type for a new known. If the client does not provide a Content-Type for a new
resource, the server MAY create a resource with no Content-Type resource, the server MAY create a resource with no Content-Type
assigned, or it MAY attempt to assign a Content-Type. assigned, or it MAY attempt to assign a Content-Type.
Note that although a recipient ought generally to treat metadata Note that although a recipient ought generally to treat metadata
supplied with an HTTP request as authoritative, in practice there's supplied with an HTTP request as authoritative, in practice there's
no guarantee that a server will accept client-supplied metadata (e.g. no guarantee that a server will accept client-supplied metadata (e.g.
any request header beginning with "Content-"). Many servers do not any request header beginning with "Content-"). Many servers do not
allow configuring the Content-Type on a per-resource basis in the allow configuring the Content-Type on a per-resource basis in the
first place. Thus, clients can't always rely on the ability to first place. Thus, clients can't always rely on the ability to
directly influence the content type by including a Content-Type directly influence the content type by including a Content-Type
request header. request header. [[anchor44: (1) We shouldn't say "ought generally",
when the TAG says it's a SHOULD. (2) I think extending this to
heeaders other than Content-Type is just confusing here.]]
9.7.2. PUT for Collections 9.7.2. PUT for Collections
This specification does not define the behavior of the PUT method for This specification does not define the behavior of the PUT method for
existing collections. A PUT request to an existing collection MAY be existing collections. A PUT request to an existing collection MAY be
treated as an error (405 Method Not Allowed). treated as an error (405 Method Not Allowed).
The MKCOL method is defined to create collections. The MKCOL method is defined to create collections.
9.8. COPY Method 9.8. COPY Method
skipping to change at page 63, line 36 skipping to change at page 64, line 36
cases, a successful MOVE might result in the property being reported cases, a successful MOVE might result in the property being reported
as "Not Found" in subsequent requests. If the live properties will as "Not Found" in subsequent requests. If the live properties will
not work the same way at the destination, the server MAY fail the not work the same way at the destination, the server MAY fail the
request. request.
MOVE is frequently used by clients to rename a file without changing MOVE is frequently used by clients to rename a file without changing
its parent collection, so it's not appropriate to reset all live its parent collection, so it's not appropriate to reset all live
properties which are set at resource creation. For example, the DAV: properties which are set at resource creation. For example, the DAV:
creationdate property value SHOULD remain the same after a MOVE. creationdate property value SHOULD remain the same after a MOVE.
Dead properties MUST be moved along with the resource. Dead properties SHOULD be moved along with the resource.
9.9.2. MOVE for Collections 9.9.2. MOVE for Collections
A MOVE with "Depth: infinity" instructs that the collection A MOVE with "Depth: infinity" instructs that the collection
identified by the Request-URI be moved to the address specified in identified by the Request-URI be moved to the address specified in
the Destination header, and all resources identified by its internal the Destination header, and all resources identified by its internal
member URLs are to be moved to locations relative to it, recursively member URLs are to be moved to locations relative to it, recursively
through all levels of the collection hierarchy. through all levels of the collection hierarchy.
The MOVE method on a collection MUST act as if a "Depth: infinity" The MOVE method on a collection MUST act as if a "Depth: infinity"
skipping to change at page 64, line 43 skipping to change at page 65, line 43
NOT be returned as values in 207 (Multi-Status) responses from a NOT be returned as values in 207 (Multi-Status) responses from a
MOVE. These responses can be safely omitted because they are the MOVE. These responses can be safely omitted because they are the
default success codes. default success codes.
9.9.3. MOVE and the Overwrite Header 9.9.3. MOVE and the Overwrite Header
If a resource exists at the destination and the Overwrite header is If a resource exists at the destination and the Overwrite header is
"T" then prior to performing the move the server MUST perform a "T" then prior to performing the move the server MUST perform a
DELETE with "Depth: infinity" on the destination resource. If the DELETE with "Depth: infinity" on the destination resource. If the
Overwrite header is set to "F" then the operation will fail. Overwrite header is set to "F" then the operation will fail.
[[anchor53: Though it is defined later, mentioning the default here
might be clearer. --Manfred Baedke]]
9.9.4. Status Codes 9.9.4. Status Codes
In addition to the general status codes possible, the following In addition to the general status codes possible, the following
status codes have specific applicability to MOVE: status codes have specific applicability to MOVE:
201 (Created) - The source resource was successfully moved, and a new 201 (Created) - The source resource was successfully moved, and a new
URL mapping was created at the destination. URL mapping was created at the destination.
204 (No Content) - The source resource was successfully moved to a 204 (No Content) - The source resource was successfully moved to a
skipping to change at page 67, line 24 skipping to change at page 68, line 24
Any resource which supports the LOCK method MUST, at minimum, support Any resource which supports the LOCK method MUST, at minimum, support
the XML request and response formats defined herein. the XML request and response formats defined herein.
This method is neither idempotent nor safe (see Section 9.1 of This method is neither idempotent nor safe (see Section 9.1 of
[RFC2616]). Responses to this method MUST NOT be cached. [RFC2616]). Responses to this method MUST NOT be cached.
9.10.1. Creating a Lock on an Existing Resource 9.10.1. Creating a Lock on an Existing Resource
A LOCK request to an existing resource will create a lock on the A LOCK request to an existing resource will create a lock on the
resource identified by the Request-URI, provided the resource is not resource identified by the Request-URI, provided the resource is not
already locked with a conflicting lock. The resource identified in already locked with a conflicting lock. The Request-URI becomes the
the Request-URI becomes the root of the lock. Lock method requests root of the lock. Lock method requests to create a new lock MUST
to create a new lock MUST have an XML request body. The server MUST have an XML request body. The server MUST preserve the information
preserve the information provided by the client in the 'owner' field provided by the client in the 'owner' XML element. The LOCK request
in the request body when the lock information is requested. The LOCK MAY have a Timeout header.
request MAY have a Timeout header.
When a new lock is created, the LOCK response: When a new lock is created, the LOCK response:
o MUST contain a body with the value of the DAV:lockdiscovery o MUST contain a body with the value of the DAV:lockdiscovery
property in a prop XML element. This MUST contain the full property in a prop XML element. This MUST contain the full
information about the lock just granted, while information about information about the lock just granted, while information about
other (shared) locks is OPTIONAL. other (shared) locks is OPTIONAL.
o MUST include the Lock-Token response header with the token o MUST include the Lock-Token response header with the token
associated with the new lock. associated with the new lock.
skipping to change at page 68, line 43 skipping to change at page 69, line 42
(Locked)). Additionally, if the resource causing the failure was not (Locked)). Additionally, if the resource causing the failure was not
the resource requested, then the server SHOULD include a 'response' the resource requested, then the server SHOULD include a 'response'
element for the Request-URI as well, with a 'status' element element for the Request-URI as well, with a 'status' element
containing 424 Failed Dependency. containing 424 Failed Dependency.
If no Depth header is submitted on a LOCK request then the request If no Depth header is submitted on a LOCK request then the request
MUST act as if a "Depth:infinity" had been submitted. MUST act as if a "Depth:infinity" had been submitted.
9.10.4. Locking Unmapped URLs 9.10.4. Locking Unmapped URLs
A successful LOCK method MUST result in the creation of an empty A successful LOCK request to an unmapped URL causes that URL to
resource which is locked (and which is not a collection), when a become mapped, and the new resource being referred to being locked.
resource did not previously exist at that URL. Later on, the lock See Section 7.3 for further details.
may go away but the empty resource remains. Empty resources MUST
then appear in PROPFIND responses including that URL in the response
scope. A server MUST respond successfully to a GET request to an
empty resource, either by using a 204 No Content response, or by
using 200 OK with a Content-Length header indicating zero length
9.10.5. Lock Compatibility Table 9.10.5. Lock Compatibility Table
The table below describes the behavior that occurs when a lock The table below describes the behavior that occurs when a lock
request is made on a resource. request is made on a resource.
+--------------------------+----------------+-------------------+ +--------------------------+----------------+-------------------+
| Current State | Shared Lock OK | Exclusive Lock OK | | Current State | Shared Lock OK | Exclusive Lock OK |
+--------------------------+----------------+-------------------+ +--------------------------+----------------+-------------------+
| None | True | True | | None | True | True |
skipping to change at page 70, line 5 skipping to change at page 70, line 48
409 (Conflict) - A resource cannot be created at the destination 409 (Conflict) - A resource cannot be created at the destination
until one or more intermediate collections have been created. The until one or more intermediate collections have been created. The
server MUST NOT create those intermediate collections automatically. server MUST NOT create those intermediate collections automatically.
423 (Locked), potentially with 'no-conflicting-lock' precondition 423 (Locked), potentially with 'no-conflicting-lock' precondition
code - There is already a lock on the resource which is not code - There is already a lock on the resource which is not
compatible with the requested lock (see lock compatibility table compatible with the requested lock (see lock compatibility table
above). above).
412 (Precondition Failed), with 'lock-token-matches-request-uri' 412 (Precondition Failed), with 'lock-token-submitted' precondition
precondition code - The LOCK request was made with a If header, code - The LOCK request was made with an If header, indicating that
indicating that the client wishes to refresh the given lock. the client wishes to refresh the given lock. However, the Request-
However, the Request-URI did not fall within the scope of the lock URI did not fall within the scope of the lock identified by the
identified by the token. The lock may have a scope that does not token. The lock may have a scope that does not include the Request-
include the Request-URI, or the lock could have disappeared, or the URI, or the lock could have disappeared, or the token may be invalid.
token may be invalid.
9.10.7. Example - Simple Lock Request 9.10.7. Example - Simple Lock Request
>>Request >>Request
LOCK /workspace/webdav/proposal.doc HTTP/1.1 LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com Host: example.com
Timeout: Infinite, Second-4100000000 Timeout: Infinite, Second-4100000000
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxxx
skipping to change at page 74, line 27 skipping to change at page 75, line 27
The UNLOCK method removes the lock identified by the lock token in The UNLOCK method removes the lock identified by the lock token in
the Lock-Token request header. The Request-URI MUST identify a the Lock-Token request header. The Request-URI MUST identify a
resource within the scope of the lock. resource within the scope of the lock.
Note that use of Lock-Token header to provide the lock token is not Note that use of Lock-Token header to provide the lock token is not
consistent with other state-changing methods which all require an If consistent with other state-changing methods which all require an If
header with the lock token. Thus, the If header is not needed to header with the lock token. Thus, the If header is not needed to
provide the lock token. Naturally when the If header is present it provide the lock token. Naturally when the If header is present it
has its normal meaning as a conditional header. has its normal meaning as a conditional header.
For a successful response to this method, the server MUST delete the For a successful response to this method, the server MUST remove the
lock entirely. lock from the resource identified by the Request-URI and from all
other resources included in the lock.
If all resources which have been locked under the submitted lock If all resources which have been locked under the submitted lock
token can not be unlocked then the UNLOCK request MUST fail. token can not be unlocked then the UNLOCK request MUST fail.
A successful response to an UNLOCK method does not mean that the A successful response to an UNLOCK method does not mean that the
resource is necessarily unlocked. It means that the specific lock resource is necessarily unlocked. It means that the specific lock
corresponding to the specified token no longer exists. corresponding to the specified token no longer exists.
Any DAV compliant resource which supports the LOCK method MUST Any DAV compliant resource which supports the LOCK method MUST
support the UNLOCK method. support the UNLOCK method.
skipping to change at page 76, line 17 skipping to change at page 77, line 17
All DAV headers follow the same basic formatting rules as HTTP All DAV headers follow the same basic formatting rules as HTTP
headers. This includes rules like line continuation and how to headers. This includes rules like line continuation and how to
combine (or separate) multiple instances of the same header using combine (or separate) multiple instances of the same header using
commas. commas.
WebDAV adds two new conditional headers to the set defined in HTTP: WebDAV adds two new conditional headers to the set defined in HTTP:
the If and Overwrite headers. the If and Overwrite headers.
10.1. DAV Header 10.1. DAV Header
DAV = "DAV" ":" #( compliance-class ) DAV = "DAV" ":" #( compliance-class )
compliance-class = ( "1" | "2" | "3" | extend ) compliance-class = ( "1" | "2" | "3" | extend )
extend = Coded-URL | token extend = Coded-URL | token
Coded-URL = "<" absolute-URI ">" ; token: defined in [RFC2616], Section 2.2
; No linear white space (LWS) allowed in Coded-URL Coded-URL = "<" absolute-URI ">"
; absolute-URI is defined in RFC3986 ; No Linear White Space (LWS) allowed in
; Coded-URL
; absolute-URI: defined in [RFC3986], Section 4.3
This general-header appearing in the response indicates that the This general-header appearing in the response indicates that the
resource supports the DAV schema and protocol as specified. All DAV resource supports the DAV schema and protocol as specified. All DAV
compliant resources MUST return the DAV header with compliance-class compliant resources MUST return the DAV header with compliance-class
"1" on all OPTIONS responses. In cases where WebDAV is only "1" on all OPTIONS responses. In cases where WebDAV is only
supported in part of the server namespace, an OPTIONS request to non- supported in part of the server namespace, an OPTIONS request to non-
WebDAV resources (including "/") SHOULD NOT advertise WebDAV support. WebDAV resources (including "/") SHOULD NOT advertise WebDAV support.
The value is a comma-separated list of all compliance class The value is a comma-separated list of all compliance class
identifiers that the resource supports. Class identifiers may be identifiers that the resource supports. Identifiers can appear in
Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can any order. Identifiers that are standardized through the IETF RFC
appear in any order. Identifiers that are standardized through the process are tokens, but other identifiers SHOULD be Coded-URLs to
IETF RFC process are tokens, but other identifiers SHOULD be Coded- encourage uniqueness.
URLs to encourage uniqueness.
A resource must show class 1 compliance if it shows class 2 or 3
compliance. In general, support for one compliance class does not
entail support for any other, and in particular, support for
compliance class 3 does not require support for compliance class 2.
Please refer to Section 18 for more details on compliance classes Please refer to Section 18 for more details on compliance classes
defined in this specification. defined in this specification.
Note that many WebDAV servers do not advertise WebDAV support in Note that many WebDAV servers do not advertise WebDAV support in
response to "OPTIONS *". response to "OPTIONS *".
As a request header, this header allows the client to advertise As a request header, this header allows the client to advertise
compliance with named features when the server needs that compliance with named features when the server needs that
information. Clients SHOULD NOT send this header unless a standards information. Clients SHOULD NOT send this header unless a standards
track specification requires it. Any extension that makes use of track specification requires it. Any extension that makes use of
skipping to change at page 78, line 13 skipping to change at page 79, line 11
The Depth header only specifies the behavior of the method with The Depth header only specifies the behavior of the method with
regards to internal members. If a resource does not have internal regards to internal members. If a resource does not have internal
members then the Depth header MUST be ignored. members then the Depth header MUST be ignored.
10.3. Destination Header 10.3. Destination Header
The Destination request header specifies the URI which identifies a The Destination request header specifies the URI which identifies a
destination resource for methods such as COPY and MOVE, which take destination resource for methods such as COPY and MOVE, which take
two URIs as parameters. two URIs as parameters.
Destination = "Destination" ":" Simple-ref Destination = "Destination" ":" Simple-ref (see Section 8.3)
If the Destination value is an absolute-URI (Section 4.3 of If the Destination value is an absolute-URI (Section 4.3 of
[RFC3986]), it may name a different server (or different port or [RFC3986]), it may name a different server (or different port or
scheme). If the source server cannot attempt a copy to the remote scheme). If the source server cannot attempt a copy to the remote
server, it MUST fail the request. Note that copying and moving server, it MUST fail the request[[anchor62: Yes. What else should the
server do? :) --Manfred Baedke]]. Note that copying and moving
resources to remote servers is not fully defined in this resources to remote servers is not fully defined in this
specification (e.g. specific error conditions). specification (e.g. specific error conditions).
If the Destination value is too long or otherwise unacceptable, the If the Destination value is too long or otherwise unacceptable, the
server SHOULD return 400 (Bad Request), ideally with helpful server SHOULD return 400 (Bad Request), ideally with helpful
information in an error body. information in an error body.
10.4. If Header 10.4. If Header
The If request header is intended to have similar functionality to The If request header is intended to have similar functionality to
the If-Match header defined in Section 14.24 of [RFC2616]. However the If-Match header defined in Section 14.24 of [RFC2616]. However
the If header handles any state token as well as ETags. A typical the If header handles any state token as well as ETags. A typical
example of a state token is a lock token, and lock tokens are the example of a state token is a lock token, and lock tokens are the
only state tokens defined in this specification. only state tokens defined in this specification.
10.4.1. Purpose 10.4.1. Purpose
The If header has two distinct purposes: The If header has two distinct purposes:
o The first purpose is to make a request conditional by supplying a o The first purpose is to make a request conditional by supplying a
series of state lists with conditions that match tokens and ETags series of state lists. If none of the state lists match the state
to specific resource. If this header is evaluated and all state of the resource it applies to, the request MUST fail with a 412
lists fail, then the request MUST fail with a 412 (Precondition (Precondition Failed) status. Otherwise, the request may succeed.
Failed) status. On the other hand, the request can succeed only The matching functions for ETags and state tokens are defined in
if one of the described state lists succeeds. The success Section 10.4.4 below.
criteria for state lists and matching functions are defined in
Section 10.4.3 and Section 10.4.4.
o Additionally, the mere fact that a state token appears in an If o Additionally, the mere fact that a state token appears in an If
header means that it has been "submitted" with the request. In header means that it has been "submitted" with the request. In
general, this is used to indicate that the client has knowledge of general, this is used to indicate that the client has knowledge of
that state token. The semantics for submitting a state token that state token. The semantics for submitting a state token
depend on its type (for lock tokens, please refer to Section 6). depend on its type (for lock tokens, please refer to Section 6).
Note that these two purposes need to be treated distinctly: a state Note that these two purposes need to be treated distinctly: a state
token counts as being submitted independently of whether the server token counts as being submitted independently of whether the server
actually has evaluated the state list it appears in, and also actually has evaluated the state list it appears in, and also
skipping to change at page 80, line 5 skipping to change at page 80, line 48
Each List consists of one or more Conditions. Each Condition is Each List consists of one or more Conditions. Each Condition is
defined in terms of an entity-tag or state-token, potentially negated defined in terms of an entity-tag or state-token, potentially negated
by the prefix "Not". by the prefix "Not".
Note that the If header syntax does not allow multiple instances of Note that the If header syntax does not allow multiple instances of
If headers in a single request. However, the HTTP header syntax If headers in a single request. However, the HTTP header syntax
allows extending single header values across multiple lines, by allows extending single header values across multiple lines, by
inserting a line break followed by whitespace (see [RFC2616], Section inserting a line break followed by whitespace (see [RFC2616], Section
4.2). 4.2).
10.4.3. List Evaluation 10.4.3. Evaluation
A Condition that consists of a single entity-tag or state-token A Condition that consists of a single entity-tag or state-token
evaluates to true if the resource matches the described state (where evaluates to true if the resource matches the described state (where
the individual matching functions are defined below in the individual matching functions are defined below in
Section 10.4.4). Prefixing it with "Not" reverses the result of the Section 10.4.4). Prefixing it with "Not" reverses the result of the
evaluation (thus, the "Not" applies only to the subsequent entity-tag evaluation (thus, the "Not" applies only to the subsequent entity-tag
or state-token). or state-token).
Each List production describes a series of conditions. The whole Each List production describes a series of conditions. The whole
list evaluates to true if and only if each condition evaluates to list evaluates to true if and only if each condition evaluates to
skipping to change at page 80, line 49 skipping to change at page 81, line 44
Matching entity tag: Where the entity tag matches an entity tag Matching entity tag: Where the entity tag matches an entity tag
associated with the identified resource. Servers MUST use either the associated with the identified resource. Servers MUST use either the
weak or the strong comparison function defined in Section 13.3.3 of weak or the strong comparison function defined in Section 13.3.3 of
[RFC2616]. [RFC2616].
Matching state token: Where there is an exact match between the state Matching state token: Where there is an exact match between the state
token in the If header and any state token on the identified token in the If header and any state token on the identified
resource. A lock state token is considered to match if the resource resource. A lock state token is considered to match if the resource
is anywhere in the scope of the lock. is anywhere in the scope of the lock.
Handling unmapped URLs: for both ETags and state tokens, treat as if Note that for the purpose of matching entity tags and state tokens,
the URL identified a resource that exists but does not have the the URL being unmapped should be treated the same way as if the
specified state. resource existed, but did not have the specified state.
10.4.5. If Header and Non-DAV Aware Proxies 10.4.5. If Header and Non-DAV Aware Proxies
Non-DAV aware proxies will not honor the If header, since they will Non-DAV aware proxies will not honor the If header, since they will
not understand the If header, and HTTP requires non-understood not understand the If header, and HTTP requires non-understood
headers to be ignored. When communicating with HTTP/1.1 proxies, the headers to be ignored. When communicating with HTTP/1.1 proxies, the
client MUST use the "Cache-Control: no-cache" request header so as to client MUST use the "Cache-Control: no-cache" request header so as to
prevent the proxy from improperly trying to service the request from prevent the proxy from improperly trying to service the request from
its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache"
request header MUST be used for the same reason. request header MUST be used for the same reason.
skipping to change at page 81, line 45 skipping to change at page 82, line 40
matches-etag("I am an ETag") matches-etag("I am an ETag")
) )
OR OR
( (
matches-etag("I am another ETag") matches-etag("I am another ETag")
) )
10.4.7. Example - using "Not" with No-tag Production 10.4.7. Example - using "Not" with No-tag Production
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>) <urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
This If header requires that the resource must not be locked with a This If header requires that the resource must not be locked with a
lock having the lock token lock having the lock token
urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked by a urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked by a
lock with the lock token lock with the lock token
urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092. urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.
10.4.8. Example - causing a Condition to always evaluate to True 10.4.8. Example - causing a Condition to always evaluate to True
There may be cases where a client wishes to submit state tokens, but There may be cases where a client wishes to submit state tokens, but
skipping to change at page 84, line 4 skipping to change at page 84, line 48
request to create a new lock. request to create a new lock.
10.6. Overwrite Header 10.6. Overwrite Header
Overwrite = "Overwrite" ":" ("T" | "F") Overwrite = "Overwrite" ":" ("T" | "F")
The Overwrite request header specifies whether the server should The Overwrite request header specifies whether the server should
overwrite a resource mapped to the destination URL during a COPY or overwrite a resource mapped to the destination URL during a COPY or
MOVE. A value of "F" states that the server must not perform the MOVE. A value of "F" states that the server must not perform the
COPY or MOVE operation if the destination URL does map to a resource. COPY or MOVE operation if the destination URL does map to a resource.
If the overwrite header is not included in a COPY or MOVE request If the overwrite header is not included in a COPY or MOVE request
then the resource MUST treat the request as if it has an overwrite then the resource MUST treat the request as if it has an overwrite
header of value "T". While the Overwrite header appears to duplicate header of value "T". While the Overwrite header appears to duplicate
the functionality of using a "If-Match: *" header (see [RFC2616]), the functionality of using a "If-Match: *" header (see [RFC2616]),
If-Match applies only to the Request-URI, and not to the Destination If-Match applies only to the Request-URI, and not to the Destination
of a COPY or MOVE. of a COPY or MOVE.
If a COPY or MOVE is not performed due to the value of the Overwrite If a COPY or MOVE is not performed due to the value of the Overwrite
header, the method MUST fail with a 412 (Precondition Failed) status header, the method MUST fail with a 412 (Precondition Failed) status
code. The server MUST do authorization checks before checking this code. The server MUST do authorization checks before checking this
or any conditional header. header.
All DAV compliant resources MUST support the Overwrite header. All DAV compliant resources MUST support the Overwrite header.
10.7. Timeout Request Header 10.7. Timeout Request Header
TimeOut = "Timeout" ":" 1#TimeType TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite") TimeType = ("Second-" DAVTimeOutVal | "Infinite")
; No LWS allowed within TimeType ; No LWS allowed within TimeType
DAVTimeOutVal = 1*DIGIT DAVTimeOutVal = 1*DIGIT
skipping to change at page 86, line 14 skipping to change at page 87, line 14
12. Use of HTTP Status Codes 12. Use of HTTP Status Codes
These HTTP codes are not redefined, but their use is somewhat These HTTP codes are not redefined, but their use is somewhat
extended by WebDAV methods and requirements. In general, many HTTP extended by WebDAV methods and requirements. In general, many HTTP
status codes can be used in response to any request, not just in status codes can be used in response to any request, not just in
cases described in this document. Note also that WebDAV servers are cases described in this document. Note also that WebDAV servers are
known to use 300-level redirect responses (and early interoperability known to use 300-level redirect responses (and early interoperability
tests found clients unprepared to see those responses). A 300-level tests found clients unprepared to see those responses). A 300-level
response MUST NOT be used when the server has created a new resource response MUST NOT be used when the server has created a new resource
in response to the request. in response to the request. [[anchor69: Don't we usually say "3xx
class" instead of "300-level"?]]
12.1. 412 Precondition Failed 12.1. 412 Precondition Failed
Any request can contain a conditional header defined in HTTP (If- Any request can contain a conditional header defined in HTTP (If-
Match, If-Modified-Since, etc.) or the "If" or "Overwrite" Match, If-Modified-Since, etc.) or the "If" or "Overwrite"
conditional headers defined in this specification. If the server conditional headers defined in this specification. If the server
evaluates a conditional header, and if that condition fails to hold, evaluates a conditional header, and if that condition fails to hold,
then this error code MUST be returned. On the other hand, if the then this error code MUST be returned. On the other hand, if the
client did not include a conditional header in the request, then the client did not include a conditional header in the request, then the
server MUST NOT use this status code. server MUST NOT use this status code.
12.2. 414 Request-URI Too Long
This status code is used in HTTP 1.1 only for Request-URIs, not URIs
in other locations.
13. Multi-Status Response 13. Multi-Status Response
A Multi-Status response conveys information about multiple resources A Multi-Status response conveys information about multiple resources
in situations where multiple status codes might be appropriate. The in situations where multiple status codes might be appropriate. The
default Multi-Status response body is a text/xml or application/xml default Multi-Status response body is a text/xml or application/xml
HTTP entity with a 'multistatus' root element. Further elements HTTP entity with a 'multistatus' root element. Further elements
contain 200, 300, 400, and 500 series status codes generated during contain 200, 300, 400, and 500 series status codes generated during
the method invocation. 100 series status codes SHOULD NOT be recorded the method invocation. 100 series status codes SHOULD NOT be recorded
in a 'response' XML element. in a 'response' XML element.
skipping to change at page 88, line 18 skipping to change at page 89, line 18
normally take a Location header to indicate the new URI for the normally take a Location header to indicate the new URI for the
single resource redirected from the Request-URI. Multi-Status single resource redirected from the Request-URI. Multi-Status
responses contain many resource addresses, but the original responses contain many resource addresses, but the original
definition in [RFC2518] did not have any place for the server to definition in [RFC2518] did not have any place for the server to
provide the new URI for redirected resources. This specification provide the new URI for redirected resources. This specification
does define a 'location' element for this information (see does define a 'location' element for this information (see
Section 14.9). Servers MUST use this new element with redirect Section 14.9). Servers MUST use this new element with redirect
responses in Multi-Status. responses in Multi-Status.
Clients encountering redirected resources in Multi-Status MUST NOT Clients encountering redirected resources in Multi-Status MUST NOT
rely on the 'location' element being present with a new URI. If the rely on the 'location' element being present with a new URI.
[[anchor73: Inconsistency: if servers MUST include the location
element, why can't clients rely on it being present???]] If the
element is not present, the client MAY reissue the request to the element is not present, the client MAY reissue the request to the
individual redirected resource, because the response to that request individual redirected resource, because the response to that request
can be redirected with a Location header containing the new URI. can be redirected with a Location header containing the new URI.
[[anchor74: Language: clients MAY do whatever they want. This is
13.3. Internal Status Codes nothing normative.]]
Section 9.2.1, Section 9.1.2, Section 9.6.1, Section 9.8.3 and
Section 9.9.2 define various status codes used in Multi-Status
responses. This specification does not define the meaning of other
status codes that could appear in these responses.
14. XML Element Definitions 14. XML Element Definitions
In this section, the final line of each section gives the element In this section, the final line of each section gives the element
type declaration using the format defined in [REC-XML]. The "Value" type declaration using the format defined in [REC-XML]. The "Value"
field, where present, specifies further restrictions on the allowable field, where present, specifies further restrictions on the allowable
contents of the XML element using BNF (i.e., to further restrict the contents of the XML element using BNF (i.e., to further restrict the
values of a PCDATA element). Note that all of the elements defined values of a PCDATA element). Note that all of the elements defined
here may be extended according to the rules defined in Section 17. here may be extended according to the rules defined in Section 17.
All elements defined here are in the "DAV:" namespace. All elements defined here are in the "DAV:" namespace.
skipping to change at page 90, line 46 skipping to change at page 91, line 46
14.7. href XML Element 14.7. href XML Element
Name: href Name: href
Purpose: MUST contain a URI or a relative reference. Purpose: MUST contain a URI or a relative reference.
Description: There may be limits on the value of 'href' depending Description: There may be limits on the value of 'href' depending
on the context of its use. Refer to the specification text where on the context of its use. Refer to the specification text where
'href' is used to see what limitations apply in each case. 'href' is used to see what limitations apply in each case.
Value: Simple-ref Value: Simple-ref (see Section 8.3)
<!ELEMENT href (#PCDATA)> <!ELEMENT href (#PCDATA)>
14.8. include XML Element 14.8. include XML Element
Name: include Name: include
Purpose: Any child element represents the name of a property to be Purpose: Any child element represents the name of a property to be
included in the PROPFIND response. All elements inside an included in the PROPFIND response. All elements inside an
'include' XML element MUST define properties related to the 'include' XML element MUST define properties related to the
skipping to change at page 93, line 23 skipping to change at page 94, line 23
nature of the response. If this value is available an application nature of the response. If this value is available an application
may use it instead of presenting the individual response may use it instead of presenting the individual response
descriptions contained within the responses. descriptions contained within the responses.
<!ELEMENT multistatus (response*, responsedescription?) > <!ELEMENT multistatus (response*, responsedescription?) >
14.17. owner XML Element 14.17. owner XML Element
Name: owner Name: owner
Purpose: Provides information about the creator of a lock. Purpose: Holds client-supplied information about the principal on
whose behalf the lock was created.
Description: Allows a client to provide information sufficient for Description: Allows a client to provide information sufficient for
either directly contacting a principal (such as a telephone number either directly contacting a principal (such as a telephone number
or Email URI), or for discovering the principal (such as the URL or Email URI), or for discovering the principal (such as the URL
of a homepage) who created a lock. The value provided MUST be of a homepage) who created a lock. The value provided MUST be
treated as a dead property in terms of XML Information Item treated as a dead property in terms of XML Information Item
preservation. The server MUST NOT alter the value unless the preservation. The server MUST NOT alter the value unless the
owner value provided by the client is empty. For a certain amount owner value provided by the client is empty. For a certain amount
of interoperability between different client implementations, if of interoperability between different client implementations, if
clients have URI-formatted contact information for the lock clients have URI-formatted contact information for the lock
skipping to change at page 96, line 4 skipping to change at page 97, line 4
element. This requirement is necessary in order to keep element. This requirement is necessary in order to keep
processing costs for a response to linear time. Essentially, this processing costs for a response to linear time. Essentially, this
prevents having to search in order to group together all the prevents having to search in order to group together all the
responses by 'href'. There are, however, no requirements responses by 'href'. There are, however, no requirements
regarding ordering based on 'href' values. The optional regarding ordering based on 'href' values. The optional
precondition/postcondition element and 'responsedescription' text precondition/postcondition element and 'responsedescription' text
can provide additional information about this resource relative to can provide additional information about this resource relative to
the request or result. the request or result.
<!ELEMENT response (href, ((href*, status)|(propstat+)), <!ELEMENT response (href, ((href*, status)|(propstat+)),
error?, responsedescription? , location?) > error?, responsedescription?, location?) >
Note: the usage of the 'error' element inside 'response' is an
incompatible change to [RFC3253], Section 1.6, paragraph 2 (where
'error' appeared as a child element of 'responsedescription').
14.25. responsedescription XML Element 14.25. responsedescription XML Element
Name: responsedescription Name: responsedescription
Purpose: Contains information about a status response within a Purpose: Contains information about a status response within a
Multi-Status. Multi-Status.
Description: Provides information suitable to be presented to a Description: Provides information suitable to be presented to a
user. user.
skipping to change at page 98, line 26 skipping to change at page 99, line 26
request. There may be other requests which would result in a change request. There may be other requests which would result in a change
to a protected property (as when a LOCK request affects the value of to a protected property (as when a LOCK request affects the value of
DAV:lockdiscovery). Note that a given property could be protected on DAV:lockdiscovery). Note that a given property could be protected on
one type of resource, but not protected on another type of resource. one type of resource, but not protected on another type of resource.
A computed property is one with a value defined in terms of a A computed property is one with a value defined in terms of a
computation (based on the content and other properties of that computation (based on the content and other properties of that
resource, or even of some other resource). A computed property is resource, or even of some other resource). A computed property is
always a protected property. always a protected property.
COPY and MOVE behavior refers to local COPY and MOVE operations.
For properties defined based on HTTP GET response headers (DAV:get*), For properties defined based on HTTP GET response headers (DAV:get*),
the header value could include LWS as defined in [RFC2616], Section the header value could include LWS as defined in [RFC2616], Section
4.2. Server implementors SHOULD strip LWS from these values before 4.2. Server implementors MUST strip LWS from these values before
using as WebDAV property values. using as WebDAV property values.
Note that all property elements can be extended according to the
rules defined in Section 17.
15.1. creationdate Property 15.1. creationdate Property
Name: creationdate Name: creationdate
Purpose: Records the time and date the resource was created. Purpose: Records the time and date the resource was created.
Value: date-time (defined in [RFC3339], see the ABNF in section Value: date-time (defined in [RFC3339], see the ABNF in section
5.6.) 5.6.)
Protected: MAY be protected. Some servers allow DAV:creationdate Protected: MAY be protected. Some servers allow DAV:creationdate
skipping to change at page 99, line 33 skipping to change at page 100, line 33
[RFC2518] might have made this a protected property as this is a [RFC2518] might have made this a protected property as this is a
new requirement. new requirement.
COPY/MOVE behaviour: This property value SHOULD be preserved in COPY/MOVE behaviour: This property value SHOULD be preserved in
COPY and MOVE operations. COPY and MOVE operations.
Description: Contains a description of the resource that is Description: Contains a description of the resource that is
suitable for presentation to a user. This property is defined on suitable for presentation to a user. This property is defined on
the resource, and hence SHOULD have the same value independent of the resource, and hence SHOULD have the same value independent of
the Request-URI used to retrieve it (thus computing this property the Request-URI used to retrieve it (thus computing this property
based on the Request-URI is deprecated). While generic clients based on the Request-URI is deprecated).
might display the property value to end users, client UI designers
must understand that the method for identifying resources is still While generic clients might display the property value to end
the URL. Changes to DAV:displayname do not issue moves or copies users, client UI designers must understand that the method for
to the server, but simply change a piece of meta-data on the identifying resources is still the URL. Changes to DAV:
individual resource. Two resources can have the same DAV: displayname do not issue moves or copies to the server, but simply
displayname value even within the same collection. change a piece of meta-data on the individual resource. Two
resources can have the same DAV:displayname value even within the
same collection.
<!ELEMENT displayname (#PCDATA) > <!ELEMENT displayname (#PCDATA) >
15.3. getcontentlanguage Property 15.3. getcontentlanguage Property
Name: getcontentlanguage Name: getcontentlanguage
Purpose: Contains the Content-Language header value (from Section Purpose: Contains the Content-Language header value (from Section
14.12 of [RFC2616]) as it would be returned by a GET without 14.12 of [RFC2616]) as it would be returned by a GET without
accept headers. accept headers.
skipping to change at page 100, line 32 skipping to change at page 101, line 32
Name: getcontentlength Name: getcontentlength
Purpose: Contains the Content-Length header returned by a GET Purpose: Contains the Content-Length header returned by a GET
without accept headers. without accept headers.
Value: See Section 14.13 of [RFC2616]. Value: See Section 14.13 of [RFC2616].
Protected: This property is computed, therefore protected. Protected: This property is computed, therefore protected.
Description: The DAV:getcontentlength property MUST be defined on Description: The DAV:getcontentlength property SHOULD be defined on
any DAV compliant resource that returns the Content-Length header any DAV compliant resource that returns the Content-Length header
in response to a GET. in response to a GET.
COPY/MOVE behaviour: This property value is dependent on the size COPY/MOVE behaviour: This property value is dependent on the size
of the destination resource, not the value of the property on the of the destination resource, not the value of the property on the
source resource. source resource.
<!ELEMENT getcontentlength (#PCDATA) > <!ELEMENT getcontentlength (#PCDATA) >
15.5. getcontenttype Property 15.5. getcontenttype Property
skipping to change at page 102, line 13 skipping to change at page 103, line 13
without accept headers. without accept headers.
Value: rfc1123-date (defined in Section 3.3.1 of [RFC2616]) Value: rfc1123-date (defined in Section 3.3.1 of [RFC2616])
Protected: SHOULD be protected because some clients may rely on the Protected: SHOULD be protected because some clients may rely on the
value for appropriate caching behavior, or on the value of the value for appropriate caching behavior, or on the value of the
Last-Modified header to which this property is linked. Last-Modified header to which this property is linked.
COPY/MOVE behaviour: This property value is dependent on the last COPY/MOVE behaviour: This property value is dependent on the last
modified date of the destination resource, not the value of the modified date of the destination resource, not the value of the
property on the source resource. Note that some server property on the source resource. Note that since [RFC2616]
implementations use the file system date modified value for the requires clients to use ETags where provided, a server
DAV:getlastmodified value, and this can be preserved in a MOVE implementing ETags can count on clients using a much better
even when the HTTP Last-Modified value SHOULD change. Note that
since [RFC2616] requires clients to use ETags where provided, a
server implementing ETags can count on clients using a much better
mechanism than modification dates for offline synchronization or mechanism than modification dates for offline synchronization or
cache control. Also note the considerations in Section 8.8. cache control. Also note the considerations in Section 8.8.
Description: Note that the last-modified date on a resource SHOULD Description: Note that the last-modified date on a resource SHOULD
only reflect changes in the body (the GET responses) of the only reflect changes in the body (the GET responses) of the
resource. A change in a property only SHOULD NOT cause the last- resource. A change in a property only SHOULD NOT cause the last-
modified date to change, because clients MAY rely on the last- modified date to change, because clients MAY rely on the last-
modified date to know when to overwrite the existing body. The modified date to know when to overwrite the existing body. The
DAV:getlastmodified property MUST be defined on any DAV compliant DAV:getlastmodified property MUST be defined on any DAV compliant
resource that returns the Last-Modified header in response to a resource that returns the Last-Modified header in response to a
GET. GET. [[anchor94: Language: starts with a note (IMHO unneeded), but
then makes a normative statement.]]
<!ELEMENT getlastmodified (#PCDATA) > <!ELEMENT getlastmodified (#PCDATA) >
15.8. lockdiscovery Property 15.8. lockdiscovery Property
Name: lockdiscovery Name: lockdiscovery
Purpose: Describes the active locks on a resource Purpose: Describes the active locks on a resource
Protected: MUST be protected. Clients change the list of locks Protected: MUST be protected. Clients change the list of locks
through LOCK and UNLOCK, not through PROPPATCH. through LOCK and UNLOCK, not through PROPPATCH.
COPY/MOVE behaviour: The value of this property depends on the lock COPY/MOVE behaviour: The value of this property depends on the lock
state of the destination, not on the locks of the source resource. state of the destination, not on the locks of the source resource.
Recall that locks are not moved in a MOVE operation. Recall that locks are not moved in a MOVE operation.
Description: Returns a listing of who has a lock, what type of lock Description: Returns a listing of who has a lock, what type of lock
he has, the timeout type and the time remaining on the timeout, he has, the timeout type and the time remaining on the timeout,
and the associated lock token. Owner information MAY be omitted and the associated lock token. The server is free to withhold any
if it is considered sensitive. If there are no locks, but the or all of this information if the requesting principal does not
server supports locks, the property will be present but contain have sufficient access rights to see the requested data. If there
zero 'activelock' elements. If there is one or more lock, an are no locks, but the server supports locks, the property will be
'activelock' element appears for each lock on the resource. This present but contain zero 'activelock' elements. If there is one
property is NOT lockable with respect to write locks (Section 7). or more lock, an 'activelock' element appears for each lock on the
resource. This property is NOT lockable with respect to write
locks (Section 7).
<!ELEMENT lockdiscovery (activelock)* > <!ELEMENT lockdiscovery (activelock)* >
15.8.1. Example - Retrieving DAV:lockdiscovery 15.8.1. Example - Retrieving DAV:lockdiscovery
>>Request >>Request
PROPFIND /container/ HTTP/1.1 PROPFIND /container/ HTTP/1.1
Host: www.example.com Host: www.example.com
Content-Length: xxxx Content-Length: xxxx
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D='DAV:'> <D:propfind xmlns:D='DAV:'>
<D:prop><D:lockdiscovery/></D:prop> <D:prop><D:lockdiscovery/></D:prop>
</D:propfind> </D:propfind>
>>Response >>Response
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'> <D:multistatus xmlns:D='DAV:'>
<D:response> <D:response>
<D:href>http://www.example.com/container/</D:href> <D:href>http://www.example.com/container/</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:lockdiscovery> <D:lockdiscovery>
<D:activelock> <D:activelock>
<D:locktype><D:write/></D:locktype> <D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope> <D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth> <D:depth>0</D:depth>
<D:owner>Jane Smith</D:owner> <D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout> <D:timeout>Infinite</D:timeout>
<D:locktoken> <D:locktoken>
<D:href <D:href
>urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href> >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>
</D:locktoken> </D:locktoken>
<D:lockroot> <D:lockroot>
<D:href>http://www.example.com/container/</D:href> <D:href>http://www.example.com/container/</D:href>
</D:lockroot> </D:lockroot>
</D:activelock> </D:activelock>
</D:lockdiscovery> </D:lockdiscovery>
</D:prop> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status> <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
This resource has a single exclusive write lock on it, with an This resource has a single exclusive write lock on it, with an
infinite timeout. infinite timeout.
15.9. resourcetype Property 15.9. resourcetype Property
Name: resourcetype Name: resourcetype
Purpose: Specifies the nature of the resource. Purpose: Specifies the nature of the resource.
Protected: SHOULD be protected. Resource type is generally decided Protected: SHOULD be protected. Resource type is generally decided
through the operation creating the resource (MKCOL vs PUT), not by through the operation creating the resource (MKCOL vs PUT), not by
PROPPATCH. PROPPATCH. [[anchor96: Language confusing: why "generally"?]]
COPY/MOVE behaviour: Generally a COPY/MOVE of a resource results in COPY/MOVE behaviour: Generally a COPY/MOVE of a resource results in
the same type of resource at the destination. the same type of resource at the destination. [[anchor97: That's
true for the collection type, but I doubt it's true in general
(where types often depend on specific locations in the server
namespace).]]
Description: MUST be defined on all DAV compliant resources. Each Description: MUST be defined on all DAV compliant resources. Each
child element identifies a specific type the resource belongs to, child element identifies a specific type the resource belongs to,
such as 'collection', which is the only resource type defined by such as 'collection', which is the only resource type defined by
this specification (see Section 14.3). If the element contains this specification (see Section 14.3). If the element contains
the 'collection' child element plus additional unrecognized the 'collection' child element plus additional unrecognized
elements, it should generally be treated as a collection. If the elements, it should generally be treated as a collection. If the
element contains no recognized child elements, it should be element contains no recognized child elements, it should be
treated as a non-collection resource. The default value is empty. treated as a non-collection resource. The default value is empty.
This element MUST NOT contain text or mixed content. Any custom This element MUST NOT contain text or mixed content. Any custom
skipping to change at page 105, line 41 skipping to change at page 106, line 44
Purpose: To provide a listing of the lock capabilities supported by Purpose: To provide a listing of the lock capabilities supported by
the resource. the resource.
Protected: MUST be protected. Servers determine what lock Protected: MUST be protected. Servers determine what lock
mechanisms are supported, not clients. mechanisms are supported, not clients.
COPY/MOVE behaviour: This property value is dependent on the kind COPY/MOVE behaviour: This property value is dependent on the kind
of locks supported at the destination, not on the value of the of locks supported at the destination, not on the value of the
property at the source resource. Servers attempting to COPY to a property at the source resource. Servers attempting to COPY to a
destination should not attempt to set this property at the destination should not attempt to set this property at the
destination. destination. [[anchor99: That's generally true for any protected
property, right?]]
Description: Returns a listing of the combinations of scope and Description: Returns a listing of the combinations of scope and
access types which may be specified in a lock request on the access types which may be specified in a lock request on the
resource. Note that the actual contents are themselves controlled resource. Note that the actual contents are themselves controlled
by access controls so a server is not required to provide by access controls so a server is not required to provide
information the client is not authorized to see. This property is information the client is not authorized to see. This property is
NOT lockable with respect to write locks (Section 7). NOT lockable with respect to write locks (Section 7).
<!ELEMENT supportedlock (lockentry)* > <!ELEMENT supportedlock (lockentry)* >
skipping to change at page 107, line 34 skipping to change at page 108, line 34
of a top-level 'error' element in the response body, unless otherwise of a top-level 'error' element in the response body, unless otherwise
negotiated by the request, along with an appropriate response status. negotiated by the request, along with an appropriate response status.
The most common response status codes are 403 (Forbidden) if the The most common response status codes are 403 (Forbidden) if the
request should not be repeated because it will always fail, and 409 request should not be repeated because it will always fail, and 409
(Conflict) if it is expected that the user might be able to resolve (Conflict) if it is expected that the user might be able to resolve
the conflict and resubmit the request. The 'error' element MAY the conflict and resubmit the request. The 'error' element MAY
contain child elements with specific error information and MAY be contain child elements with specific error information and MAY be
extended with any custom child elements. extended with any custom child elements.
This mechanism does not take the place of using a correct numeric This mechanism does not take the place of using a correct numeric
status code as defined here or in HTTP, because the client MUST status code as defined here or in HTTP, because the client must
always be able to take a reasonable course of action based only on always be able to take a reasonable course of action based only on
the numeric code. However, it does remove the need to define new the numeric code. However, it does remove the need to define new
numeric codes. The new machine-readable codes used for this purpose numeric codes. The new machine-readable codes used for this purpose
are XML elements classified as preconditions and postconditions, so are XML elements classified as preconditions and postconditions, so
naturally any group defining a new condition code can use their own naturally any group defining a new condition code can use their own
namespace. As always, the "DAV:" namespace is reserved for use by namespace. As always, the "DAV:" namespace is reserved for use by
IETF-chartered WebDAV working groups. IETF-chartered WebDAV working groups.
A server supporting this specification SHOULD use the XML error A server supporting this specification SHOULD use the XML error
whenever a precondition or postcondition defined in this document is whenever a precondition or postcondition defined in this document is
skipping to change at page 108, line 29 skipping to change at page 109, line 29
collection member "/workspace/webdav/proposal.doc". collection member "/workspace/webdav/proposal.doc".
Some other useful preconditions and postconditions have been defined Some other useful preconditions and postconditions have been defined
in other specifications extending WebDAV, such as [RFC3744] (see in other specifications extending WebDAV, such as [RFC3744] (see
particularly Section 7.1.1), [RFC3253], and [RFC3648]. particularly Section 7.1.1), [RFC3253], and [RFC3648].
All these elements are in the "DAV:" namespace. If not specified All these elements are in the "DAV:" namespace. If not specified
otherwise, the content for each condition's XML element is defined to otherwise, the content for each condition's XML element is defined to
be empty. be empty.
Name: lock-token-matches-request-uri 16.1. DAV:lock-token-matches-request-uri (Precondition)
Use with: 409 Conflict A request may include a Lock-Token header to identify a lock for the
purpose of UNLOCK. However, if the Request-URI does not fall within
the scope of the lock identified by the token, the server SHOULD use
this condition code.
Purpose: (precondition) -- A request may include a Lock-Token header 16.2. DAV:lock-token-submitted (Precondition)
to identify a lock for the UNLOCK method. However, if the
Request-URI does not fall within the scope of the lock identified
by the token, the server SHOULD use this error. The lock may have
a scope that does not include the Request-URI, or the lock could
have disappeared, or the token may be invalid.
Name: lock-token-submitted (precondition) If a request would
Use with: 423 Locked o modify the content for a locked resource, a dead property of a
locked resource, a live property that is defined to be lockable
for a locked resource,
Purpose: The request could not succeed because a lock token should o an internal member URI of a locked collection, or
have been submitted. This element, if present, MUST contain at
least one URL of a locked resource that prevented the request. In
cases of MOVE, COPY and DELETE where collection locks are
involved, it can be difficult for the client to find out which
locked resource made the request fail -- but the server is only
resonsible for returning one such locked resource. The server MAY
return every locked resource that prevented the request from
succeeding if it knows them all.
<!ELEMENT lock-token-submitted (href+) > o refresh a lock that locks that resource,
Name: no-conflicting-lock (precondition) the request MUST fail unless the lock-token for that lock is
submitted in the request. An internal member URI of a collection is
considered to be modified if it is added, removed, or identifies a
different resource.
Use with: Typically 423 Locked <!ELEMENT lock-token-submitted (href)* >
Purpose: A LOCK request failed due the presence of an already Servers SHOULD insert DAV:href elements for the URLs of each root of
existing conflicting lock. Note that a lock can be in conflict a lock for which a lock token was needed, unless that URL identifies
although the resource to which the request was directed is only the same resource to that the request was sent.
indirectly locked. In this case, the precondition code can be
used to inform the client about the resource which is the root of
the conflicting lock, avoiding a separate lookup of the
"lockdiscovery" property.
<!ELEMENT no-conflicting-lock (href)* > 16.3. DAV:no-conflicting-lock (Precondition)
Name: no-external-entities This precondition code can be used to signal that a lock request
failed due the presence of an already existing conflicting lock.
Note that a lock can be in conflict although the resource to which
the request was directed is only indirectly locked. In this case,
the precondition code can be used to inform the client about the
resource which is the root of the conflicting lock, avoiding a
separate lookup of the "lockdiscovery" property. [[anchor101: Make
sure the document actually defines "indirectly locked".]]
Use with: 403 Forbidden <!ELEMENT no-conflicting-lock (href)* >
Purpose: (precondition) -- If the server rejects a client request Servers SHOULD insert a DAV:href element for the URL of the root of
because the request body contains an external entity, the server the conflicting lock.
SHOULD use this error.
Name: preserved-live-properties 16.4. DAV:no-external-entities (Precondition)
Use with: 409 Conflict If the request body is XML, and the server does not support external
entities, this condition code can be used to signal the problem (see
also Section 20.6).
Purpose: (postcondition) -- The server received an otherwise-valid 16.5. DAV:preserved-live-properties (postcondition)
MOVE or COPY request, but cannot maintain the live properties with
the same behavior at the destination. It may be that the server
only supports some live properties in some parts of the
repository, or simply has an internal error.
Name: propfind-finite-depth Servers may reject MOVE requests, if they cannot maintain live
properties with the same behaviour at the destination URL. In this
case, this postcondition name may be used to signal the failure
condition. [[q-copy-live-prop: Does this really apply to COPY as
well???]]
Use with: 403 Forbidden 16.6. DAV:propfind-finite-depth (Precondition)
Purpose: (precondition) -- This server does not allow infinite-depth Used to signal that a request was rejected because the server did not
PROPFIND requests on collections. allow a value of "infinity" for the "Depth" request header.
Name: cannot-modify-protected-property 16.7. DAV:cannot-modify-protected-property (Precondition)
Use with: 403 Forbidden
Purpose: (precondition) -- The client attempted to set a protected An attempt to modify a property that is defined by this document, as
property in a PROPPATCH (such as DAV:getetag). See also being protected for that kind of resource, MUST fail (see [RFC3253],
[RFC3253], Section 3.12. Section 3.12).
17. XML Extensibility in DAV 17. XML Extensibility in DAV
The XML namespace extension ([REC-XML-NAMES]) is used in this The XML namespace extension ([REC-XML-NAMES]) is used in this
specification in order to allow for new XML elements to be added specification in order to allow for new XML elements to be added
without fear of colliding with other element names. Although WebDAV without fear of colliding with other element names. Although WebDAV
request and response bodies can be extended by arbitrary XML request and response bodies can be extended by arbitrary XML
elements, which can be ignored by the message recipient, an XML elements, which can be ignored by the message recipient, an XML
element in the "DAV:" namespace SHOULD NOT be used in the request or element in the "DAV:" namespace SHOULD NOT be used in the request or
response body unless that XML element is explicitly defined in an response body unless that XML element is explicitly defined in an
skipping to change at page 111, line 47 skipping to change at page 111, line 47
Processing instructions in XML SHOULD be ignored by recipients. Processing instructions in XML SHOULD be ignored by recipients.
Thus, specifications extending WebDAV SHOULD NOT use processing Thus, specifications extending WebDAV SHOULD NOT use processing
instructions to define normative behavior. instructions to define normative behavior.
XML DTD fragments are included for all the XML elements defined in XML DTD fragments are included for all the XML elements defined in
this specification. However, correct XML will not be valid according this specification. However, correct XML will not be valid according
to any DTD due to namespace usage and extension rules. In to any DTD due to namespace usage and extension rules. In
particular: particular:
o Elements (from this specification) are in the "DAV:" namespace, o Element names use the "DAV:" namespace,
o Element ordering is irrelevant unless otherwise stated, o Element ordering is irrelevant unless otherwise stated,
o Extension attributes MAY be added, o Extension attributes (attributes not already defined by this
o For element type definitions of "ANY", the normative text specification) may be added, and MUST be ignored by recipients
definition for that element defines what can be in it and what unless recognized),
that means.
o For element type definitions of "#PCDATA", extension elements MUST
NOT be added.
o For other element type definitions, including "EMPTY", extension
elements MAY be added.
Note that this means that elements containing elements cannot be o Extension elements (elements not already defined by this
extended to contain text, and vice versa. specification) may be added for element type definitions other
than "ANY" or "#PCDATA", and MUST be ignored by recipients unless
recognized).
With DTD validation relaxed by the rules above, the constraints With DTD validation relaxed by the rules above, the constraints
described by the DTD fragments are normative (see for example described by the DTD fragments are normative (see for example
Appendix A). A recipient of a WebDAV message with an XML body MUST Appendix A). A recipient of a WebDAV message with an XML body MUST
NOT validate the XML document according to any hard-coded or NOT validate the XML document according to any hard-coded or
dynamically-declared DTD. dynamically-declared DTD.
Note that this section describes backwards-compatible extensibility Note that this section describes backwards-compatible extensibility
rules. There might also be times when an extension is designed not rules. There might also be times when an extension is designed not
to be backwards-compatible, for example defining an extension that to be backwards-compatible, for example defining an extension that
skipping to change at page 115, line 14 skipping to change at page 115, line 14
19. Internationalization Considerations 19. Internationalization Considerations
In the realm of internationalization, this specification complies In the realm of internationalization, this specification complies
with the IETF Character Set Policy [RFC2277]. In this specification, with the IETF Character Set Policy [RFC2277]. In this specification,
human-readable fields can be found either in the value of a property, human-readable fields can be found either in the value of a property,
or in an error message returned in a response entity body. In both or in an error message returned in a response entity body. In both
cases, the human-readable content is encoded using XML, which has cases, the human-readable content is encoded using XML, which has
explicit provisions for character set tagging and encoding, and explicit provisions for character set tagging and encoding, and
requires that XML processors read XML elements encoded, at minimum, requires that XML processors read XML elements encoded, at minimum,
using the UTF-8 [RFC3629] and UTF-16 encodings of the ISO 10646 using the UTF-8 ([RFC3629]) and UTF-16 ([RFC2781]) encodings of the
multilingual plane. XML examples in this specification demonstrate ISO 10646 multilingual plane. XML examples in this specification
use of the charset parameter of the Content-Type header, as defined demonstrate use of the charset parameter of the Content-Type header,
in [RFC3023], as well as the XML declarations which provide charset as defined in [RFC3023], as well as the XML declarations which
identification information for MIME and XML processors. provide charset identification information for MIME and XML
processors.
XML also provides a language tagging capability for specifying the XML also provides a language tagging capability for specifying the
language of the contents of a particular XML element. The "xml:lang" language of the contents of a particular XML element. The "xml:lang"
attribute appears on an XML element to identify the language of its attribute appears on an XML element to identify the language of its
content and attributes. See [REC-XML] for definitions of values and content and attributes. See [REC-XML] for definitions of values and
scoping. scoping.
WebDAV applications MUST support the character set tagging, character WebDAV applications MUST support the character set tagging, character
set encoding, and the language tagging functionality of the XML set encoding, and the language tagging functionality of the XML
specification. Implementors of WebDAV applications are strongly specification. Implementors of WebDAV applications are strongly
skipping to change at page 119, line 28 skipping to change at page 119, line 28
state that an XML processor may, at its discretion, include the state that an XML processor may, at its discretion, include the
external XML entity. external XML entity.
External XML entities have no inherent trustworthiness and are External XML entities have no inherent trustworthiness and are
subject to all the attacks that are endemic to any HTTP GET request. subject to all the attacks that are endemic to any HTTP GET request.
Furthermore, it is possible for an external XML entity to modify the Furthermore, it is possible for an external XML entity to modify the
DTD, and hence affect the final form of an XML document, in the worst DTD, and hence affect the final form of an XML document, in the worst
case significantly modifying its semantics, or exposing the XML case significantly modifying its semantics, or exposing the XML
processor to the security risks discussed in [RFC3023]. Therefore, processor to the security risks discussed in [RFC3023]. Therefore,
implementers must be aware that external XML entities should be implementers must be aware that external XML entities should be
treated as untrustworthy. If a server implementor chooses not to treated as untrustworthy. If a server rejects a request due to the
handle external XML entities, it SHOULD respond to requests presence of external entities, it SHOULD include the 'no-external-
containing external entities with the 'no-external-entities' entities' condition code in the response body.
condition code.
There is also the scalability risk that would accompany a widely There is also the scalability risk that would accompany a widely
deployed application which made use of external XML entities. In deployed application which made use of external XML entities. In
this situation, it is possible that there would be significant this situation, it is possible that there would be significant
numbers of requests for one external XML entity, potentially numbers of requests for one external XML entity, potentially
overloading any server which fields requests for the resource overloading any server which fields requests for the resource
containing the external XML entity. containing the external XML entity.
Furthermore, there's also a risk based on the evaluation of "internal Furthermore, there's also a risk based on the evaluation of "internal
entities" as defined in Section 4.2.2 of [REC-XML]. A small, entities" as defined in Section 4.2.2 of [REC-XML]. A small,
skipping to change at page 121, line 5 skipping to change at page 120, line 46
trust relationship with the author that is publishing the document. trust relationship with the author that is publishing the document.
Servers that allow clients to publish arbitrary content can usefully Servers that allow clients to publish arbitrary content can usefully
implement precautions to check that content published to the server implement precautions to check that content published to the server
is not harmful to other clients. Servers could do this by techniques is not harmful to other clients. Servers could do this by techniques
such as restricting the types of content that is allowed to be such as restricting the types of content that is allowed to be
published and running virus and malware detection software on published and running virus and malware detection software on
published content. Servers can also mitigate the risk by having published content. Servers can also mitigate the risk by having
appropriate access restriction and authentication of users that are appropriate access restriction and authentication of users that are
allowed to publish content to the server. allowed to publish content to the server.
One specific attack scenario deserves special mention here: with the
arrival of the "XMLHttpRequest" API (see [WD-XMLHttpRequest]), user
agents have acquired the capability to submit arbitrary HTTP requests
against the server the content was obtained from. With the well-
known semantics of HTTP verbs such as PUT and DELETE, the following
attack becomes possible:
1. Alice prepares an HTML page with embedded Javascript code that
will submit a DELETE request against the URI
http://www.example.com/users/bob/ (a resource she has not write
access to, but Bob has).
2. Alice stores this HTML page at
http://www.example.com/users/alice/readme.html, a resource she
has write access to.
3. Alice emails Bob a link to
http://www.example.com/users/alice/readme.html, for which he has
read access once authenticated.
4. Bob follows the link, authenticates, and the embedded script code
executes the DELETE request against
http://www.example.com/users/bob/ while being authenticated as
Bob.
This attack relies on the common risk of collaboratively authoring
resources on the same server, which requires a certain amount of
trust between the users. However, even an action usually considered
as "safe", such as opening an HTML page in a web browser, can cause
arbitrary HTTP methods to be invoked. Note that WebDAV isn't the
root cause for this vulnerability, it just makes it more visible.
Potential steps to reduce the risks associated with this attack
include:
o Separating server domains for authoring (read/write) and publicly
serving content.
o Disallowing certain content (such as scripts in HTML pages)
altogether, as discussed above.
o Using user agents that follow Section 9.1.1 of [RFC2616], in that
they do not allow unsafe methods to be executed without making the
user aware of the consequences - unfortunately, none of today's
browsers is doing that.
21. IANA Considerations 21. IANA Considerations
21.1. New URI Schemes 21.1. New URI Schemes
This specification defines two URI schemes: This specification defines two URI schemes (see [RFC3986] and
[RFC4395]):
1. the "opaquelocktoken" scheme defined in Appendix C, and 1. the "opaquelocktoken" scheme defined in Appendix C, and
2. the "DAV" URI scheme, which historically was used in [RFC2518] to 2. the "DAV" URI scheme, which historically was used in [RFC2518] to
disambiguate WebDAV property and XML element names and which disambiguate WebDAV property and XML element names and which
continues to be used for that purpose in this specification and continues to be used for that purpose in this specification and
others extending WebDAV. Creation of identifiers in the "DAV:" others extending WebDAV. Creation of identifiers in the "DAV:"
namespace is controlled by the IETF. namespace is controlled by the IETF.
Note that defining new URI schemes for XML namespaces is now Note that defining new URI schemes for XML namespaces is now
skipping to change at page 121, line 32 skipping to change at page 122, line 33
21.2. XML Namespaces 21.2. XML Namespaces
XML namespaces disambiguate WebDAV property names and XML elements. XML namespaces disambiguate WebDAV property names and XML elements.
Any WebDAV user or application can define a new namespace in order to Any WebDAV user or application can define a new namespace in order to
create custom properties or extend WebDAV XML syntax. IANA does not create custom properties or extend WebDAV XML syntax. IANA does not
need to manage such namespaces, property names or element names. need to manage such namespaces, property names or element names.
21.3. Message Header Fields 21.3. Message Header Fields
The message header fields below should be added to the permanent The message header fields below should be updated in the permanent
registry (see [RFC3864]). registry (see [RFC3864] for the registration process, and [RFC4229]
for the initial registration being updated by this specification).
Note: the "Status-URI" header defined in Section 9.7 of [RFC2518]
has been removed in this specification; its IANA registration
should continue to reference RFC2518.
21.3.1. DAV 21.3.1. DAV
Header field name: DAV Header field name: DAV
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
skipping to change at page 123, line 4 skipping to change at page 124, line 10
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 10.5) Specification document: this specification (Section 10.5)
21.3.6. Overwrite 21.3.6. Overwrite
Header field name: Overwrite Header field name: Overwrite
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 10.6) Specification document: this specification (Section 10.6)
21.3.7. Timeout 21.3.7. Timeout
Header field name: Timeout Header field name: Timeout
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 10.7) Specification document: this specification (Section 10.7)
21.4. HTTP Status Codes
This specification defines the HTTP status codes
o 207 Multi-Status (Section 11.1),
o 422 Unprocessable Entity (Section 11.2),
o 423 Locked (Section 11.3),
o 424 Failed Dependency (Section 11.4) and
o 507 Insufficient Storage (Section 11.5),
to be updated in the registry at
<http://www.iana.org/assignments/http-status-codes>.
Note: the HTTP status code 102 (Processing) (defined in Section
10.1 of [RFC2518]) has been removed in this specification; its
IANA registration should continue to reference RFC2518.
22. Acknowledgements 22. Acknowledgements
A specification such as this thrives on piercing critical review and [[anchor117: I think three sections of thanks is way too much, this
withers from apathetic neglect. The authors gratefully acknowledge probably should be collapsed into a single one.]] A specification
the contributions of the following people, whose insights were so such as this thrives on piercing critical review and withers from
apathetic neglect. The authors gratefully acknowledge the
contributions of the following people, whose insights were so
valuable at every stage of our work. valuable at every stage of our work.
Contributors to RFC2518 Contributors to RFC2518
Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan
Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners- Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-
Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith
Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee
Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan
Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis
skipping to change at page 128, line 10 skipping to change at page 129, line 10
1555 N. Technology Way, 1555 N. Technology Way,
M/S ORM F111, M/S ORM F111,
Orem, UT 84097-2399. Orem, UT 84097-2399.
Email: dcjensen@novell.com. Email: dcjensen@novell.com.
25. References 25. References
25.1. Normative References 25.1. Normative References
[REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and [REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", W3C REC-xml-20040204, February 2004, Edition)", W3C REC-xml-20060816, August 2006,
<http://www.w3.org/TR/2004/REC-xml-20040204>. <http://www.w3.org/TR/2006/REC-xml-20060816>.
[REC-XML-INFOSET] [REC-XML-INFOSET]
Cowan, J. and R. Tobin, "XML Information Set (Second Cowan, J. and R. Tobin, "XML Information Set (Second
Edition)", W3C REC-xml-infoset-20040204, February 2004, Edition)", W3C REC-xml-infoset-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-infoset-20040204/>. <http://www.w3.org/TR/2004/REC-xml-infoset-20040204/>.
[REC-XML-NAMES] [REC-XML-NAMES]
Bray, T., Hollander, D., and A. Layman, "Namespaces in Bray, T., Hollander, D., Layman, A., and R. Tobin,
XML", W3C REC-xml-names-19990114, January 1999, "Namespaces in XML 1.0 (Second Edition)", W3C REC-xml-
<http://www.w3.org/TR/1999/REC-xml-names-19990114>. names-20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-names-20060816>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
25.2. Informational References 25.2. Informational References
[RFC2291] Slein, J., Vitali, F., Whitehead, E., and D. Durand, [RFC2291] Slein, J., Vitali, F., Whitehead, E., and D. Durand,
"Requirements for a Distributed Authoring and Versioning "Requirements for a Distributed Authoring and Versioning
Protocol for the World Wide Web", RFC 2291, February 1998. Protocol for the World Wide Web", RFC 2291, February 1998.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
Jensen, "HTTP Extensions for Distributed Authoring -- Jensen, "HTTP Extensions for Distributed Authoring --
WEBDAV", RFC 2518, February 1999. WEBDAV", RFC 2518, February 1999.
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, February 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
Whitehead, "Versioning Extensions to WebDAV Whitehead, "Versioning Extensions to WebDAV
(Web Distributed Authoring and Versioning)", RFC 3253, (Web Distributed Authoring and Versioning)", RFC 3253,
March 2002. March 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, STD 63, November 2003.
[RFC3648] Whitehead, J. and J. Reschke, Ed., "Web Distributed [RFC3648] Whitehead, J. and J. Reschke, Ed., "Web Distributed
Authoring and Versioning (WebDAV) Ordered Collections Authoring and Versioning (WebDAV) Ordered Collections
Protocol", RFC 3648, December 2003. Protocol", RFC 3648, December 2003.
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV) Access Distributed Authoring and Versioning (WebDAV) Access
Control Protocol", RFC 3744, May 2004. Control Protocol", RFC 3744, May 2004.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC4229] Nottingham, M. and J. Mogul, "HTTP Header Field
Registrations", RFC 4229, December 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006.
[WD-XMLHttpRequest]
van Kesteren, A., "The XMLHttpRequest Object", W3C WD-
XMLHttpRequest-20070227, February 2007,
<http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070227/>.
Work in progress.
URIs
[1] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=48>
[2] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=143>
[3] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=152>
[4] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=161>
[5] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=169>
[6] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=177>
[7] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=181>
[8] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=202>
[9] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=213>
[10] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=217>
[11] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=220>
[12] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=227>
[13] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=229>
[14] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=235>
[15] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=237>
[16] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=238>
[17] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=239>
[18] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=240>
[19] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=241>
[20] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=242>
[21] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=243>
[22] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=244>
[23] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=245>
[24] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=247>
[25] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=248>
[26] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=250>
[27] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=251>
[28] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=252>
[29] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=254>
[30] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=255>
[31] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=258>
[32] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=259>
[33] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=260>
[34] <http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=264>
Appendix A. Notes on Processing XML Elements Appendix A. Notes on Processing XML Elements
A.1. Notes on Empty XML Elements A.1. Notes on Empty XML Elements
XML supports two mechanisms for indicating that an XML element does XML supports two mechanisms for indicating that an XML element does
not have any content. The first is to declare an XML element of the not have any content. The first is to declare an XML element of the
form <A></A>. The second is to declare an XML element of the form form <A></A>. The second is to declare an XML element of the form
<A/>. The two XML elements are semantically identical. <A/>. The two XML elements are semantically identical.
A.2. Notes on Illegal XML Processing A.2. Notes on Illegal XML Processing
skipping to change at page 134, line 5 skipping to change at page 139, line 5
extension will never be used twice with the associated UUID. extension will never be used twice with the associated UUID.
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
; UUID is defined in Section 3 of [RFC4122]. Note that LWS ; UUID is defined in Section 3 of [RFC4122]. Note that LWS
; is not allowed between elements of ; is not allowed between elements of
; this production. ; this production.
Extension = path Extension = path
; path is defined in Section 3.3 of [RFC3986] ; path is defined in Section 3.3 of [RFC3986]
Appendix D. Lock-null Resources Appendix D. Lock-Null Resources
The original WebDAV model for locking unmapped URLs created "lock-
null resources". This model was over-complicated and some
interoperability and implementation problems were discovered. The
new WebDAV model for locking unmapped URLs (see Section 7.3) creates
"locked empty resources". Lock-null resources are deprecated. This
section discusses the original model briefly because clients MUST be
able to handle either model.
In the original "lock-null resource" model, which is no longer
recommended for implementation:
o A lock-null resource sometimes appeared as "Not Found". The
server responds with a 404 or 405 to any method except for PUT,
MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
o A lock-null resource does however show up as a member of its This specification deprecates the "Lock-Null Resources" (LNRs)
parent collection. defined in Section 7.4 of [RFC2518], and replaces them with empty
locked regular resources (see Section 7.3). However, it's still
legal for servers to implement the deprecated model.
o The server removes the lock-null resource entirely (its URI A LNR differs from an empty locked resource in the following aspects:
becomes unmapped) if its lock goes away before it is converted to
a regular resource. Recall that locks go away not only when they
expire or are unlcoked, but are also removed if a resource is
renamed or moved, or if any parent collection is renamed or moved.
o The server converts the lock-null resource into a regular resource o It MUST respond with a 404 (Not Found) or 405 (Method Not Allowed)
if a PUT request to the URL is successful. to any methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and
UNLOCK.
o The server converts the lock-null resource into a collection if a o Most of its live properties, such as all the get* properties, will
MKCOL request to the URL is successful (though interoperability have no value as a lock-null resource does not support the GET
experience showed that not all servers followed this requirement). method. It MUST have defined values for lockdiscovery and
supportedlock properties.
o Property values were defined for DAV:lockdiscovery and DAV: o Until a method such as PUT or MKCOL is successfully executed on
supportedlock properties but not necessarily for other properties the lock-null resource the resource MUST stay in the lock-null
like DAV:getcontenttype. state. However, once a PUT or MKCOL is successfully executed on a
lock-null resource the resource ceases to be in the lock-null
state. (Note that an LNR thus can be used to create a collection,
which is not possible with the simplified empty locked resource
model anymore.)
Clients can easily interoperate both with servers that support the o If it is unlocked, for any reason, without a PUT, MKCOL, or
old model "lock-null resources" and the recommended model of "locked similar method having been successfully executed upon it then the
empty resources" by only attempting PUT after a LOCK to an unmapped resource MUST return to the null state. (Note that with an empty
URL, not MKCOL or GET. locked resource, an empty regular resource would remain in place.)
D.1. Guidance for Clients Using LOCK to Create Resources D.1. Guidance for Clients Using LOCK to Create Resources
A WebDAV client implemented to this specification might find servers A WebDAV client implemented to this specification might find servers
that create lock-null resources (implemented before this that create lock-null resources (implemented before this
specification using [RFC2518]) as well as servers that create locked specification using [RFC2518]) as well as servers that create locked
empty resources. The response to the LOCK request will not indicate empty resources. The response to the LOCK request will not indicate
what kind of resource was created. There are a few techniques which what kind of resource was created. There are a few techniques which
help the client deal with either type. help the client deal with either type.
skipping to change at page 139, line 6 skipping to change at page 144, line 6
o The Destination and If request headers now allow absolute paths in o The Destination and If request headers now allow absolute paths in
addition to full URIs (see Section 8.3). This may be useful for addition to full URIs (see Section 8.3). This may be useful for
clients operating through a reverse proxy that does rewrite the clients operating through a reverse proxy that does rewrite the
Host request header, but not WebDAV-specific headers. Host request header, but not WebDAV-specific headers.
o This specification adopts the error marshalling extensions and the o This specification adopts the error marshalling extensions and the
"precondition/postcondition" terminology defined in [RFC3253] (see "precondition/postcondition" terminology defined in [RFC3253] (see
Section 16). Related to that, it adds the "error" XML element Section 16). Related to that, it adds the "error" XML element
inside multistatus response bodies (see Section 14.5, however note inside multistatus response bodies (see Section 14.5, however note
that it uses a format different from the one recommend in that it uses a format different from the one recommended in
RFC3253). RFC3253).
o Senders and recipients are now required to support the UTF-16
character encoding in XML message bodies (see Section 19).
o Clients are now required to send the Depth header on PROPFIND
requests, although servers are still encouraged to support clients
that don't.
Locking Locking
o RFC2518's concept of "lock-null resources" (LNRs) has been o RFC2518's concept of "lock-null resources" (LNRs) has been
replaced by a simplified approach, the "locked empty resources" replaced by a simplified approach, the "locked empty resources"
(see Section 7.3). There are some aspects of lock-null resources (see Section 7.3). There are some aspects of lock-null resources
clients can not rely on anymore, namely the ability to use them to clients can not rely on anymore, namely the ability to use them to
create a locked collection or the fact that they disappear upon create a locked collection or the fact that they disappear upon
UNLOCK when no PUT or MKCOL request was issued. Note that servers UNLOCK when no PUT or MKCOL request was issued. Note that servers
are still allowed to implement LNRs as per RFC2518. are still allowed to implement LNRs as per RFC2518.
skipping to change at page 147, line 9 skipping to change at page 151, line 9
G.11. Changes in -16 G.11. Changes in -16
Fixed factual errors in Security Considerations authentication Fixed factual errors in Security Considerations authentication
section. section.
Fixed example of refreshing a lock -- didn't use "If" header as Fixed example of refreshing a lock -- didn't use "If" header as
required in the text. required in the text.
Fixed example of using so-called 'all-prop' with the 'include' Fixed example of using so-called 'all-prop' with the 'include'
directivenotifi, so that it would actually be a useful example, by directive, so that it would actually be a useful example, by
including live properties that wouldn't already be covered by 'all- including live properties that wouldn't already be covered by 'all-
prop'. prop'.
Clarified requirement in section 7.7 paragraph 2 -- a clear Clarified requirement in section 7.7 paragraph 2 -- a clear
requirement for the server to meet, rather than passive voice "this requirement for the server to meet, rather than passive voice "this
request MUST only be used". request MUST only be used".
Made explicit requirement for successful response format for Made explicit requirement for successful response format for
PROPPATCH (bug 238) PROPPATCH (bug 238)
skipping to change at page 148, line 5 skipping to change at page 152, line 5
Removed suggestive/confusing text about lock notifications Removed suggestive/confusing text about lock notifications
Add section with guidance for clients dealing with both lock-null Add section with guidance for clients dealing with both lock-null
resources and locked empty resources. resources and locked empty resources.
Allow servers to omit owner information in lockdiscovery property. Allow servers to omit owner information in lockdiscovery property.
Clarify what 'allprop' means, mostly fixing misleading text in change Clarify what 'allprop' means, mostly fixing misleading text in change
summary summary
G.14. Changes compared to RFC2518bis, dated 2007-02-15
In Section 17, clarify extensibility, and what exactly the DTD
fragments mean. In Section 14 and Section 15, refer to extensibility
rules, remove "Extensibility" lines. Clarify content for
Section 15.9. See issue 48 [1].
Fix inconsistencies after backout of lock refresh changes. See issue
143 [2].
Update PUT (Section 9.7.1) accordingly. Also fix language in
Section 7.3 (should be a separate ticket). See issue 152 [3].
Minor fixes applied to changes made by L. D. See issue 161 [4].
Remove misleading statement about Date header in Section 8.5 (it
tries to repeat normative language from Section 14.18 of [RFC2616],
but fails; for instance, the Date header is not required for 1xx
responses). See issue 169 [5].
Cleanup description of status codes inside multistatus in Section 13,
and clarify individual Sections 9.1.2 and 9.2.1 as well. See issue
177 [6].
Fix incorrect terminology and typos, mainly in Section 16. Add
forward references. See issue 181 [7].
Remove most of the unnecessary stuff from the definition of empty
locked resources, and remove the part about LNRs completely, just
adding a forward reference to a new appendix (Section 7.3). See
issue 202 [8].
Fix intro in Section 9.1 plus text in Section 16. See issue 213 [9].
Various proposed fixes to Sections 6, 7 and 9. See issue 217 [10].
Remove "use with" statements from Section 16. See issue 220 [11].
Fix typos; add requirement to consistently use the same segment in
PROPFIND responses, re-add subsection titles for examples. See issue
227 [12].
Re-organize some of the Timeout discussion in Section 6. Remove
unneeded statement about what timetype values are allowed in
responses (Section 10.7), and integrate those parts that are about
Timeout semantics into Section 6. Update Changes section. See issue
229 [13].
Relaxed requirements for COPY (Section 9.8.2) and MOVE
(Section 9.9.1) of dead properties to "SHOULD". See issue 235 [14].
Describe the problem and potential solutions in Section 20.8. See
issue 237 [15].
Add definition of PROPPATCH response format in Section 9.2. See
issue 238 [16].
Relax requirements for DAV:getcontentlength in Section 15.4. See
issue 239 [17].
Update references for REC-XML and REC-XML-NAMES. See issue 240 [18].
Fix inconsistency between Section 9.7.1 and Section 15.5. See issue
241 [19].
Remove statement in Section 7.3. See issue 242 [20].
Remove unneeded subsection from Section 12. See issue 243 [21].
Fix description of DAV:owner in Section 14.17. See issue 244 [22].
Remove incomprehensible statement from Section 15.7. See issue
245 [23].
Get rid of confusing statement about COPY/MOVE behaviour in
Section 15. See issue 247 [24].
Fix statement about LWS handling in Section 15. See issue 248 [25].
Remove misleading statement about status 415 from Section 9.3. See
issue 250 [26].
Rephrase introduction to Section 9.10.1. See issue 251 [27].
Rewrite Section 9.10.4 to become consistent with whatever Section 7.3
says. See issue 252 [28].
Rephrase statement about shared locks in Section 6.2. See issue
254 [29].
Remove redundant language from Section 10.1. See issue 255 [30].
Update front matter to say "Updates: 3253" (no change tracking).
Note the nature of the change in Section 14.24. See issue 258 [31].
Rephrase sentence about unlock notifications (Section 6.6) so that it
becomes clear that those are not specified by WebDAV. See issue
259 [32].
Restore missing text from [RFC2518] (see Section 15.8). See issue
260 [33].
Add registration procedure and registry references; add information
about Status-URI to Section 21.3, add HTTP status code registration
(Section 21.4). See issue 264 [34].
Clarify the requirement about the ordering of instructions inside the
PROPPATCH request in Section 9.2.
Add reference for UTF-16 in Section 19. Make the UTF-8 reference
informative (the normative reference is already made through XML-
REC).
Remove incorrect claim from Appendix F that the UTF-16 requirement is
new (it was always required to support UTF-16 because of the
requirements inherited from XML-REC).
Add missing whitespace in If header example.
Index
C
Condition Names
DAV:cannot-modify-protected-property (pre) 110
DAV:lock-token-matches-request-uri (pre) 109
DAV:lock-token-submitted (pre) 109
DAV:no-conflicting-lock (pre) 110
DAV:no-external-entities (pre) 110
DAV:preserved-live-properties (post) 110
DAV:propfind-finite-depth (pre) 110
D
DAV:cannot-modify-protected-property 110
DAV:lock-token-matches-request-uri 109
DAV:lock-token-submitted precondition 109
DAV:no-conflicting-lock precondition 110
DAV:no-external-entities precondition 110
DAV:preserved-live-properties 110
DAV:propfind-finite-depth 110
Author's Address Author's Address
Lisa Dusseault (editor) Lisa Dusseault (editor)
CommerceNet CommerceNet
2064 Edgewood Dr. 2064 Edgewood Dr.
Palo Alto, CA 94303 Palo Alto, CA 94303
US US
Email: ldusseault@commerce.net Email: ldusseault@commerce.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 143 change blocks. 
588 lines changed or deleted 906 lines changed or added

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