draft-ietf-webdav-rfc2518bis-13.txt   draft-ietf-webdav-rfc2518bis-14.txt 
WebDAV L. Dusseault, Ed. WebDAV L. Dusseault, Ed.
Internet-Draft OSAF Internet-Draft OSAF
Obsoletes: 2518 (if approved) February 12, 2006 Obsoletes: 2518 (if approved) February 17, 2006
Expires: August 16, 2006 Expires: August 21, 2006
HTTP Extensions for Distributed Authoring - WebDAV HTTP Extensions for Distributed Authoring - WebDAV
draft-ietf-webdav-rfc2518bis-13 draft-ietf-webdav-rfc2518bis-14
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 34 skipping to change at page 1, line 34
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 16, 2006. This Internet-Draft will expire on August 21, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 9 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 9
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Data Model for Resource Properties . . . . . . . . . . . . . 11 4. Data Model for Resource Properties . . . . . . . . . . . . . 12
4.1. The Resource Property Model . . . . . . . . . . . . . . 11 4.1. The Resource Property Model . . . . . . . . . . . . . . 12
4.2. Properties and HTTP Headers . . . . . . . . . . . . . . 11 4.2. Properties and HTTP Headers . . . . . . . . . . . . . . 12
4.3. Property Values . . . . . . . . . . . . . . . . . . . . 11 4.3. Property Values . . . . . . . . . . . . . . . . . . . . 12
4.3.1. Example - Property with Mixed Content . . . . . . . 13 4.3.1. Example - Property with Mixed Content . . . . . . . 14
4.4. Property Names . . . . . . . . . . . . . . . . . . . . . 15 4.4. Property Names . . . . . . . . . . . . . . . . . . . . . 16
4.5. Source Resources and Output Resources . . . . . . . . . 15 4.5. Source Resources and Output Resources . . . . . . . . . 16
5. Collections of Web Resources . . . . . . . . . . . . . . . . 16 5. Collections of Web Resources . . . . . . . . . . . . . . . . 17
5.1. HTTP URL Namespace Model . . . . . . . . . . . . . . . . 16 5.1. HTTP URL Namespace Model . . . . . . . . . . . . . . . . 17
5.2. Collection Resources . . . . . . . . . . . . . . . . . . 16 5.2. Collection Resources . . . . . . . . . . . . . . . . . . 17
6. Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Lock Model . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Lock Model . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Exclusive Vs. Shared Locks . . . . . . . . . . . . . . . 19 6.2. Exclusive Vs. Shared Locks . . . . . . . . . . . . . . . 21
6.3. Required Support . . . . . . . . . . . . . . . . . . . . 20 6.3. Required Support . . . . . . . . . . . . . . . . . . . . 22
6.4. Lock Creator and Privileges . . . . . . . . . . . . . . 20 6.4. Lock Creator and Privileges . . . . . . . . . . . . . . 22
6.5. Lock Tokens . . . . . . . . . . . . . . . . . . . . . . 21 6.5. Lock Tokens . . . . . . . . . . . . . . . . . . . . . . 23
6.6. Lock Timeout . . . . . . . . . . . . . . . . . . . . . . 22 6.6. Lock Timeout . . . . . . . . . . . . . . . . . . . . . . 24
6.7. Lock Capability Discovery . . . . . . . . . . . . . . . 22 6.7. Lock Capability Discovery . . . . . . . . . . . . . . . 24
6.8. Active Lock Discovery . . . . . . . . . . . . . . . . . 23 6.8. Active Lock Discovery . . . . . . . . . . . . . . . . . 25
6.9. Locks and Multiple Bindings . . . . . . . . . . . . . . 23 6.9. Locks and Multiple Bindings . . . . . . . . . . . . . . 25
7. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Write Locks and Properties . . . . . . . . . . . . . . . 24 7.1. Write Locks and Properties . . . . . . . . . . . . . . . 26
7.2. Avoiding Lost Updates . . . . . . . . . . . . . . . . . 25 7.2. Avoiding Lost Updates . . . . . . . . . . . . . . . . . 27
7.3. Write Locks and Unmapped URLs . . . . . . . . . . . . . 26 7.3. Write Locks and Unmapped URLs . . . . . . . . . . . . . 28
7.4. Write Locks and Collections . . . . . . . . . . . . . . 28 7.4. Write Locks and Collections . . . . . . . . . . . . . . 30
7.5. Write Locks and the If Request Header . . . . . . . . . 29 7.5. Write Locks and the If Request Header . . . . . . . . . 31
7.5.1. Example - Write Lock and COPY . . . . . . . . . . . 30 7.5.1. Example - Write Lock and COPY . . . . . . . . . . . 32
7.5.2. Example - Deleting a member of a locked collection . 30 7.5.2. Example - Deleting a member of a locked collection . 32
7.6. Write Locks and COPY/MOVE . . . . . . . . . . . . . . . 31 7.6. Write Locks and COPY/MOVE . . . . . . . . . . . . . . . 33
7.7. Refreshing Write Locks . . . . . . . . . . . . . . . . . 31 7.7. Refreshing Write Locks . . . . . . . . . . . . . . . . . 33
8. General Request and Response Handling . . . . . . . . . . . . 33 8. General Request and Response Handling . . . . . . . . . . . . 35
8.1. Precedence in Error Handling . . . . . . . . . . . . . . 33 8.1. Precedence in Error Handling . . . . . . . . . . . . . . 35
8.2. Use of XML . . . . . . . . . . . . . . . . . . . . . . . 33 8.2. Use of XML . . . . . . . . . . . . . . . . . . . . . . . 35
8.3. URL Handling . . . . . . . . . . . . . . . . . . . . . . 33 8.3. URL Handling . . . . . . . . . . . . . . . . . . . . . . 36
8.3.1. Example - Correct URL Handling . . . . . . . . . . . 34 8.3.1. Example - Correct URL Handling . . . . . . . . . . . 36
8.4. Required Bodies in Requests . . . . . . . . . . . . . . 35 8.4. Required Bodies in Requests . . . . . . . . . . . . . . 37
8.5. HTTP Headers for use in WebDAV . . . . . . . . . . . . . 35 8.5. HTTP Headers for use in WebDAV . . . . . . . . . . . . . 37
8.6. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.6. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.7. Including error response bodies . . . . . . . . . . . . 36 8.7. Including error response bodies . . . . . . . . . . . . 38
8.8. Impact of Namespace Operations on Cache Validators . . . 36 8.8. Impact of Namespace Operations on Cache Validators . . . 38
9. HTTP Methods for Distributed Authoring . . . . . . . . . . . 38 9. HTTP Methods for Distributed Authoring . . . . . . . . . . . 40
9.1. PROPFIND Method . . . . . . . . . . . . . . . . . . . . 38 9.1. PROPFIND Method . . . . . . . . . . . . . . . . . . . . 40
9.1.1. PROPFIND status codes . . . . . . . . . . . . . . . 39 9.1.1. PROPFIND status codes . . . . . . . . . . . . . . . 41
9.1.2. Status codes for use with 207 (Multi-Status) . . . . 40 9.1.2. Status codes for use with 207 (Multi-Status) . . . . 42
9.1.3. Example - Retrieving Named Properties . . . . . . . 40 9.1.3. Example - Retrieving Named Properties . . . . . . . 42
9.1.4. Example - Retrieving Named and Dead Properties . . . 42 9.1.4. Example - Retrieving Named and Dead Properties . . . 44
9.1.5. Example - Using 'propname' to Retrieve all 9.1.5. Example - Using 'propname' to Retrieve all
Property Names . . . . . . . . . . . . . . . . . . . 42 Property Names . . . . . . . . . . . . . . . . . . . 44
9.1.6. Example - Using 'allprop' . . . . . . . . . . . . . 44 9.1.6. Example - Using 'allprop' . . . . . . . . . . . . . 46
9.2. PROPPATCH Method . . . . . . . . . . . . . . . . . . . . 46 9.2. PROPPATCH Method . . . . . . . . . . . . . . . . . . . . 48
9.2.1. Status Codes for use in 207 (Multi-Status) . . . . . 47 9.2.1. Status Codes for use in 207 (Multi-Status) . . . . . 49
9.2.2. Example - PROPPATCH . . . . . . . . . . . . . . . . 48 9.2.2. Example - PROPPATCH . . . . . . . . . . . . . . . . 50
9.3. MKCOL Method . . . . . . . . . . . . . . . . . . . . . . 49 9.3. MKCOL Method . . . . . . . . . . . . . . . . . . . . . . 51
9.3.1. MKCOL Status Codes . . . . . . . . . . . . . . . . . 50 9.3.1. MKCOL Status Codes . . . . . . . . . . . . . . . . . 52
9.3.2. Example - MKCOL . . . . . . . . . . . . . . . . . . 50 9.3.2. Example - MKCOL . . . . . . . . . . . . . . . . . . 52
9.4. GET, HEAD for Collections . . . . . . . . . . . . . . . 51 9.4. GET, HEAD for Collections . . . . . . . . . . . . . . . 53
9.5. POST for Collections . . . . . . . . . . . . . . . . . . 51 9.5. POST for Collections . . . . . . . . . . . . . . . . . . 53
9.6. DELETE Requirements . . . . . . . . . . . . . . . . . . 51 9.6. DELETE Requirements . . . . . . . . . . . . . . . . . . 53
9.6.1. DELETE for Collections . . . . . . . . . . . . . . . 52 9.6.1. DELETE for Collections . . . . . . . . . . . . . . . 54
9.6.2. Example - DELETE . . . . . . . . . . . . . . . . . . 52 9.6.2. Example - DELETE . . . . . . . . . . . . . . . . . . 54
9.7. PUT Requirements . . . . . . . . . . . . . . . . . . . . 53 9.7. PUT Requirements . . . . . . . . . . . . . . . . . . . . 55
9.7.1. PUT for Non-Collection Resources . . . . . . . . . . 53 9.7.1. PUT for Non-Collection Resources . . . . . . . . . . 55
9.7.2. PUT for Collections . . . . . . . . . . . . . . . . 54 9.7.2. PUT for Collections . . . . . . . . . . . . . . . . 56
9.8. COPY Method . . . . . . . . . . . . . . . . . . . . . . 54 9.8. COPY Method . . . . . . . . . . . . . . . . . . . . . . 56
9.8.1. COPY for Non-collection Resources . . . . . . . . . 54 9.8.1. COPY for Non-collection Resources . . . . . . . . . 56
9.8.2. COPY for Properties . . . . . . . . . . . . . . . . 55 9.8.2. COPY for Properties . . . . . . . . . . . . . . . . 57
9.8.3. COPY for Collections . . . . . . . . . . . . . . . . 55 9.8.3. COPY for Collections . . . . . . . . . . . . . . . . 57
9.8.4. COPY and Overwriting Destination Resources . . . . . 56 9.8.4. COPY and Overwriting Destination Resources . . . . . 58
9.8.5. Status Codes . . . . . . . . . . . . . . . . . . . . 57 9.8.5. Status Codes . . . . . . . . . . . . . . . . . . . . 59
9.8.6. Example - COPY with Overwrite . . . . . . . . . . . 58 9.8.6. Example - COPY with Overwrite . . . . . . . . . . . 60
9.8.7. Example - COPY with No Overwrite . . . . . . . . . . 58 9.8.7. Example - COPY with No Overwrite . . . . . . . . . . 60
9.8.8. Example - COPY of a Collection . . . . . . . . . . . 59 9.8.8. Example - COPY of a Collection . . . . . . . . . . . 61
9.9. MOVE Method . . . . . . . . . . . . . . . . . . . . . . 59 9.9. MOVE Method . . . . . . . . . . . . . . . . . . . . . . 61
9.9.1. MOVE for Properties . . . . . . . . . . . . . . . . 60 9.9.1. MOVE for Properties . . . . . . . . . . . . . . . . 62
9.9.2. MOVE for Collections . . . . . . . . . . . . . . . . 60 9.9.2. MOVE for Collections . . . . . . . . . . . . . . . . 62
9.9.3. MOVE and the Overwrite Header . . . . . . . . . . . 61 9.9.3. MOVE and the Overwrite Header . . . . . . . . . . . 63
9.9.4. Status Codes . . . . . . . . . . . . . . . . . . . . 61 9.9.4. Status Codes . . . . . . . . . . . . . . . . . . . . 63
9.9.5. Example - MOVE of a Non-Collection . . . . . . . . . 62 9.9.5. Example - MOVE of a Non-Collection . . . . . . . . . 64
9.9.6. Example - MOVE of a Collection . . . . . . . . . . . 63 9.9.6. Example - MOVE of a Collection . . . . . . . . . . . 65
9.10. LOCK Method . . . . . . . . . . . . . . . . . . . . . . 63 9.10. LOCK Method . . . . . . . . . . . . . . . . . . . . . . 65
9.10.1. Creating a lock on existing resource . . . . . . . . 64 9.10.1. Creating a lock on existing resource . . . . . . . . 66
9.10.2. Refreshing Locks . . . . . . . . . . . . . . . . . . 64 9.10.2. Refreshing Locks . . . . . . . . . . . . . . . . . . 66
9.10.3. Depth and Locking . . . . . . . . . . . . . . . . . 65 9.10.3. Depth and Locking . . . . . . . . . . . . . . . . . 67
9.10.4. Locking Unmapped URLs . . . . . . . . . . . . . . . 65 9.10.4. Locking Unmapped URLs . . . . . . . . . . . . . . . 67
9.10.5. Lock Compatibility Table . . . . . . . . . . . . . . 66 9.10.5. Lock Compatibility Table . . . . . . . . . . . . . . 68
9.10.6. LOCK Responses . . . . . . . . . . . . . . . . . . . 66 9.10.6. LOCK Responses . . . . . . . . . . . . . . . . . . . 68
9.10.7. Example - Simple Lock Request . . . . . . . . . . . 67 9.10.7. Example - Simple Lock Request . . . . . . . . . . . 69
9.10.8. Example - Refreshing a Write Lock . . . . . . . . . 69 9.10.8. Example - Refreshing a Write Lock . . . . . . . . . 71
9.10.9. Example - Multi-Resource Lock Request . . . . . . . 70 9.10.9. Example - Multi-Resource Lock Request . . . . . . . 72
9.11. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . 71 9.11. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . 73
9.11.1. Status Codes . . . . . . . . . . . . . . . . . . . . 71 9.11.1. Status Codes . . . . . . . . . . . . . . . . . . . . 73
9.11.2. Example - UNLOCK . . . . . . . . . . . . . . . . . . 72 9.11.2. Example - UNLOCK . . . . . . . . . . . . . . . . . . 74
10. HTTP Headers for Distributed Authoring . . . . . . . . . . . 73 10. HTTP Headers for Distributed Authoring . . . . . . . . . . . 75
10.1. DAV Header . . . . . . . . . . . . . . . . . . . . . . . 73 10.1. DAV Header . . . . . . . . . . . . . . . . . . . . . . . 75
10.2. Depth Header . . . . . . . . . . . . . . . . . . . . . . 74 10.2. Depth Header . . . . . . . . . . . . . . . . . . . . . . 76
10.3. Destination Header . . . . . . . . . . . . . . . . . . . 75 10.3. Destination Header . . . . . . . . . . . . . . . . . . . 77
10.4. If Header . . . . . . . . . . . . . . . . . . . . . . . 75 10.4. If Header . . . . . . . . . . . . . . . . . . . . . . . 77
10.4.1. No-tag-list Production . . . . . . . . . . . . . . . 76 10.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 77
10.4.2. Tagged-list Production . . . . . . . . . . . . . . . 76 10.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 78
10.4.3. Example - Tagged List If header in COPY . . . . . . 77 10.4.3. List Evaluation . . . . . . . . . . . . . . . . . . 79
10.4.4. Not Production . . . . . . . . . . . . . . . . . . . 77 10.4.4. Matching State Tokens and ETags . . . . . . . . . . 79
10.4.5. Matching Function . . . . . . . . . . . . . . . . . 78 10.4.5. If Header and Non-DAV Aware Proxies . . . . . . . . 80
10.4.6. If Header and Non-DAV Aware Proxies . . . . . . . . 78 10.4.6. Example - No-tag Production . . . . . . . . . . . . 80
10.5. Lock-Token Header . . . . . . . . . . . . . . . . . . . 79 10.4.7. Example - using "Not" with No-tag Production . . . . 80
10.6. Overwrite Header . . . . . . . . . . . . . . . . . . . . 79 10.4.8. Example - causing a Condition to always evaluate
10.7. Timeout Request Header . . . . . . . . . . . . . . . . . 79 to True . . . . . . . . . . . . . . . . . . . . . . 81
11. Status Code Extensions to HTTP/1.1 . . . . . . . . . . . . . 81 10.4.9. Example - Tagged List If header in COPY . . . . . . 81
11.1. 207 Multi-Status . . . . . . . . . . . . . . . . . . . . 81 10.4.10. Example - Matching lock tokens with collection
11.2. 422 Unprocessable Entity . . . . . . . . . . . . . . . . 81 locks . . . . . . . . . . . . . . . . . . . . . . . 81
11.3. 423 Locked . . . . . . . . . . . . . . . . . . . . . . . 81 10.4.11. Example - Matching ETags on unmapped URLs . . . . . 82
11.4. 424 Failed Dependency . . . . . . . . . . . . . . . . . 81 10.5. Lock-Token Header . . . . . . . . . . . . . . . . . . . 82
11.5. 507 Insufficient Storage . . . . . . . . . . . . . . . . 81 10.6. Overwrite Header . . . . . . . . . . . . . . . . . . . . 82
12. Use of HTTP Status Codes . . . . . . . . . . . . . . . . . . 82 10.7. Timeout Request Header . . . . . . . . . . . . . . . . . 83
12.1. 412 Precondition Failed . . . . . . . . . . . . . . . . 82 11. Status Code Extensions to HTTP/1.1 . . . . . . . . . . . . . 84
12.2. 414 Request-URI Too Long . . . . . . . . . . . . . . . . 82 11.1. 207 Multi-Status . . . . . . . . . . . . . . . . . . . . 84
13. Multi-Status Response . . . . . . . . . . . . . . . . . . . . 83 11.2. 422 Unprocessable Entity . . . . . . . . . . . . . . . . 84
13.1. Response headers . . . . . . . . . . . . . . . . . . . . 83 11.3. 423 Locked . . . . . . . . . . . . . . . . . . . . . . . 84
13.2. Handling redirected child resources . . . . . . . . . . 83 11.4. 424 Failed Dependency . . . . . . . . . . . . . . . . . 84
13.3. Internal Status Codes . . . . . . . . . . . . . . . . . 84 11.5. 507 Insufficient Storage . . . . . . . . . . . . . . . . 84
14. XML Element Definitions . . . . . . . . . . . . . . . . . . . 85 12. Use of HTTP Status Codes . . . . . . . . . . . . . . . . . . 85
14.1. activelock XML Element . . . . . . . . . . . . . . . . . 85 12.1. 412 Precondition Failed . . . . . . . . . . . . . . . . 85
14.2. allprop XML Element . . . . . . . . . . . . . . . . . . 85 12.2. 414 Request-URI Too Long . . . . . . . . . . . . . . . . 85
14.3. collection XML Element . . . . . . . . . . . . . . . . . 85 13. Multi-Status Response . . . . . . . . . . . . . . . . . . . . 86
14.4. depth XML Element . . . . . . . . . . . . . . . . . . . 86 13.1. Response headers . . . . . . . . . . . . . . . . . . . . 86
14.5. error XML Element . . . . . . . . . . . . . . . . . . . 86 13.2. Handling redirected child resources . . . . . . . . . . 86
14.6. exclusive XML Element . . . . . . . . . . . . . . . . . 86 13.3. Internal Status Codes . . . . . . . . . . . . . . . . . 87
14.7. href XML Element . . . . . . . . . . . . . . . . . . . . 86 14. XML Element Definitions . . . . . . . . . . . . . . . . . . . 88
14.8. include XML Element . . . . . . . . . . . . . . . . . . 87 14.1. activelock XML Element . . . . . . . . . . . . . . . . . 88
14.9. location XML Element . . . . . . . . . . . . . . . . . . 87 14.2. allprop XML Element . . . . . . . . . . . . . . . . . . 88
14.10. lockentry XML Element . . . . . . . . . . . . . . . . . 87 14.3. collection XML Element . . . . . . . . . . . . . . . . . 88
14.11. lockinfo XML Element . . . . . . . . . . . . . . . . . . 87 14.4. depth XML Element . . . . . . . . . . . . . . . . . . . 89
14.12. lockroot XML Element . . . . . . . . . . . . . . . . . . 88 14.5. error XML Element . . . . . . . . . . . . . . . . . . . 89
14.13. lockscope XML Element . . . . . . . . . . . . . . . . . 88 14.6. exclusive XML Element . . . . . . . . . . . . . . . . . 89
14.14. locktoken XML Element . . . . . . . . . . . . . . . . . 88 14.7. href XML Element . . . . . . . . . . . . . . . . . . . . 89
14.15. locktype XML Element . . . . . . . . . . . . . . . . . . 88 14.8. include XML Element . . . . . . . . . . . . . . . . . . 90
14.16. multistatus XML Element . . . . . . . . . . . . . . . . 89 14.9. location XML Element . . . . . . . . . . . . . . . . . . 90
14.17. owner XML Element . . . . . . . . . . . . . . . . . . . 89 14.10. lockentry XML Element . . . . . . . . . . . . . . . . . 90
14.18. prop XML element . . . . . . . . . . . . . . . . . . . . 90 14.11. lockinfo XML Element . . . . . . . . . . . . . . . . . . 90
14.19. propertyupdate XML element . . . . . . . . . . . . . . . 90 14.12. lockroot XML Element . . . . . . . . . . . . . . . . . . 91
14.20. propfind XML Element . . . . . . . . . . . . . . . . . . 90 14.13. lockscope XML Element . . . . . . . . . . . . . . . . . 91
14.21. propname XML Element . . . . . . . . . . . . . . . . . . 90 14.14. locktoken XML Element . . . . . . . . . . . . . . . . . 91
14.22. propstat XML Element . . . . . . . . . . . . . . . . . . 91 14.15. locktype XML Element . . . . . . . . . . . . . . . . . . 91
14.23. remove XML element . . . . . . . . . . . . . . . . . . . 91 14.16. multistatus XML Element . . . . . . . . . . . . . . . . 92
14.24. response XML Element . . . . . . . . . . . . . . . . . . 91 14.17. owner XML Element . . . . . . . . . . . . . . . . . . . 92
14.25. responsedescription XML Element . . . . . . . . . . . . 92 14.18. prop XML element . . . . . . . . . . . . . . . . . . . . 93
14.26. set XML element . . . . . . . . . . . . . . . . . . . . 92 14.19. propertyupdate XML element . . . . . . . . . . . . . . . 93
14.27. shared XML Element . . . . . . . . . . . . . . . . . . . 92 14.20. propfind XML Element . . . . . . . . . . . . . . . . . . 93
14.28. status XML Element . . . . . . . . . . . . . . . . . . . 93 14.21. propname XML Element . . . . . . . . . . . . . . . . . . 93
14.29. timeout XML Element . . . . . . . . . . . . . . . . . . 93 14.22. propstat XML Element . . . . . . . . . . . . . . . . . . 94
14.30. write XML Element . . . . . . . . . . . . . . . . . . . 93 14.23. remove XML element . . . . . . . . . . . . . . . . . . . 94
15. DAV Properties . . . . . . . . . . . . . . . . . . . . . . . 94 14.24. response XML Element . . . . . . . . . . . . . . . . . . 94
15.1. creationdate Property . . . . . . . . . . . . . . . . . 94 14.25. responsedescription XML Element . . . . . . . . . . . . 95
15.2. displayname Property . . . . . . . . . . . . . . . . . . 95 14.26. set XML element . . . . . . . . . . . . . . . . . . . . 95
15.3. getcontentlanguage Property . . . . . . . . . . . . . . 95 14.27. shared XML Element . . . . . . . . . . . . . . . . . . . 95
15.4. getcontentlength Property . . . . . . . . . . . . . . . 96 14.28. status XML Element . . . . . . . . . . . . . . . . . . . 96
15.5. getcontenttype Property . . . . . . . . . . . . . . . . 96 14.29. timeout XML Element . . . . . . . . . . . . . . . . . . 96
15.6. getetag Property . . . . . . . . . . . . . . . . . . . . 97 14.30. write XML Element . . . . . . . . . . . . . . . . . . . 96
15.7. getlastmodified Property . . . . . . . . . . . . . . . . 97 15. DAV Properties . . . . . . . . . . . . . . . . . . . . . . . 97
15.8. lockdiscovery Property . . . . . . . . . . . . . . . . . 98 15.1. creationdate Property . . . . . . . . . . . . . . . . . 97
15.8.1. Example - Retrieving DAV:lockdiscovery . . . . . . . 99 15.2. displayname Property . . . . . . . . . . . . . . . . . . 98
15.9. resourcetype Property . . . . . . . . . . . . . . . . . 100 15.3. getcontentlanguage Property . . . . . . . . . . . . . . 98
15.10. supportedlock Property . . . . . . . . . . . . . . . . . 101 15.4. getcontentlength Property . . . . . . . . . . . . . . . 99
15.10.1. Example - Retrieving DAV:supportedlock . . . . . . . 102 15.5. getcontenttype Property . . . . . . . . . . . . . . . . 99
16. Precondition/postcondition XML elements . . . . . . . . . . . 103 15.6. getetag Property . . . . . . . . . . . . . . . . . . . . 100
17. XML Extensibility in DAV . . . . . . . . . . . . . . . . . . 107 15.7. getlastmodified Property . . . . . . . . . . . . . . . . 100
18. DAV Compliance Classes . . . . . . . . . . . . . . . . . . . 109 15.8. lockdiscovery Property . . . . . . . . . . . . . . . . . 101
18.1. Class 1 . . . . . . . . . . . . . . . . . . . . . . . . 109 15.8.1. Example - Retrieving DAV:lockdiscovery . . . . . . . 102
18.2. Class 2 . . . . . . . . . . . . . . . . . . . . . . . . 109 15.9. resourcetype Property . . . . . . . . . . . . . . . . . 103
18.3. Class 3 . . . . . . . . . . . . . . . . . . . . . . . . 109 15.10. supportedlock Property . . . . . . . . . . . . . . . . . 104
19. Internationalization Considerations . . . . . . . . . . . . . 111 15.10.1. Example - Retrieving DAV:supportedlock . . . . . . . 105
20. Security Considerations . . . . . . . . . . . . . . . . . . . 113 16. Precondition/postcondition XML elements . . . . . . . . . . . 106
20.1. Authentication of Clients . . . . . . . . . . . . . . . 113 17. XML Extensibility in DAV . . . . . . . . . . . . . . . . . . 110
20.2. Denial of Service . . . . . . . . . . . . . . . . . . . 113 18. DAV Compliance Classes . . . . . . . . . . . . . . . . . . . 112
20.3. Security through Obscurity . . . . . . . . . . . . . . . 114 18.1. Class 1 . . . . . . . . . . . . . . . . . . . . . . . . 112
20.4. Privacy Issues Connected to Locks . . . . . . . . . . . 114 18.2. Class 2 . . . . . . . . . . . . . . . . . . . . . . . . 112
20.5. Privacy Issues Connected to Properties . . . . . . . . . 114 18.3. Class 3 . . . . . . . . . . . . . . . . . . . . . . . . 112
20.6. Implications of XML Entities . . . . . . . . . . . . . . 115 19. Internationalization Considerations . . . . . . . . . . . . . 114
20.7. Risks Connected with Lock Tokens . . . . . . . . . . . . 116 20. Security Considerations . . . . . . . . . . . . . . . . . . . 116
20.8. Hosting Malicious Content . . . . . . . . . . . . . . . 116 20.1. Authentication of Clients . . . . . . . . . . . . . . . 116
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117 20.2. Denial of Service . . . . . . . . . . . . . . . . . . . 116
21.1. New URI Schemes . . . . . . . . . . . . . . . . . . . . 117 20.3. Security through Obscurity . . . . . . . . . . . . . . . 117
21.2. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 117 20.4. Privacy Issues Connected to Locks . . . . . . . . . . . 117
21.3. Message Header Fields . . . . . . . . . . . . . . . . . 117 20.5. Privacy Issues Connected to Properties . . . . . . . . . 117
21.3.1. DAV . . . . . . . . . . . . . . . . . . . . . . . . 117 20.6. Implications of XML Entities . . . . . . . . . . . . . . 118
21.3.2. Depth . . . . . . . . . . . . . . . . . . . . . . . 117 20.7. Risks Connected with Lock Tokens . . . . . . . . . . . . 119
21.3.3. Destination . . . . . . . . . . . . . . . . . . . . 118 20.8. Hosting Malicious Content . . . . . . . . . . . . . . . 119
21.3.4. If . . . . . . . . . . . . . . . . . . . . . . . . . 118 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120
21.3.5. Lock-Token . . . . . . . . . . . . . . . . . . . . . 118 21.1. New URI Schemes . . . . . . . . . . . . . . . . . . . . 120
21.3.6. Overwrite . . . . . . . . . . . . . . . . . . . . . 118 21.2. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 120
21.3.7. Timeout . . . . . . . . . . . . . . . . . . . . . . 119 21.3. Message Header Fields . . . . . . . . . . . . . . . . . 120
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 120 21.3.1. DAV . . . . . . . . . . . . . . . . . . . . . . . . 120
23. Contributors to This Specification . . . . . . . . . . . . . 122 21.3.2. Depth . . . . . . . . . . . . . . . . . . . . . . . 120
24. Authors of RFC2518 . . . . . . . . . . . . . . . . . . . . . 123 21.3.3. Destination . . . . . . . . . . . . . . . . . . . . 121
25. References . . . . . . . . . . . . . . . . . . . . . . . . . 124 21.3.4. If . . . . . . . . . . . . . . . . . . . . . . . . . 121
25.1. Normative References . . . . . . . . . . . . . . . . . . 124 21.3.5. Lock-Token . . . . . . . . . . . . . . . . . . . . . 121
25.2. Informational References . . . . . . . . . . . . . . . . 125 21.3.6. Overwrite . . . . . . . . . . . . . . . . . . . . . 121
Appendix A. Notes on Processing XML Elements . . . . . . . . . . 126 21.3.7. Timeout . . . . . . . . . . . . . . . . . . . . . . 122
A.1. Notes on Empty XML Elements . . . . . . . . . . . . . . 126 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 123
A.2. Notes on Illegal XML Processing . . . . . . . . . . . . 126 23. Contributors to This Specification . . . . . . . . . . . . . 125
A.3. Example - XML Syntax Error . . . . . . . . . . . . . . . 126 24. Authors of RFC2518 . . . . . . . . . . . . . . . . . . . . . 126
A.4. Example - Unexpected XML Element . . . . . . . . . . . . 127 25. References . . . . . . . . . . . . . . . . . . . . . . . . . 127
Appendix B. Notes on HTTP Client Compatibility . . . . . . . . . 128 25.1. Normative References . . . . . . . . . . . . . . . . . . 127
Appendix C. The opaquelocktoken scheme and URIs . . . . . . . . 129 25.2. Informational References . . . . . . . . . . . . . . . . 128
Appendix D. Guidance for Clients Desiring to Authenticate . . . 130 Appendix A. Notes on Processing XML Elements . . . . . . . . . . 129
Appendix E. Summary of changes from RFC2518 . . . . . . . . . . 132 A.1. Notes on Empty XML Elements . . . . . . . . . . . . . . 129
E.1. Changes for both Clients and Servers . . . . . . . . . . 132 A.2. Notes on Illegal XML Processing . . . . . . . . . . . . 129
E.2. Changes Notable to Server Implementors . . . . . . . . . 132 A.3. Example - XML Syntax Error . . . . . . . . . . . . . . . 129
E.3. Changes Notable to Client Implementors . . . . . . . . . 133 A.4. Example - Unexpected XML Element . . . . . . . . . . . . 130
Appendix B. Notes on HTTP Client Compatibility . . . . . . . . . 131
Appendix C. The opaquelocktoken scheme and URIs . . . . . . . . 132
Appendix D. Guidance for Clients Desiring to Authenticate . . . 133
Appendix E. Summary of changes from RFC2518 . . . . . . . . . . 135
E.1. Changes for both Client and Server Implementations . . . 135
E.2. Changes for Server Implementations . . . . . . . . . . . 136
E.3. Other Changes . . . . . . . . . . . . . . . . . . . . . 137
Appendix F. Change Log (to be removed by RFC Editor before Appendix F. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 135 publication) . . . . . . . . . . . . . . . . . . . . 138
F.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . 135 F.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . 138
F.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 135 F.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 138
F.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 136 F.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 139
F.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 137 F.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 140
F.5. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 138 F.5. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 141
F.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 138 F.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 141
F.7. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 138 F.7. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 141
F.8. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 139 F.8. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 142
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 140 F.9. Changes in -14 . . . . . . . . . . . . . . . . . . . . . 142
Intellectual Property and Copyright Statements . . . . . . . . . 141 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 143
Intellectual Property and Copyright Statements . . . . . . . . . 144
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 10, line 18 skipping to change at page 10, line 18
respectively. These terms (and the distinction between them) are respectively. These terms (and the distinction between them) are
defined in [RFC3986]. defined in [RFC3986].
URI/URL Mapping - A relation between an absolute URI and a resource. URI/URL Mapping - A relation between an absolute URI and a resource.
Since a resource can represent items that are not network Since a resource can represent items that are not network
retrievable, as well as those that are, it is possible for a resource retrievable, as well as those that are, it is possible for a resource
to have zero, one, or many URI mappings. Mapping a resource to an to have zero, one, or many URI mappings. Mapping a resource to an
"http" scheme URI makes it possible to submit HTTP protocol requests "http" scheme URI makes it possible to submit HTTP protocol requests
to the resource using the URI. to the resource using the URI.
Collection - A resource that contains a set of URLs, which identify
and locate member resources and which meet the collections
requirements (Section 5).
Member URL - A URL which is a member of the set of URLs contained by
a collection.
Path Segment - Informally, the characters found between slashes ("/") Path Segment - Informally, the characters found between slashes ("/")
in a URI. Formally, as defined in Section 3.3 of [RFC3986]. in a URI. Formally, as defined in Section 3.3 of [RFC3986].
Internal Member URL - A member URL that is immediately relative to Collection - Informally, a resource that also acts as a container of
the URL of the collection. That is, the internal member URL is equal references to child resources. Formally, a resource that contains a
to a containing collection's URL plus an additional path segment for set of mappings between path segments and resources and meets the
non-collection resources, or additional segment plus trailing slash requirements in Section 5.
"/" for collection resources.
Internal Member (of a Collection) - Informally, a child resource of a
collection. Formally, a resource referenced by a path segment
contained in the collection.
Internal Member URL (of a Collection) - A URL of an internal member,
consisting of the URL of the collection (including trailing slash)
plus the path segment identifying the internal member.
Member (of a Collection) - Informally, a "descendant" of a
collection. Formally, an internal member of the collection, or,
recursively, a member of an internal member.
Member URL (of a Collection) - A URL that is either an internal
member URL of the collection itself, or is an internal member URL of
a member of that collection.
Property - A name/value pair that contains descriptive information Property - A name/value pair that contains descriptive information
about a resource. about a resource.
Live Property - A property whose semantics and syntax are enforced by Live Property - A property whose semantics and syntax are enforced by
the server. For example, the live property DAV:getcontentlength has the server. For example, the live property DAV:getcontentlength has
its value, the length of the entity returned by a GET request, its value, the length of the entity returned by a GET request,
automatically calculated by the server. automatically calculated by the server.
Dead Property - A property whose semantics and syntax are not Dead Property - A property whose semantics and syntax are not
skipping to change at page 16, line 52 skipping to change at page 17, line 52
act as containers. A collection is a resource whose state consists act as containers. A collection is a resource whose state consists
of at least a set of mappings between path segments and resources, of at least a set of mappings between path segments and resources,
and a set of properties on the collection itself. A collection MAY and a set of properties on the collection itself. A collection MAY
have additional state such as entity bodies returned by GET. have additional state such as entity bodies returned by GET.
A collection MUST contain at most one mapping for a given path A collection MUST contain at most one mapping for a given path
segment, i.e., it is illegal to have the same path segment mapped to segment, i.e., it is illegal to have the same path segment mapped to
more than one resource. Properties defined on collections behave more than one resource. Properties defined on collections behave
exactly as do properties on non-collection resources. exactly as do properties on non-collection resources.
When a WebDAV resource has a URL U, such that U is the same as URL V For all WebDAV compliant resources A and B, identified by URLs "U"
plus a single additional path segment, then if the resource and "V" respectively, such that "V" is equal to "U/SEGMENT", A MUST
identified by V is WebDAV compliant it MUST be a collection that has be a collection that contains a mapping from "SEGMENT" to B. So, if
U as an internal member URL. For example, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant
"http://example.com/bar/blah" is a WebDAV resource, then if and if resource A with URL "http://example.com/bar/" is WebDAV
"http://example.com/bar/" is WebDAV compliant, it MUST be a compliant, then resource A must be a collection and must contain at
collection and MUST contain "http://example.com/bar/blah" as an least one mapping from "blah" to B.
internal member.
Collection resources MAY have internal members with mappings to non- Collection resources MAY have mappings to non-WebDAV compliant
WebDAV compliant children in the HTTP URL namespace hierarchy but are resources in the HTTP URL namespace hierarchy but are not required to
not required to do so. For example, if the resource X with URL do so. For example, if resource X with URL
"http://example.com/bar/index.html" is not WebDAV compliant and the "http://example.com/bar/blah" is not WebDAV compliant and resource A
resource with URL "http://example.com/bar/" identifies a collection, with "URL http://example.com/bar/" identifies a WebDAV collection,
then collection "bar" might or might not have an internal member with then A may or may not have a mapping from "blah" to X.
a mapping from "index.html" to the resource X. If the collection
doesn't have such an internal member, presumably the consequence is
that the "index.html" resource might not show up in PROPFIND
responses, might not be locked when the collection is locked, might
not have WebDAV properties, and so on.
If a WebDAV compliant resource has no WebDAV compliant children in If a WebDAV compliant resource has no WebDAV compliant children in
the HTTP URL namespace hierarchy then the WebDAV compliant resource the HTTP URL namespace hierarchy then the WebDAV compliant resource
is not required to be a collection. is not required to be a collection.
There is a standing convention that when a collection is referred to There is a standing convention that when a collection is referred to
by its name without a trailing slash, the server MAY handle the by its name without a trailing slash, the server MAY handle the
request as if the trailing slash were present. In this case it request as if the trailing slash were present. In this case it
SHOULD return a Content-Location header in the response, pointing to SHOULD return a Content-Location header in the response, pointing to
the URL ending with the "/". For example, if a client invokes a the URL ending with the "/". For example, if a client invokes a
skipping to change at page 18, line 5 skipping to change at page 18, line 45
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.
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
redirects to non-WebDAV resources. For instance, "/col/link" might
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
"/col/link" would indeed be mapped. Similarly, a dynamically-
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
appear as a member of "/col/".
Some mappings to even WebDAV-compliant resources might not appear in
the parent collection. An example for this case are servers that
support multiple alias URLs for each WebDAV compliant resource. A
server may implement case-insensitive URLs, thus "/col/a" and
"/col/A" identify the same resource, yet only either "a" or "A" are
reported upon listing the members of "/col".
6. Locking 6. Locking
The ability to lock a resource provides a mechanism for serializing The ability to lock a resource provides a mechanism for serializing
access to that resource. Using a lock, an authoring client can access to that resource. Using a lock, an authoring client can
provide a reasonable guarantee that another principal will not modify provide a reasonable guarantee that another principal will not modify
a resource while it is being edited. In this way, a client can a resource while it is being edited. In this way, a client can
prevent the "lost update" problem. prevent the "lost update" problem.
This specification allows locks to vary over two client-specified This specification allows locks to vary over two client-specified
parameters, the number of principals involved (exclusive vs. shared) parameters, the number of principals involved (exclusive vs. shared)
skipping to change at page 33, line 30 skipping to change at page 35, line 30
motivated by the ability to add extra XML elements to existing motivated by the ability to add extra XML elements to existing
structures, providing extensibility; and by XML's ability to encode structures, providing extensibility; and by XML's ability to encode
information in ISO 10646 character sets, providing information in ISO 10646 character sets, providing
internationalization support. internationalization support.
In addition to encoding method parameters, XML is used in WebDAV to In addition to encoding method parameters, XML is used in WebDAV to
encode the responses from methods, providing the extensibility and encode the responses from methods, providing the extensibility and
internationalization advantages of XML for method output, as well as internationalization advantages of XML for method output, as well as
input. input.
When XML is used for a request or response body, the Content-Type
type SHOULD be application/xml. Implementations MUST accept both
text/xml and application/xml in request and response bodies. Use of
text/xml is deprecated.
All DAV compliant clients and resources MUST use XML parsers that are All DAV compliant clients and resources MUST use XML parsers that are
compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in either compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in either
requests or responses MUST be, at minimum, well formed and use requests or responses MUST be, at minimum, well formed and use
namespaces correctly. If a server receives XML that is not well- namespaces correctly. If a server receives XML that is not well-
formed then the server MUST reject the entire request with a 400 (Bad formed then the server MUST reject the entire request with a 400 (Bad
Request). If a client receives XML that is not well-formed in a Request). If a client receives XML that is not well-formed in a
response then the client MUST NOT assume anything about the outcome response then the client MUST NOT assume anything about the outcome
of the executed method and SHOULD treat the server as malfunctioning. of the executed method and SHOULD treat the server as malfunctioning.
Note that processing XML submitted by an untrusted source may cause Note that processing XML submitted by an untrusted source may cause
skipping to change at page 35, line 31 skipping to change at page 37, line 37
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. Note that HTTP 1.1 requires the
Date header in all responses if possible (see section 14.18, Date header in all responses if possible (see section 14.18,
[RFC2616]). [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 the ETag header in responses to GET HTTP 1.1 recommends the use of ETags rather than modification dates,
and PUT requests. Correct use of ETags is even more important in a for cache-control, and there are even stronger reasons to prefer
distributed authoring environment, because ETags are necessary along ETags for authoring. Correct use of ETags is even more important in
with locks to avoid the lost-update problem. A client might fail to a distributed authoring environment, because ETags are necessary
renew a lock, for example when the lock times out and the client is along with locks to avoid the lost-update problem. A client might
accidentally offline or in the middle of a long upload. When a fail to renew a lock, for example when the lock times out and the
client fails to renew the lock, it's quite possible the resource can client is accidentally offline or in the middle of a long upload.
still be relocked and the user can go on editing, as long as no When a client fails to renew the lock, it's quite possible the
changes were made in the meantime. ETags are required for the client resource can still be relocked and the user can go on editing, as
to be able to distinguish this case. Otherwise, the client is forced long as no changes were made in the meantime. ETags are required for
to ask the user whether to overwrite the resource on the server the client to be able to distinguish this case. Otherwise, the
without even being able to tell the user whether it has changed. client is forced to ask the user whether to overwrite the resource on
Timestamps do not solve this problem nearly as well as ETags. the server without even being able to tell the user whether it has
changed. Timestamps do not solve this problem nearly as well as
ETags.
Strong ETags are much more useful for authoring use cases than weak Strong ETags are much more useful for authoring use cases than weak
ETags. Semantic equivalence can be a useful concept but that depends ETags. Semantic equivalence can be a useful concept but that depends
on the document type and the application type, and interoperability on the document type and the application type, and interoperability
might require some agreement or standard outside the scope of this might require some agreement or standard outside the scope of this
specification and HTTP. Note also that weak ETags have certain specification and HTTP. Note also that weak ETags have certain
restrictions in HTTP, e.g. these cannot be used in If-Match headers. restrictions in HTTP, e.g. these cannot be used in If-Match headers.
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). It is in the formatting or content of the document upon storage). This is
hoped that future specification work will clarify this confusion. an HTTP issue, not purely a WebDAV issue, and is being addressed in
[I-D.draft-whitehead-http-etag].
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 body or
contents of the resource. There is no similar way to tell if contents of the resource. There is no similar way to tell if
properties have changed. properties have changed.
8.7. Including error response bodies 8.7. Including error response bodies
skipping to change at page 39, line 19 skipping to change at page 41, line 19
describes the results of the attempts to retrieve the various describes the results of the attempts to retrieve the various
properties. properties.
If there is an error retrieving a property then a proper error result If there is an error retrieving a property then a proper error result
MUST be included in the response. A request to retrieve the value of MUST be included in the response. A request to retrieve the value of
a property which does not exist is an error and MUST be noted, if the a property which does not exist is an error and MUST be noted, if the
response uses a 'multistatus' XML element, with a 'response' XML response uses a 'multistatus' XML element, with a 'response' XML
element which contains a 404 (Not Found) status value. element which contains a 404 (Not Found) status value.
Consequently, the 'multistatus' XML element for a collection resource Consequently, the 'multistatus' XML element for a collection resource
with member URLs MUST include a 'response' XML element for each MUST include a 'response' XML element for each member URL of the
member URL of the collection, to whatever depth was requested. Each collection, to whatever depth was requested. It SHOULD NOT include
'response' XML element MUST contain an 'href' XML element that any 'response' elements for resources that are not WebDAV-compliant.
contains the URL of the resource on which the properties in the prop Each 'response' element MUST contain an 'href' element that contains
XML element are defined. Results for a PROPFIND on a collection the URL of the resource on which the properties in the prop XML
resource with internal member URLs are returned as a flat list whose element are defined. Results for a PROPFIND on a collection resource
order of entries is not significant. Note that a resource may have are returned as a flat list whose order of entries is not
only one value for a property of a given name, so the property may significant. Note that a resource may have only one value for a
only show up once in PROPFIND responses. property of a given name, so the property may only show up once in
PROPFIND responses.
Properties may be subject to access control. In the case of Properties may be subject to access control. In the case of
'allprop' and 'propname' requests, if a principal does not have the 'allprop' and 'propname' requests, if a principal does not have the
right to know whether a particular property exists then the property right to know whether a particular property exists then the property
MAY be silently excluded from the response. MAY be silently excluded from the response.
Some PROPFIND results MAY be cached, with care as there is no cache Some PROPFIND results MAY be cached, with care as there is no cache
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]).
skipping to change at page 65, line 5 skipping to change at page 67, line 5
If the resource has other (shared) locks, those locks are unaffected If the resource has other (shared) locks, those locks are unaffected
by a lock refresh. Additionally, those locks do not prevent the by a lock refresh. Additionally, those locks do not prevent the
named lock from being refreshed. named lock from being refreshed.
Note that in [RFC2518], clients were indicated through the example in Note that in [RFC2518], clients were indicated through the example in
the text to use the If header to specify what lock to refresh (rather the text to use the If header to specify what lock to refresh (rather
than the Lock-Token header). Servers are encouraged to continue to than the Lock-Token header). Servers are encouraged to continue to
support this as well as the Lock-Token header. support this as well as the Lock-Token header.
Note that the Lock-Token header is not be returned in the response Note that the Lock-Token header is not returned in the response for a
for a successful refresh LOCK request, but the LOCK response body successful refresh LOCK request, but the LOCK response body MUST
MUST contain the new value for the DAV:lockdiscovery body. contain the new value for the DAV:lockdiscovery body.
9.10.3. Depth and Locking 9.10.3. Depth and Locking
The Depth header may be used with the LOCK method. Values other than The Depth header may be used with the LOCK method. Values other than
0 or infinity MUST NOT be used with the Depth header on a LOCK 0 or infinity MUST NOT be used with the Depth header on a LOCK
method. All resources that support the LOCK method MUST support the method. All resources that support the LOCK method MUST support the
Depth header. Depth header.
A Depth header of value 0 means to just lock the resource specified A Depth header of value 0 means to just lock the resource specified
by the Request-URI. by the Request-URI.
skipping to change at page 75, line 32 skipping to change at page 77, line 32
attempt a copy to the remote server, it MUST fail the request. Note attempt a copy to the remote server, it MUST fail the request. Note
that copying and moving resources to remote servers is not fully that copying and moving resources to remote servers is not fully
defined in this specification (e.g. specific error conditions). defined in this 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
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
No-tag-list = List
Tagged-list = Resource 1*List
Resource = Coded-Reference
List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
; No LWS allowed between "[", entity-tag and "]"
State-token = Coded-URL
Coded-Reference = "<" Simple-ref ">"
; No LWS allowed in Coded-Reference
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. The <DAV:no- the If header handles any state token as well as ETags. A typical
lock> state token is an example of a state token that will never example of a state token is a lock token, and lock tokens are the
match an actual valid lock token (not that it's special in this only state tokens defined in this specification.
regard). The purpose of this is described in Section 10.4.4.
The If header's purpose is to describe a series of state lists. If
the state of the resource to which the header is applied does not
match any of the specified state lists then the request MUST fail
with a 412 (Precondition Failed). If one of the described state
lists matches the state of the resource then the request may succeed.
Because of error handling precedence rules (see Section 8.1), the
server checks for permissions before checking the If header.
Assuming no permission failures or other errors, the server MUST
parse the If header when it appears on any request, evaluate all the
clauses, and if the conditional evaluates to false, fail as described
above.
10.4.1. No-tag-list Production 10.4.1. Purpose
The No-tag-list production describes a series of state tokens and The If header has two distinct purposes:
ETags. If multiple No-tag-list productions are used then one only
needs to match the state of the resource for the method to be allowed
to continue. All untagged tokens apply to the resource identified in
the Request-URI.
Example - no-tag-list production o The first purpose is to make a request conditional by supplying a
series of state lists with conditions that match tokens and ETags
to specific resource. If this header is evaluated and all state
lists fail, then the request MUST fail with a 412 (Precondition
Failed) status. On the other hand, the request can succeed only
if one of the described state lists succeeds. The success
criteria for state lists and matching functions are defined in
Section 10.4.3 and Section 10.4.4.
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> o Additionally, the mere fact that a state token appears in an If
["I am an ETag"]) (["I am another ETag"]) header means that is has been "submitted" with the request. In
general, this is used to indicate that the client has knowledge of
that state token. The meaning of submitting a state token depends
on its type (for lock tokens, please refer to Section 6).
The previous header would require that the resource identified in the Note that these two purposes need to be treated distinctly: a state
Request-URI be locked with the specified lock token and in the state token counts as being submitted independently of whether the server
identified by the "I am an ETag" ETag or in the state identified by actually has evaluated the state list it appears in, and also
the second ETag "I am another ETag". To put the matter more plainly independently of whether the condition it expressed was found to be
one can think of the previous If header as being in the form (or (and true or not.
<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> ["I am an ETag"])
(and ["I am another ETag"])).
10.4.2. Tagged-list Production 10.4.2. Syntax
The tagged-list production may be used instead of the no-tag-list If = "If" ":" ( 1*No-tag-list | 1*Tagged-list )
production, in order to scope each token to a specific resource.
That is, it specifies that the lists following the resource
specification only apply to the specified resource. The scope of the
resource production begins with the list production immediately
following the resource production and ends with the next resource
production, if any. All clauses must be evaluated. If the state of
the resource named in the tag does not match any of the associated
state lists then the request MUST fail with a 412 (Precondition
Failed).
The same URI MUST NOT appear more than once in a resource production No-tag-list = List
in an If header. Tagged-list = Resource-Tag 1*List
10.4.3. Example - Tagged List If header in COPY List = "(" 1*Condition ")"
Condition = ["Not"] (State-token | "[" entity-tag "]")
; entity-tag: see Section 3.11 of [RFC2616]
; No LWS allowed between "[", entity-tag and "]"
>>Request State-token = Coded-URL
COPY /resource1 HTTP/1.1 Resource-Tag = "<" Simple-ref ">"
Host: www.example.com ; Simple-ref: see Section 8.3
Destination: http://www.example.com/resource2 ; No LWS allowed in Resource-Tag
If: </resource1>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
[W/"A weak ETag"]) (["strong ETag"])
</random>
(["another strong ETag"])
In this example http://www.example.com/resource1 is being copied to The syntax distinguishes between untagged lists ("No-tag-list") and
http://www.example.com/resource2. When the method is first applied tagged lists ("Tagged-list"). Untagged lists apply to the resource
to http://www.example.com/resource1, resource1 must be in the state identified by the Request-URI, while tagged lists apply to the
specified by "(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A resource identified by the preceding Resource-Tag.
weak ETag"]) (["strong ETag"])", that is, it either must be locked
with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2"
and have a weak entity tag W/"A weak ETag" or it must have a strong
entity tag "strong ETag".
That is the only success condition since the resource A Resource-Tag applies to all subsequent Lists, up to the next
http://www.example.com/random never has the method applied to it (the Resource-Tag.
only other resource listed in the If header) and
http://www.example.com/resource2 is not listed in the If header.
10.4.4. Not Production Note that the two list types cannot be mixed within an If header.
This is not a functional restriction because the No-tag-list syntax
is just a shorthand notation for a Tagged-list production with a
Resource-Tag referring to the Request-URI.
Every state token or ETag is either current, and hence describes the Each List consists of one or more Conditions. Each Condition is
state of a resource, or is not current, and does not describe the defined in terms of an entity-tag or state-token, potentially negated
state of a resource. The boolean operation of matching a state token by the prefix "Not".
or ETag to the current state of a resource thus resolves to a true or
false value. The "Not" production is used to reverse that value.
The scope of the not production is the state-token or entity-tag
immediately following it.
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> Note that the If header syntax does not allow multiple instances of
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>) If headers in a single request. However, the HTTP header syntax
allows extending single header values across multiple lines, by
inserting a line break followed by whitespace (see [RFC2616], Section
4.2).
When submitted with a request, this If header requires that all 10.4.3. List Evaluation
operand resources must not be locked with
urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked with
urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.
The Not production is particularly useful with a state token that A Condition that consists of a single entity-tag or state-token
never identifies a lock, such as the "<DAV:no-lock>" state token. evaluates to true if the resource matches the described state (where
The server MUST evaluate any unrecognized state token as false. the individual matching functions are defined below in
Section 10.4.4). Prefixing it with "Not" reverses the result of the
evaluation (thus, the "Not" applies only to the subsequent entity-tag
or state-token).
Thus, for example: Each List production describes a series of conditions. The whole
list evaluates to true if and only if each condition evaluates to
true (that is, the list represents a logical conjunction of
Conditions).
The clause "Not <DAV:no-lock>" evaluates to true. Each No-tag-list and Tagged-list production may contain one or more
Lists. They evaluate to true if and only if any of the contained
lists evaluates to true (that is, if there's more than one List, that
List sequence represents a logical disjunction of the Lists).
Any "OR" statement containing the clause "Not <DAV:no-lock>" Finally, the whole If header evaluates to true if and only if at
evaluates to true. least one of the No-tag-list or Tagged-list productions evaluates to
true. If the header evaluates to false, the server MUST reject the
request with a 412 (Precondition Failed) status. Otherwise,
execution of the request can proceed as if the header wasn't present.
10.4.5. Matching Function 10.4.4. Matching State Tokens and ETags
When performing If header processing, the definition of a matching When performing If header processing, the definition of a matching
state token or entity tag is as follows. state token or entity tag is as follows:
Identifying a resource: The resource is identified by the URI along Identifying a resource: The resource is identified by the URI along
with the token, in tagged list production, or by the Request-URI in with the token, in tagged list production, or by the Request-URI in
untagged list production. untagged list production.
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. associated with the identified resource. Servers MUST use either the
weak or the strong comparison function defined in Section 13.3.3 of
[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.
Example - Matching lock tokens with collection locks Handling unmapped URLs: for both ETags and state tokens, treat as if
the URL identified a resource that exists but does not have the
specified state.
10.4.5. If Header and Non-DAV Aware Proxies
Non-DAV aware proxies will not honor the If header, since they will
not understand the If header, and HTTP requires non-understood
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
prevent the proxy from improperly trying to service the request from
its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache"
request header MUST be used for the same reason.
As in general clients may not be able to reliably detect non-DAV
aware intermediates, they are advised to always prevent caching using
the request directives mentioned above.
10.4.6. Example - No-tag Production
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
["I am an ETag"])
(["I am another ETag"])
The previous header would require that the resource identified in the
Request-URI be locked with the specified lock token and be in the
state identified by the "I am an ETag" ETag or in the state
identified by the second ETag "I am another ETag".
To put the matter more plainly one can think of the previous If
header as expressing the condition below:
(
is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND
matches-etag("I am an ETag")
)
OR
(
matches-etag("I am another ETag")
)
10.4.7. Example - using "Not" with No-tag Production
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
This If header requires that the resource must not be locked with a
lock having the lock token
urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked by a
lock with the lock token
urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.
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
doesn't want the request to fail just because the state token isn't
current anymore. One simple way to do this is to include a Condition
that is known to always evaluate to true, such as in:
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
(Not <DAV:no-lock>)
"DAV:no-lock" is known to never represent a current lock token, as
lock tokens are assigned by the server, following the uniqueness
requirements described in Section 6.5, therefore in particular
exclude URIs in the "DAV:" scheme. Thus, by applying "Not" to a
known not to be current state token, the Condition always evaluates
to true. Consequently, the whole If header will always evaluate to
true, and the lock token
urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 will be submitted in
any case.
10.4.9. Example - Tagged List If header in COPY
>>Request
COPY /resource1 HTTP/1.1
Host: www.example.com
Destination: /resource2
If: </resource1>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
[W/"A weak ETag"]) (["strong ETag"])
In this example http://www.example.com/resource1 is being copied to
http://www.example.com/resource2. When the method is first applied
to http://www.example.com/resource1, resource1 must be in the state
specified by "(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A
weak ETag"]) (["strong ETag"])", that is, it either must be locked
with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2"
and have a weak entity tag W/"A weak ETag" or it must have a strong
entity tag "strong ETag".
10.4.10. Example - Matching lock tokens with collection locks
DELETE /specs/rfc2518.txt HTTP/1.1 DELETE /specs/rfc2518.txt HTTP/1.1
Host: www.example.com Host: www.example.com
If: <http://www.example.com/specs/> If: <http://www.example.com/specs/>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>) (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
For this example, the lock token must be compared to the identified For this example, the lock token must be compared to the identified
resource, which is the 'specs' collection identified by the URL in resource, which is the 'specs' collection identified by the URL in
the tagged list production. If the 'specs' collection is not locked the tagged list production. If the 'specs' collection is not locked
or has a lock with a different token, the request MUST fail. If the by a lock with the specified lock token, the request MUST fail.
'specs' collection is locked (depth infinity) with that lock token, Otherwise, this request could succeed, because the If header
then this request could succeed, both because the If header evaluates evaluates to true, and because the lock token for the lock affecting
to true, and because the lock token for the lock affecting the the affected resource has been submitted.
affected resource has been provided. Alternatively, a request where
the 'rfc2518.txt' URL is associated with the lock token in the If
header could also succeed.
10.4.6. If Header and Non-DAV Aware Proxies 10.4.11. Example - Matching ETags on unmapped URLs
Non-DAV aware proxies will not honor the If header, since they will Consider a collection "/specs" that does not contain the member
not understand the If header, and HTTP requires non-understood "/specs/rfc2518.doc". In this case, the If header
headers to be ignored. When communicating with HTTP/1.1 proxies, the
"Cache-Control: no-cache" request header MUST be used so as to If: </specs/rfc2518.doc> (["4217"])
prevent the proxy from improperly trying to service the request from
its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" will evaluate to false (the URI isn't mapped, thus the resource
request header MUST be used for the same reason. identified by the URI doesn't have an entity matching the ETag
"4217").
On the other hand, an If header of
If: </specs/rfc2518.doc> (Not ["4217"])
will consequently evaluate to true.
Note that as defined above in Section 10.4.4, the same considerations
apply to matching state tokens.
10.5. Lock-Token Header 10.5. Lock-Token Header
Lock-Token = "Lock-Token" ":" Coded-URL Lock-Token = "Lock-Token" ":" Coded-URL
The Lock-Token request header is used with the UNLOCK method to The Lock-Token request header is used with the UNLOCK method to
identify the lock to be removed. The lock token in the Lock-Token identify the lock to be removed. The lock token in the Lock-Token
request header MUST identify a lock that contains the resource request header MUST identify a lock that contains the resource
identified by Request-URI as a member. identified by Request-URI as a member.
skipping to change at page 79, line 50 skipping to change at page 83, line 28
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
Clients MAY include Timeout request headers in their Section 9.10 Clients MAY include Timeout request headers in their LOCK requests.
requests. However, the server is not required to honor or even However, the server is not required to honor or even consider these
consider these requests. Clients MUST NOT submit a Timeout request requests. Clients MUST NOT submit a Timeout request header with any
header with any method other than a LOCK method. method other than a LOCK method.
The "Second" TimeType specifies the number of seconds that will The "Second" TimeType specifies the number of seconds that will
elapse between granting of the lock at the server, and the automatic elapse between granting of the lock at the server, and the automatic
removal of the lock. The timeout value for TimeType "Second" MUST removal of the lock. The timeout value for TimeType "Second" MUST
NOT be greater than 2^32-1. NOT be greater than 2^32-1.
See Section 6.6 for a description of lock timeout behavior. See Section 6.6 for a description of lock timeout behavior.
11. Status Code Extensions to HTTP/1.1 11. Status Code Extensions to HTTP/1.1
skipping to change at page 107, line 38 skipping to change at page 110, line 38
property values where unexpected XML elements SHOULD be ignored property values where unexpected XML elements SHOULD be ignored
unless the property's schema declares otherwise. unless the property's schema declares otherwise.
This restriction does not apply to setting dead DAV properties on the This restriction does not apply to setting dead DAV properties on the
server where the server MUST record all XML elements. server where the server MUST record all XML elements.
Additionally, this restriction does not apply to the use of XML where Additionally, this restriction does not apply to the use of XML where
XML happens to be the content type of the entity body, for example, XML happens to be the content type of the entity body, for example,
when used as the body of a PUT. when used as the body of a PUT.
When XML is used for a request or response body, the Content-Type
type SHOULD be application/xml. Implementations MUST accept both
text/xml and application/xml in request and response bodies. Use of
text/xml is deprecated.
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 All elements defined in this specification use the "DAV:" o All elements defined in this specification use the "DAV:"
skipping to change at page 122, line 10 skipping to change at page 125, line 10
Cullen Jennings helped close many issues. Barry Lind described an Cullen Jennings helped close many issues. Barry Lind described an
additional security consideration and Cullen Jennings provided text additional security consideration and Cullen Jennings provided text
for that consideration. Jason Crawford tracked issue status for this for that consideration. Jason Crawford tracked issue status for this
document for a period of years, followed by Elias Sinderson. document for a period of years, followed by Elias Sinderson.
23. Contributors to This Specification 23. Contributors to This Specification
Julian Reschke, Julian Reschke,
<green/>bytes GmbH, <green/>bytes GmbH,
Hafenweg 16, 48155 Muenster, Germany, Hafenweg 16, 48155 Muenster, Germany,
Email: reschke@greenbytes.de Email: julian.reschke@greenbytes.de
Elias Sinderson Elias Sinderson
University of California, Santa Cruz
1156 High Street, Santa Cruz, CA 95064
Email: elias@cse.ucsc.edu Email: elias@cse.ucsc.edu
[address needed]
Jim Whitehead, Jim Whitehead,
University of California, Santa Cruz University of California, Santa Cruz
1156 High Street, Santa Cruz, CA 95064 1156 High Street, Santa Cruz, CA 95064
Email: ejw@soe.ucsc.edu Email: ejw@soe.ucsc.edu
24. Authors of RFC2518 24. Authors of RFC2518
Y. Y. Goland, Y. Y. Goland,
Microsoft Corporation, Microsoft Corporation,
skipping to change at page 125, line 7 skipping to change at page 128, line 7
[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
[I-D.draft-whitehead-http-etag]
Whitehead, J., "ETags in HTTP PUT Responses",
draft-whitehead-http-etag-00 (work in progress),
February 2006.
[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.
[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.
skipping to change at page 128, line 28 skipping to change at page 131, line 28
not present any issues: 422, 423 and 507 (424 is also a new status not present any issues: 422, 423 and 507 (424 is also a new status
code but it appears only in the body of a Multistatus response.) So, code but it appears only in the body of a Multistatus response.) So,
for example, if a HTTP client attempted to PUT or DELETE a locked for example, if a HTTP client attempted to PUT or DELETE a locked
resource, the 423 Locked response ought to result in a generic error resource, the 423 Locked response ought to result in a generic error
presented to the user. presented to the user.
The 207 Multistatus response is interesting because a HTTP client The 207 Multistatus response is interesting because a HTTP client
issuing a DELETE request to a collection might interpret a 207 issuing a DELETE request to a collection might interpret a 207
response as a success, even though it does not realize the resource response as a success, even though it does not realize the resource
is a collection and cannot understand that the DELETE operation might is a collection and cannot understand that the DELETE operation might
have been a complete or partial failure. Thus, a server MAY choose have been a complete or partial failure. That interpretation isn't
to treat a DELETE of a collection as an atomic operation, and use entirely justified, because a 200-level response indicates that the
either 204 No Content in case of success, or some appropriate error server "received, understood and accepted" the request, not that the
response (400 or 500 level) depending on what the error was. This request resulted in complete success.
approach would maximize backward compatibility. However, since
interoperability tests and working group discussions have not turned One option is that a server could treat a DELETE of a collection as
up any instances of HTTP clients issuing a DELETE request against a an atomic operation, and use either 204 No Content in case of
WebDAV collection, this concern may be more theoretical than success, or some appropriate error response (400 or 500 level) for an
practical. Thus, servers MAY instead choose to treat any such DELETE error. This approach would indeed maximize backward compatibility.
request as a WebDAV request, and send a 207 Multistatus containing However, since interoperability tests and working group discussions
more detail about what resources could not be deleted. have not turned up any instances of HTTP clients issuing a DELETE
request against a WebDAV collection, this concern is more theoretical
than practical. Thus, servers are likely to be completely successful
at interoperating with HTTP clients even if they treat any collection
DELETE request as a WebDAV request and send a 207 Multistatus
response.
In general server implementations are encouraged to use the detailed In general server implementations are encouraged to use the detailed
responses defined in this document and to avoid attempts to detect responses and other mechanisms defined in this document rather than
client version or to determine client compatibility. make changes for theoretical interoperability concerns.
Appendix C. The opaquelocktoken scheme and URIs Appendix C. The opaquelocktoken scheme and URIs
The 'opaquelocktoken' URI scheme was defined in [RFC2518] (and The 'opaquelocktoken' URI scheme was defined in [RFC2518] (and
registered by IANA) in order to create syntactically correct and registered by IANA) in order to create syntactically correct and
easy-to-generate URIs out of UUIDs, intended to be used as lock easy-to-generate URIs out of UUIDs, intended to be used as lock
tokens and to be unique across all resources for all time. tokens and to be unique across all resources for all time.
An opaquelocktoken URI is constructed by concatenating the An opaquelocktoken URI is constructed by concatenating the
'opaquelocktoken' scheme with a UUID, along with an optional 'opaquelocktoken' scheme with a UUID, along with an optional
skipping to change at page 132, line 7 skipping to change at page 135, line 7
PROPFIND /docs/ HTTP/1.1 PROPFIND /docs/ HTTP/1.1
Host: www.example.com Host: www.example.com
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-type: application/xml; charset="utf-8" Content-type: application/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxxx
[body omitted] [body omitted]
Appendix E. Summary of changes from RFC2518 Appendix E. Summary of changes from RFC2518
This section lists changes that are likely to result in This section lists major changes between this document and RFC2518,
implementation changes due to tightened requirements or changed starting with those that are likely to result in implementation
behavior. changes. Servers will advertise support for all changes in this
specification by returning the compliance class "3" in the DAV
response header (see Sections 10.1 and 18.3).
E.1. Changes for both Clients and Servers E.1. Changes for both Client and Server Implementations
New value for "DAV:" header (Section 10.1) to advertise support for Collections and Namespace Operations
this specification.
Replaced lock-null resources with simpler locked empty resources o The semantics of PROPFIND 'allprop' (Section 9.1) have been
(Section 7.3). relaxed so that servers may leave out live properties defined in
other specifications, such as [RFC3253] and [RFC3744]. Related to
this, 'allprop' requests can now be extended with the 'include'
syntax to include specific named properties, thereby avoiding
additional requests due to changed 'allprop' semantics.
Support for UTF-16 now required (ref (Section 19)). o Servers are now allowed to reject PROPFIND requests with Depth:
Infinity. Clients that used this will need to be able to do a
series of Depth:1 requests instead.
Changed meaning of PROPFIND 'allprop' so that it doesn't have to o Multistatus response bodies now can transport the value of HTTP's
return live properties not defined in this specification; added Location response header in the new 'location' element. Clients
'include' syntax so that clients can retrieve specific live may use this to avoid additional roundtrips to the server when
properties along with 'allprop' results. there is a 'response' element with a 3xx status (see
Section 14.24).
Changes in LOCK refresh (not implicit anymore, uses LOCK without body o The definition of COPY has been relaxed so that it doesn't require
with Lock-Token request header) servers to first delete the target resources anymore (this was a
known incompatibility with [RFC3253]). See Section 9.8.
New element 'location' defined for handling redirected resources in Headers and Marshalling
Multi-Status.
Defined response bodies for error responses, including several o The Destination and If request headers now allow absolute paths in
machine-readable precondition or postcondition codes (Section 16) for addition to full URIs (see Section 8.3). This may be useful for
error detail. clients operating through a reverse proxy that does rewrite the
Host request header, but not WebDAV-specific headers.
Removed definition of "source" property and special handling for o This specification adopts the error marshalling extensions and the
dynamic resources. "precondition/postcondition" terminology defined in [RFC3253] (see
Section 16). Related to that, it adds the "error" XML element
inside multistatus response bodies (see Section 14.5, however note
that it uses a format different from the one recommend in
RFC3253).
The definition of the 102 Processing response was removed and servers o Senders and recipients are now required to support the UTF-16
ought to stop sending that response when they implement this character encoding in XML message bodies (see Section 19).
specification; clients may be able to remove code that handles this.
E.2. Changes Notable to Server Implementors Locking
Tightened requirements for storing property values (Section 4.3) when o RFC2518's concept of "lock-null resources" (LNRs) has been
"xml:lang" appears and also when values are XML fragments replaced by a simplified approach, the "locked empty resources"
(specifically on preserving prefixes, namespaces and whitespace.) (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
create a locked collection or the fact that they disappear upon
UNLOCK when no PUT or MKCOL request was issued. Note that servers
are still allowed to implement LNRs as per RFC2518.
Tightened requirements on which properties are protected and computed o There is no implicit refresh of locks anymore. Locks are only
(Section 15). refreshed upon explicit request. Furthermore, the lock token for
the lock to be refreshed is now specified in the Lock-Token
request header rather than the If header (see Section 9.10.2).
Several tightened requirements for general response handling o Clarified that the DAV:owner value supplied in the LOCK request
(Section 8), including ETag and Location header, and reminder to use must be preserved by the server just like a dead property
Date header. (Section 14.17). Also added the DAV:lockroot element
(Section 14.12) which allows clients to discover the root of lock.
Requirements for URL construction in Multi-Status responses, E.2. Changes for Server Implementations
Destination and If headers: more consistent and mostly tighter
requirements.
Tightened requirements for checking identity of lock creators Collections and Namespace Operations
(Section 6.4) during operations affected by locks.
Tightened requirements for copying properties (Section 9.8.2) and o Due to interoperability problems, allowable formats for contents
moving properties (Section 9.9.1). of 'href' elements in multistatus responses have been limited (see
Section 8.3).
Tightened requirements on preserving 'owner' field in locks o Due to lack of implementation, support for the 'propertybehaviour'
(Section 9.10). Added "lockroot" element to lockdiscovery request body for COPY and MOVE has been removed. Instead,
information. requirements for property preservation have been clarified (see
Sections 9.8 and 9.9).
Some changes for "If:" header (Section 10.4) handling, including Properties
"DAV:no-lock" state token.
Encouraged servers to change ETags (Section 8.6) only when body of o Strengthened server requirements for storage of property values,
resource changes. in particular persistence of language information (xml:lang),
whitespace, and XML namespace information (see Section 4.3).
Previously, servers were encouraged to return 409 status code in o Clarified requirements on which properties should be writeable by
response to a collection LOCK request if some resource could not be the client; in particular, setting "DAV:displayname" should be
locked. Now servers should use 207 Multi-Status instead. supported by servers (see Section 15).
Only 'rfc1123-date' productions are legal as values for DAV: o Only 'rfc1123-date' productions are legal as values for DAV:
getlastmodified. getlastmodified (see Section 15.7).
New explicit requirement to do authorization checks before Headers and Marshalling
conditional checks (Section 8.5).
Defined idempotence, safeness and cacheability for all new methods. o Servers are now required to do authorization checks before
processing conditional headers (see Section 8.5).
Depth: Infinity doesn't affect other headers; by default these Locking
headers only apply to the Request-URI (Section 10.4).
E.3. Changes Notable to Client Implementors o Strengthened requirement to check identity of lock creator when
accessing locked resources (see Section 6.4). Clients should be
aware that lock tokens returned to other principals can only be
used to break a lock, if at all.
Tightened requirements for supporting WebDAV collections o Section 8.10.4 of [RFC2518] incorrectly required servers to return
(Section 5.2) within resources that do not support WebDAV (e.g. a 409 status where a 207 status was really appropriate. This has
servlet containers). been corrected (Section 9.10).
Servers are no longer required to support all depth "infinity" E.3. Other Changes
PROPFIND requests, so clients need to be able to handle that and do
multiple depth "1" requests instead.
No more "propertybehavior" specification allowed in MOVE and COPY The definition of collection state has been fixed so it doesn't vary
requests anymore depending on the Request-URI (see Section 5.2).
The change in behavior of LOCK with an unmapped URL might affect The DAV:source property introduced in Section 4.6 of [RFC2518] was
client implementations that counted on lock-null resources removed due to lack of implementation experience.
disappearing when the lock expired. Clients can no longer rely on
that cleanup happening.
Clients use Lock-Token header, not the If header, to provide lock The DAV header now allows non-IETF extensions through URIs in
token when renewing lock. Section 9.10.2 addition to compliance class tokens. It also can now be used in
requests, although this specification does not define any associated
semantics for the compliance classes defined in here (see
Section 10.1).
Clients must refresh locks explicitly as this is now the only way to In RFC2518, the definition of the Depth header (Section 9.2) required
renew timeout. that by default request headers would be applied to each resource in
scope. Based on implementation experience, the default has now been
reversed (see Section 10.2).
The definitions of HTTP status code 102 ([RFC2518], Section 10.1) and
the Status-URI response header (Section 9.7) have been removed due to
lack of implementation.
The TimeType format used in the Timeout request header and the
"timeout" XML element used to be extensible. Now, only the two
formats defined by this specification are allowed (see Section 10.7).
Appendix F. Change Log (to be removed by RFC Editor before publication) Appendix F. Change Log (to be removed by RFC Editor before publication)
F.1. Changes from -05 to -06 F.1. Changes from -05 to -06
Specified that a successful LOCK request to an unmapped URL creates a Specified that a successful LOCK request to an unmapped URL creates a
new, empty locked resource. new, empty locked resource.
Resolved UNLOCK_NEEDS_IF_HEADER by clarifying that only Lock-Token Resolved UNLOCK_NEEDS_IF_HEADER by clarifying that only Lock-Token
header is needed on UNLOCK. header is needed on UNLOCK.
skipping to change at page 140, line 5 skipping to change at page 142, line 24
Fixed the definition of collection state (bug 227). Fixed the definition of collection state (bug 227).
Made the depth header required on PROPFIND requests (bug 213). Made the depth header required on PROPFIND requests (bug 213).
Fixed inconsistencies in Destination header definition (bug 211). Fixed inconsistencies in Destination header definition (bug 211).
Improved appendix on HTTP client compatibility (bug 100). Improved appendix on HTTP client compatibility (bug 100).
Fixed external references with unwieldy pointers (bug 72). Fixed external references with unwieldy pointers (bug 72).
F.9. Changes in -14
Changes section rewritten, if section rewritten
Collection definition and membership requirements changed (bug 227)
Bug 100 and 229 iterations, smallish editorial changes
Author's Address Author's Address
Lisa Dusseault (editor) Lisa Dusseault (editor)
Open Source Application Foundation Open Source Application Foundation
2064 Edgewood Dr. 2064 Edgewood Dr.
Palo Alto, CA 94303 Palo Alto, CA 94303
US US
Email: lisa@osafoundation.org Email: lisa@osafoundation.org
 End of changes. 88 change blocks. 
498 lines changed or deleted 652 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/