< draft-ietf-webdav-rfc2518bis-17.txt   draft-ietf-webdav-rfc2518bis-18.txt >
WebDAV L. Dusseault, Ed. WebDAV L. Dusseault, Ed.
Internet-Draft CommerceNet Internet-Draft CommerceNet
Obsoletes: 2518 (if approved) December 1, 2006 Obsoletes: 2518 (if approved) February 15, 2007
Intended status: Standards Track Intended status: Standards Track
Expires: June 4, 2007 Expires: August 19, 2007
HTTP Extensions for Distributed Authoring - WebDAV HTTP Extensions for Distributed Authoring - WebDAV
draft-ietf-webdav-rfc2518bis-17 draft-ietf-webdav-rfc2518bis-18
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 June 4, 2007. This Internet-Draft will expire on August 19, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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.
skipping to change at page 2, line 46 skipping to change at page 2, line 46
6.6. Lock Timeout . . . . . . . . . . . . . . . . . . . . . . 25 6.6. Lock Timeout . . . . . . . . . . . . . . . . . . . . . . 25
6.7. Lock Capability Discovery . . . . . . . . . . . . . . . 25 6.7. Lock Capability Discovery . . . . . . . . . . . . . . . 25
6.8. Active Lock Discovery . . . . . . . . . . . . . . . . . 26 6.8. Active Lock Discovery . . . . . . . . . . . . . . . . . 26
7. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Write Locks and Properties . . . . . . . . . . . . . . . 27 7.1. Write Locks and Properties . . . . . . . . . . . . . . . 27
7.2. Avoiding Lost Updates . . . . . . . . . . . . . . . . . 28 7.2. Avoiding Lost Updates . . . . . . . . . . . . . . . . . 28
7.3. Write Locks and Unmapped URLs . . . . . . . . . . . . . 29 7.3. Write Locks and Unmapped URLs . . . . . . . . . . . . . 29
7.4. Write Locks and Collections . . . . . . . . . . . . . . 30 7.4. Write Locks and Collections . . . . . . . . . . . . . . 30
7.5. Write Locks and the If Request Header . . . . . . . . . 31 7.5. Write Locks and the If Request Header . . . . . . . . . 31
7.5.1. Example - Write Lock and COPY . . . . . . . . . . . 32 7.5.1. Example - Write Lock and COPY . . . . . . . . . . . 32
7.5.2. Example - Deleting a member of a locked collection . 32 7.5.2. Example - Deleting a Member of a Locked Collection . 32
7.6. Write Locks and COPY/MOVE . . . . . . . . . . . . . . . 33 7.6. Write Locks and COPY/MOVE . . . . . . . . . . . . . . . 33
7.7. Refreshing Write Locks . . . . . . . . . . . . . . . . . 34 7.7. Refreshing Write Locks . . . . . . . . . . . . . . . . . 34
8. General Request and Response Handling . . . . . . . . . . . . 35 8. General Request and Response Handling . . . . . . . . . . . . 35
8.1. Precedence in Error Handling . . . . . . . . . . . . . . 35 8.1. Precedence in Error Handling . . . . . . . . . . . . . . 35
8.2. Use of XML . . . . . . . . . . . . . . . . . . . . . . . 35 8.2. Use of XML . . . . . . . . . . . . . . . . . . . . . . . 35
8.3. URL Handling . . . . . . . . . . . . . . . . . . . . . . 36 8.3. URL Handling . . . . . . . . . . . . . . . . . . . . . . 36
8.3.1. Example - Correct URL Handling . . . . . . . . . . . 36 8.3.1. Example - Correct URL Handling . . . . . . . . . . . 36
8.4. Required Bodies in Requests . . . . . . . . . . . . . . 37 8.4. Required Bodies in Requests . . . . . . . . . . . . . . 37
8.5. HTTP Headers for use in WebDAV . . . . . . . . . . . . . 37 8.5. HTTP Headers for use in WebDAV . . . . . . . . . . . . . 37
8.6. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.6. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.7. Including error response bodies . . . . . . . . . . . . 38 8.7. Including Error Response Bodies . . . . . . . . . . . . 38
8.8. Impact of Namespace Operations on Cache Validators . . . 38 8.8. Impact of Namespace Operations on Cache Validators . . . 38
9. HTTP Methods for Distributed Authoring . . . . . . . . . . . 40 9. HTTP Methods for Distributed Authoring . . . . . . . . . . . 40
9.1. PROPFIND Method . . . . . . . . . . . . . . . . . . . . 40 9.1. PROPFIND Method . . . . . . . . . . . . . . . . . . . . 40
9.1.1. PROPFIND status codes . . . . . . . . . . . . . . . 41 9.1.1. PROPFIND Status Codes . . . . . . . . . . . . . . . 41
9.1.2. Status Codes for use in 'propstat' Element . . . . . 42 9.1.2. Status Codes for Use in 'propstat' Element . . . . . 42
9.1.3. Example - Retrieving Named Properties . . . . . . . 42 9.1.3. Example - Retrieving Named Properties . . . . . . . 42
9.1.4. Example - Using so-called 'allprop' . . . . . . . . 44 9.1.4. Example - Using 'propname' to Retrieve All
9.1.5. Example - Using 'propname' to Retrieve all
Property Names . . . . . . . . . . . . . . . . . . . 44 Property Names . . . . . . . . . . . . . . . . . . . 44
9.1.6. Example - Using 'allprop' . . . . . . . . . . . . . 46 9.1.5. Example - Using So-called 'allprop' . . . . . . . . 46
9.1.6. Example - Using 'allprop' with 'include' . . . . . . 49
9.2. PROPPATCH Method . . . . . . . . . . . . . . . . . . . . 49 9.2. PROPPATCH Method . . . . . . . . . . . . . . . . . . . . 49
9.2.1. Status Codes for use in 'propstat' Element . . . . . 49 9.2.1. Status Codes for Use in 'propstat' Element . . . . . 50
9.2.2. Example - PROPPATCH . . . . . . . . . . . . . . . . 50 9.2.2. Example - PROPPATCH . . . . . . . . . . . . . . . . 51
9.3. MKCOL Method . . . . . . . . . . . . . . . . . . . . . . 51 9.3. MKCOL Method . . . . . . . . . . . . . . . . . . . . . . 52
9.3.1. MKCOL Status Codes . . . . . . . . . . . . . . . . . 52 9.3.1. MKCOL Status Codes . . . . . . . . . . . . . . . . . 53
9.3.2. Example - MKCOL . . . . . . . . . . . . . . . . . . 52 9.3.2. Example - MKCOL . . . . . . . . . . . . . . . . . . 53
9.4. GET, HEAD for Collections . . . . . . . . . . . . . . . 53 9.4. GET, HEAD for Collections . . . . . . . . . . . . . . . 54
9.5. POST for Collections . . . . . . . . . . . . . . . . . . 53 9.5. POST for Collections . . . . . . . . . . . . . . . . . . 54
9.6. DELETE Requirements . . . . . . . . . . . . . . . . . . 53 9.6. DELETE Requirements . . . . . . . . . . . . . . . . . . 54
9.6.1. DELETE for Collections . . . . . . . . . . . . . . . 54 9.6.1. DELETE for Collections . . . . . . . . . . . . . . . 55
9.6.2. Example - DELETE . . . . . . . . . . . . . . . . . . 54 9.6.2. Example - DELETE . . . . . . . . . . . . . . . . . . 55
9.7. PUT Requirements . . . . . . . . . . . . . . . . . . . . 55 9.7. PUT Requirements . . . . . . . . . . . . . . . . . . . . 56
9.7.1. PUT for Non-Collection Resources . . . . . . . . . . 55 9.7.1. PUT for Non-Collection Resources . . . . . . . . . . 56
9.7.2. PUT for Collections . . . . . . . . . . . . . . . . 56 9.7.2. PUT for Collections . . . . . . . . . . . . . . . . 57
9.8. COPY Method . . . . . . . . . . . . . . . . . . . . . . 56 9.8. COPY Method . . . . . . . . . . . . . . . . . . . . . . 57
9.8.1. COPY for Non-collection Resources . . . . . . . . . 56 9.8.1. COPY for Non-collection Resources . . . . . . . . . 57
9.8.2. COPY for Properties . . . . . . . . . . . . . . . . 57 9.8.2. COPY for Properties . . . . . . . . . . . . . . . . 58
9.8.3. COPY for Collections . . . . . . . . . . . . . . . . 57 9.8.3. COPY for Collections . . . . . . . . . . . . . . . . 58
9.8.4. COPY and Overwriting Destination Resources . . . . . 58 9.8.4. COPY and Overwriting Destination Resources . . . . . 59
9.8.5. Status Codes . . . . . . . . . . . . . . . . . . . . 59 9.8.5. Status Codes . . . . . . . . . . . . . . . . . . . . 60
9.8.6. Example - COPY with Overwrite . . . . . . . . . . . 60 9.8.6. Example - COPY with Overwrite . . . . . . . . . . . 61
9.8.7. Example - COPY with No Overwrite . . . . . . . . . . 60 9.8.7. Example - COPY with No Overwrite . . . . . . . . . . 61
9.8.8. Example - COPY of a Collection . . . . . . . . . . . 61 9.8.8. Example - COPY of a Collection . . . . . . . . . . . 62
9.9. MOVE Method . . . . . . . . . . . . . . . . . . . . . . 61 9.9. MOVE Method . . . . . . . . . . . . . . . . . . . . . . 62
9.9.1. MOVE for Properties . . . . . . . . . . . . . . . . 62 9.9.1. MOVE for Properties . . . . . . . . . . . . . . . . 63
9.9.2. MOVE for Collections . . . . . . . . . . . . . . . . 62 9.9.2. MOVE for Collections . . . . . . . . . . . . . . . . 63
9.9.3. MOVE and the Overwrite Header . . . . . . . . . . . 63 9.9.3. MOVE and the Overwrite Header . . . . . . . . . . . 64
9.9.4. Status Codes . . . . . . . . . . . . . . . . . . . . 63 9.9.4. Status Codes . . . . . . . . . . . . . . . . . . . . 64
9.9.5. Example - MOVE of a Non-Collection . . . . . . . . . 64 9.9.5. Example - MOVE of a Non-Collection . . . . . . . . . 65
9.9.6. Example - MOVE of a Collection . . . . . . . . . . . 65 9.9.6. Example - MOVE of a Collection . . . . . . . . . . . 66
9.10. LOCK Method . . . . . . . . . . . . . . . . . . . . . . 66 9.10. LOCK Method . . . . . . . . . . . . . . . . . . . . . . 67
9.10.1. Creating a lock on existing resource . . . . . . . . 66 9.10.1. Creating a Lock on an Existing Resource . . . . . . 67
9.10.2. Refreshing Locks . . . . . . . . . . . . . . . . . . 66 9.10.2. Refreshing Locks . . . . . . . . . . . . . . . . . . 67
9.10.3. Depth and Locking . . . . . . . . . . . . . . . . . 67 9.10.3. Depth and Locking . . . . . . . . . . . . . . . . . 68
9.10.4. Locking Unmapped URLs . . . . . . . . . . . . . . . 67 9.10.4. Locking Unmapped URLs . . . . . . . . . . . . . . . 68
9.10.5. Lock Compatibility Table . . . . . . . . . . . . . . 68 9.10.5. Lock Compatibility Table . . . . . . . . . . . . . . 69
9.10.6. LOCK Responses . . . . . . . . . . . . . . . . . . . 68 9.10.6. LOCK Responses . . . . . . . . . . . . . . . . . . . 69
9.10.7. Example - Simple Lock Request . . . . . . . . . . . 69 9.10.7. Example - Simple Lock Request . . . . . . . . . . . 70
9.10.8. Example - Refreshing a Write Lock . . . . . . . . . 71 9.10.8. Example - Refreshing a Write Lock . . . . . . . . . 72
9.10.9. Example - Multi-Resource Lock Request . . . . . . . 72 9.10.9. Example - Multi-Resource Lock Request . . . . . . . 73
9.11. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . 73 9.11. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . 74
9.11.1. Status Codes . . . . . . . . . . . . . . . . . . . . 73 9.11.1. Status Codes . . . . . . . . . . . . . . . . . . . . 74
9.11.2. Example - UNLOCK . . . . . . . . . . . . . . . . . . 74 9.11.2. Example - UNLOCK . . . . . . . . . . . . . . . . . . 75
10. HTTP Headers for Distributed Authoring . . . . . . . . . . . 75 10. HTTP Headers for Distributed Authoring . . . . . . . . . . . 76
10.1. DAV Header . . . . . . . . . . . . . . . . . . . . . . . 75 10.1. DAV Header . . . . . . . . . . . . . . . . . . . . . . . 76
10.2. Depth Header . . . . . . . . . . . . . . . . . . . . . . 76 10.2. Depth Header . . . . . . . . . . . . . . . . . . . . . . 77
10.3. Destination Header . . . . . . . . . . . . . . . . . . . 77 10.3. Destination Header . . . . . . . . . . . . . . . . . . . 78
10.4. If Header . . . . . . . . . . . . . . . . . . . . . . . 77 10.4. If Header . . . . . . . . . . . . . . . . . . . . . . . 78
10.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 77 10.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 78
10.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 78 10.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 79
10.4.3. List Evaluation . . . . . . . . . . . . . . . . . . 79 10.4.3. List Evaluation . . . . . . . . . . . . . . . . . . 80
10.4.4. Matching State Tokens and ETags . . . . . . . . . . 79 10.4.4. Matching State Tokens and ETags . . . . . . . . . . 80
10.4.5. If Header and Non-DAV Aware Proxies . . . . . . . . 80 10.4.5. If Header and Non-DAV Aware Proxies . . . . . . . . 81
10.4.6. Example - No-tag Production . . . . . . . . . . . . 80 10.4.6. Example - No-tag Production . . . . . . . . . . . . 81
10.4.7. Example - using "Not" with No-tag Production . . . . 80 10.4.7. Example - using "Not" with No-tag Production . . . . 81
10.4.8. Example - causing a Condition to always evaluate 10.4.8. Example - causing a Condition to always evaluate
to True . . . . . . . . . . . . . . . . . . . . . . 81 to True . . . . . . . . . . . . . . . . . . . . . . 82
10.4.9. Example - Tagged List If header in COPY . . . . . . 81 10.4.9. Example - Tagged List If header in COPY . . . . . . 82
10.4.10. Example - Matching lock tokens with collection 10.4.10. Example - Matching lock tokens with collection
locks . . . . . . . . . . . . . . . . . . . . . . . 81 locks . . . . . . . . . . . . . . . . . . . . . . . 82
10.4.11. Example - Matching ETags on unmapped URLs . . . . . 82 10.4.11. Example - Matching ETags on unmapped URLs . . . . . 83
10.5. Lock-Token Header . . . . . . . . . . . . . . . . . . . 82 10.5. Lock-Token Header . . . . . . . . . . . . . . . . . . . 83
10.6. Overwrite Header . . . . . . . . . . . . . . . . . . . . 82 10.6. Overwrite Header . . . . . . . . . . . . . . . . . . . . 83
10.7. Timeout Request Header . . . . . . . . . . . . . . . . . 83 10.7. Timeout Request Header . . . . . . . . . . . . . . . . . 84
11. Status Code Extensions to HTTP/1.1 . . . . . . . . . . . . . 84 11. Status Code Extensions to HTTP/1.1 . . . . . . . . . . . . . 85
11.1. 207 Multi-Status . . . . . . . . . . . . . . . . . . . . 84 11.1. 207 Multi-Status . . . . . . . . . . . . . . . . . . . . 85
11.2. 422 Unprocessable Entity . . . . . . . . . . . . . . . . 84 11.2. 422 Unprocessable Entity . . . . . . . . . . . . . . . . 85
11.3. 423 Locked . . . . . . . . . . . . . . . . . . . . . . . 84 11.3. 423 Locked . . . . . . . . . . . . . . . . . . . . . . . 85
11.4. 424 Failed Dependency . . . . . . . . . . . . . . . . . 84 11.4. 424 Failed Dependency . . . . . . . . . . . . . . . . . 85
11.5. 507 Insufficient Storage . . . . . . . . . . . . . . . . 84 11.5. 507 Insufficient Storage . . . . . . . . . . . . . . . . 85
12. Use of HTTP Status Codes . . . . . . . . . . . . . . . . . . 85 12. Use of HTTP Status Codes . . . . . . . . . . . . . . . . . . 86
12.1. 412 Precondition Failed . . . . . . . . . . . . . . . . 85 12.1. 412 Precondition Failed . . . . . . . . . . . . . . . . 86
12.2. 414 Request-URI Too Long . . . . . . . . . . . . . . . . 85 12.2. 414 Request-URI Too Long . . . . . . . . . . . . . . . . 86
13. Multi-Status Response . . . . . . . . . . . . . . . . . . . . 86 13. Multi-Status Response . . . . . . . . . . . . . . . . . . . . 87
13.1. Response headers . . . . . . . . . . . . . . . . . . . . 86 13.1. Response Headers . . . . . . . . . . . . . . . . . . . . 87
13.2. Handling redirected child resources . . . . . . . . . . 87 13.2. Handling Redirected Child Resources . . . . . . . . . . 88
13.3. Internal Status Codes . . . . . . . . . . . . . . . . . 87 13.3. Internal Status Codes . . . . . . . . . . . . . . . . . 88
14. XML Element Definitions . . . . . . . . . . . . . . . . . . . 88 14. XML Element Definitions . . . . . . . . . . . . . . . . . . . 89
14.1. activelock XML Element . . . . . . . . . . . . . . . . . 88 14.1. activelock XML Element . . . . . . . . . . . . . . . . . 89
14.2. allprop XML Element . . . . . . . . . . . . . . . . . . 88 14.2. allprop XML Element . . . . . . . . . . . . . . . . . . 89
14.3. collection XML Element . . . . . . . . . . . . . . . . . 88 14.3. collection XML Element . . . . . . . . . . . . . . . . . 89
14.4. depth XML Element . . . . . . . . . . . . . . . . . . . 88 14.4. depth XML Element . . . . . . . . . . . . . . . . . . . 89
14.5. error XML Element . . . . . . . . . . . . . . . . . . . 89 14.5. error XML Element . . . . . . . . . . . . . . . . . . . 90
14.6. exclusive XML Element . . . . . . . . . . . . . . . . . 89 14.6. exclusive XML Element . . . . . . . . . . . . . . . . . 90
14.7. href XML Element . . . . . . . . . . . . . . . . . . . . 89 14.7. href XML Element . . . . . . . . . . . . . . . . . . . . 90
14.8. include XML Element . . . . . . . . . . . . . . . . . . 90 14.8. include XML Element . . . . . . . . . . . . . . . . . . 91
14.9. location XML Element . . . . . . . . . . . . . . . . . . 90 14.9. location XML Element . . . . . . . . . . . . . . . . . . 91
14.10. lockentry XML Element . . . . . . . . . . . . . . . . . 90 14.10. lockentry XML Element . . . . . . . . . . . . . . . . . 91
14.11. lockinfo XML Element . . . . . . . . . . . . . . . . . . 90 14.11. lockinfo XML Element . . . . . . . . . . . . . . . . . . 91
14.12. lockroot XML Element . . . . . . . . . . . . . . . . . . 91 14.12. lockroot XML Element . . . . . . . . . . . . . . . . . . 92
14.13. lockscope XML Element . . . . . . . . . . . . . . . . . 91 14.13. lockscope XML Element . . . . . . . . . . . . . . . . . 92
14.14. locktoken XML Element . . . . . . . . . . . . . . . . . 91 14.14. locktoken XML Element . . . . . . . . . . . . . . . . . 92
14.15. locktype XML Element . . . . . . . . . . . . . . . . . . 91 14.15. locktype XML Element . . . . . . . . . . . . . . . . . . 92
14.16. multistatus XML Element . . . . . . . . . . . . . . . . 92 14.16. multistatus XML Element . . . . . . . . . . . . . . . . 93
14.17. owner XML Element . . . . . . . . . . . . . . . . . . . 92 14.17. owner XML Element . . . . . . . . . . . . . . . . . . . 93
14.18. prop XML element . . . . . . . . . . . . . . . . . . . . 92 14.18. prop XML Element . . . . . . . . . . . . . . . . . . . . 93
14.19. propertyupdate XML element . . . . . . . . . . . . . . . 93 14.19. propertyupdate XML Element . . . . . . . . . . . . . . . 94
14.20. propfind XML Element . . . . . . . . . . . . . . . . . . 93 14.20. propfind XML Element . . . . . . . . . . . . . . . . . . 94
14.21. propname XML Element . . . . . . . . . . . . . . . . . . 93 14.21. propname XML Element . . . . . . . . . . . . . . . . . . 94
14.22. propstat XML Element . . . . . . . . . . . . . . . . . . 93 14.22. propstat XML Element . . . . . . . . . . . . . . . . . . 94
14.23. remove XML element . . . . . . . . . . . . . . . . . . . 94 14.23. remove XML Element . . . . . . . . . . . . . . . . . . . 95
14.24. response XML Element . . . . . . . . . . . . . . . . . . 94 14.24. response XML Element . . . . . . . . . . . . . . . . . . 95
14.25. responsedescription XML Element . . . . . . . . . . . . 95 14.25. responsedescription XML Element . . . . . . . . . . . . 96
14.26. set XML element . . . . . . . . . . . . . . . . . . . . 95 14.26. set XML Element . . . . . . . . . . . . . . . . . . . . 96
14.27. shared XML Element . . . . . . . . . . . . . . . . . . . 95 14.27. shared XML Element . . . . . . . . . . . . . . . . . . . 96
14.28. status XML Element . . . . . . . . . . . . . . . . . . . 95 14.28. status XML Element . . . . . . . . . . . . . . . . . . . 96
14.29. timeout XML Element . . . . . . . . . . . . . . . . . . 96 14.29. timeout XML Element . . . . . . . . . . . . . . . . . . 97
14.30. write XML Element . . . . . . . . . . . . . . . . . . . 96 14.30. write XML Element . . . . . . . . . . . . . . . . . . . 97
15. DAV Properties . . . . . . . . . . . . . . . . . . . . . . . 97 15. DAV Properties . . . . . . . . . . . . . . . . . . . . . . . 98
15.1. creationdate Property . . . . . . . . . . . . . . . . . 97 15.1. creationdate Property . . . . . . . . . . . . . . . . . 98
15.2. displayname Property . . . . . . . . . . . . . . . . . . 98 15.2. displayname Property . . . . . . . . . . . . . . . . . . 99
15.3. getcontentlanguage Property . . . . . . . . . . . . . . 98 15.3. getcontentlanguage Property . . . . . . . . . . . . . . 99
15.4. getcontentlength Property . . . . . . . . . . . . . . . 99 15.4. getcontentlength Property . . . . . . . . . . . . . . . 100
15.5. getcontenttype Property . . . . . . . . . . . . . . . . 99 15.5. getcontenttype Property . . . . . . . . . . . . . . . . 100
15.6. getetag Property . . . . . . . . . . . . . . . . . . . . 100 15.6. getetag Property . . . . . . . . . . . . . . . . . . . . 101
15.7. getlastmodified Property . . . . . . . . . . . . . . . . 100 15.7. getlastmodified Property . . . . . . . . . . . . . . . . 101
15.8. lockdiscovery Property . . . . . . . . . . . . . . . . . 101 15.8. lockdiscovery Property . . . . . . . . . . . . . . . . . 102
15.8.1. Example - Retrieving DAV:lockdiscovery . . . . . . . 102 15.8.1. Example - Retrieving DAV:lockdiscovery . . . . . . . 103
15.9. resourcetype Property . . . . . . . . . . . . . . . . . 103 15.9. resourcetype Property . . . . . . . . . . . . . . . . . 104
15.10. supportedlock Property . . . . . . . . . . . . . . . . . 104 15.10. supportedlock Property . . . . . . . . . . . . . . . . . 105
15.10.1. Example - Retrieving DAV:supportedlock . . . . . . . 105 15.10.1. Example - Retrieving DAV:supportedlock . . . . . . . 106
16. Precondition/postcondition XML elements . . . . . . . . . . . 106 16. Precondition/Postcondition XML Elements . . . . . . . . . . . 107
17. XML Extensibility in DAV . . . . . . . . . . . . . . . . . . 110 17. XML Extensibility in DAV . . . . . . . . . . . . . . . . . . 111
18. DAV Compliance Classes . . . . . . . . . . . . . . . . . . . 112 18. DAV Compliance Classes . . . . . . . . . . . . . . . . . . . 113
18.1. Class 1 . . . . . . . . . . . . . . . . . . . . . . . . 112 18.1. Class 1 . . . . . . . . . . . . . . . . . . . . . . . . 113
18.2. Class 2 . . . . . . . . . . . . . . . . . . . . . . . . 112 18.2. Class 2 . . . . . . . . . . . . . . . . . . . . . . . . 113
18.3. Class 3 . . . . . . . . . . . . . . . . . . . . . . . . 112 18.3. Class 3 . . . . . . . . . . . . . . . . . . . . . . . . 113
19. Internationalization Considerations . . . . . . . . . . . . . 114 19. Internationalization Considerations . . . . . . . . . . . . . 115
20. Security Considerations . . . . . . . . . . . . . . . . . . . 116 20. Security Considerations . . . . . . . . . . . . . . . . . . . 117
20.1. Authentication of Clients . . . . . . . . . . . . . . . 116 20.1. Authentication of Clients . . . . . . . . . . . . . . . 117
20.2. Denial of Service . . . . . . . . . . . . . . . . . . . 116 20.2. Denial of Service . . . . . . . . . . . . . . . . . . . 117
20.3. Security through Obscurity . . . . . . . . . . . . . . . 117 20.3. Security through Obscurity . . . . . . . . . . . . . . . 118
20.4. Privacy Issues Connected to Locks . . . . . . . . . . . 117 20.4. Privacy Issues Connected to Locks . . . . . . . . . . . 118
20.5. Privacy Issues Connected to Properties . . . . . . . . . 117 20.5. Privacy Issues Connected to Properties . . . . . . . . . 118
20.6. Implications of XML Entities . . . . . . . . . . . . . . 118 20.6. Implications of XML Entities . . . . . . . . . . . . . . 119
20.7. Risks Connected with Lock Tokens . . . . . . . . . . . . 118 20.7. Risks Connected with Lock Tokens . . . . . . . . . . . . 119
20.8. Hosting Malicious Content . . . . . . . . . . . . . . . 119 20.8. Hosting Malicious Content . . . . . . . . . . . . . . . 120
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 121
21.1. New URI Schemes . . . . . . . . . . . . . . . . . . . . 120 21.1. New URI Schemes . . . . . . . . . . . . . . . . . . . . 121
21.2. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 120 21.2. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 121
21.3. Message Header Fields . . . . . . . . . . . . . . . . . 120 21.3. Message Header Fields . . . . . . . . . . . . . . . . . 121
21.3.1. DAV . . . . . . . . . . . . . . . . . . . . . . . . 120 21.3.1. DAV . . . . . . . . . . . . . . . . . . . . . . . . 121
21.3.2. Depth . . . . . . . . . . . . . . . . . . . . . . . 120 21.3.2. Depth . . . . . . . . . . . . . . . . . . . . . . . 121
21.3.3. Destination . . . . . . . . . . . . . . . . . . . . 121 21.3.3. Destination . . . . . . . . . . . . . . . . . . . . 122
21.3.4. If . . . . . . . . . . . . . . . . . . . . . . . . . 121 21.3.4. If . . . . . . . . . . . . . . . . . . . . . . . . . 122
21.3.5. Lock-Token . . . . . . . . . . . . . . . . . . . . . 121 21.3.5. Lock-Token . . . . . . . . . . . . . . . . . . . . . 122
21.3.6. Overwrite . . . . . . . . . . . . . . . . . . . . . 121 21.3.6. Overwrite . . . . . . . . . . . . . . . . . . . . . 122
21.3.7. Timeout . . . . . . . . . . . . . . . . . . . . . . 122 21.3.7. Timeout . . . . . . . . . . . . . . . . . . . . . . 123
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 123 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 124
23. Contributors to This Specification . . . . . . . . . . . . . 125 23. Contributors to This Specification . . . . . . . . . . . . . 126
24. Authors of RFC2518 . . . . . . . . . . . . . . . . . . . . . 126 24. Authors of RFC2518 . . . . . . . . . . . . . . . . . . . . . 127
25. References . . . . . . . . . . . . . . . . . . . . . . . . . 127 25. References . . . . . . . . . . . . . . . . . . . . . . . . . 128
25.1. Normative References . . . . . . . . . . . . . . . . . . 127 25.1. Normative References . . . . . . . . . . . . . . . . . . 128
25.2. Informational References . . . . . . . . . . . . . . . . 128 25.2. Informational References . . . . . . . . . . . . . . . . 129
Appendix A. Notes on Processing XML Elements . . . . . . . . . . 129 Appendix A. Notes on Processing XML Elements . . . . . . . . . . 130
A.1. Notes on Empty XML Elements . . . . . . . . . . . . . . 129 A.1. Notes on Empty XML Elements . . . . . . . . . . . . . . 130
A.2. Notes on Illegal XML Processing . . . . . . . . . . . . 129 A.2. Notes on Illegal XML Processing . . . . . . . . . . . . 130
A.3. Example - XML Syntax Error . . . . . . . . . . . . . . . 129 A.3. Example - XML Syntax Error . . . . . . . . . . . . . . . 130
A.4. Example - Unexpected XML Element . . . . . . . . . . . . 130 A.4. Example - Unexpected XML Element . . . . . . . . . . . . 131
Appendix B. Notes on HTTP Client Compatibility . . . . . . . . . 131 Appendix B. Notes on HTTP Client Compatibility . . . . . . . . . 132
Appendix C. The opaquelocktoken scheme and URIs . . . . . . . . 132 Appendix C. The 'opaquelocktoken' Scheme and URIs . . . . . . . 133
Appendix D. Lock-null Resources . . . . . . . . . . . . . . . . 133 Appendix D. Lock-null Resources . . . . . . . . . . . . . . . . 134
Appendix E. Guidance for Clients Desiring to Authenticate . . . 134 D.1. Guidance for Clients Using LOCK to Create Resources . . 134
Appendix F. Summary of changes from RFC2518 . . . . . . . . . . 136 Appendix E. Guidance for Clients Desiring to Authenticate . . . 136
F.1. Changes for both Client and Server Implementations . . . 136 Appendix F. Summary of changes from RFC2518 . . . . . . . . . . 138
F.2. Changes for Server Implementations . . . . . . . . . . . 137 F.1. Changes for both Client and Server Implementations . . . 138
F.3. Other Changes . . . . . . . . . . . . . . . . . . . . . 138 F.2. Changes for Server Implementations . . . . . . . . . . . 139
F.3. Other Changes . . . . . . . . . . . . . . . . . . . . . 140
Appendix G. Change Log (to be removed by RFC Editor before Appendix G. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 139 publication) . . . . . . . . . . . . . . . . . . . . 142
G.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . 139 G.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . 142
G.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 139 G.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 142
G.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 140 G.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 143
G.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 141 G.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 144
G.5. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 142 G.5. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 145
G.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 142 G.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 145
G.7. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 142 G.7. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 145
G.8. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 143 G.8. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 146
G.9. Changes in -14 . . . . . . . . . . . . . . . . . . . . . 143 G.9. Changes in -14 . . . . . . . . . . . . . . . . . . . . . 146
G.10. Changes in -15 . . . . . . . . . . . . . . . . . . . . . 143 G.10. Changes in -15 . . . . . . . . . . . . . . . . . . . . . 146
G.11. Changes in -16 . . . . . . . . . . . . . . . . . . . . . 143 G.11. Changes in -16 . . . . . . . . . . . . . . . . . . . . . 146
G.12. Changes in -17 . . . . . . . . . . . . . . . . . . . . . 144 G.12. Changes in -17 . . . . . . . . . . . . . . . . . . . . . 147
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 145 G.13. Changes in -18 . . . . . . . . . . . . . . . . . . . . . 147
Intellectual Property and Copyright Statements . . . . . . . . . 146 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 148
Intellectual Property and Copyright Statements . . . . . . . . . 149
1. Introduction 1. Introduction
This document describes an extension to the HTTP/1.1 protocol that This document describes an extension to the HTTP/1.1 protocol that
allows clients to perform remote web content authoring operations. allows clients to perform remote web content authoring operations.
This extension provides a coherent set of methods, headers, request This extension provides a coherent set of methods, headers, request
entity body formats, and response entity body formats that provide entity body formats, and response entity body formats that provide
operations for: operations for:
Properties: The ability to create, remove, and query information Properties: The ability to create, remove, and query information
skipping to change at page 8, line 43 skipping to change at page 8, line 43
This document does not specify the versioning operations suggested by This document does not specify the versioning operations suggested by
[RFC2291]. That work was done in a separate document, "Versioning [RFC2291]. That work was done in a separate document, "Versioning
Extensions to WebDAV" [RFC3253]. Extensions to WebDAV" [RFC3253].
The sections below provide a detailed introduction to various WebDAV The sections below provide a detailed introduction to various WebDAV
abstractions: resource properties (Section 4), collections of abstractions: resource properties (Section 4), collections of
resources (Section 5), locks (Section 6) in general and write locks resources (Section 5), locks (Section 6) in general and write locks
(Section 7) specifically. (Section 7) specifically.
These abstractions are manipulated by the WebDAV-specific HTTP These abstractions are manipulated by the WebDAV-specific HTTP
methods (Section 9) and the new HTTP headers (Section 10) used with methods (Section 9) and the extra HTTP headers (Section 10) used with
WebDAV methods. General considerations for handling HTTP requests WebDAV methods. General considerations for handling HTTP requests
and responses in WebDAV are found in Section 8. and responses in WebDAV are found in Section 8.
While the status codes provided by HTTP/1.1 are sufficient to While the status codes provided by HTTP/1.1 are sufficient to
describe most error conditions encountered by WebDAV methods, there describe most error conditions encountered by WebDAV methods, there
are some errors that do not fall neatly into the existing categories. are some errors that do not fall neatly into the existing categories.
This specification defines new status codes developed for WebDAV This specification defines extra status codes developed for WebDAV
methods (Section 11) and describes existing HTTP status codes methods (Section 11) and describes existing HTTP status codes
(Section 12) as used in WebDAV. Since some WebDAV methods may (Section 12) as used in WebDAV. Since some WebDAV methods may
operate over many resources, the Multi-Status response (Section 13) operate over many resources, the Multi-Status response (Section 13)
has been introduced to return status information for multiple has been introduced to return status information for multiple
resources. Finally, this version of WebDAV introduces precondition resources. Finally, this version of WebDAV introduces precondition
and postcondition (Section 16) XML elements in error response bodies. and postcondition (Section 16) XML elements in error response bodies.
WebDAV uses XML ([REC-XML]) for property names and some values, and WebDAV uses XML ([REC-XML]) for property names and some values, and
also uses XML to marshal complicated request and response. This also uses XML to marshal complicated requests and responses. This
specification contains DTD and text definitions of all all properties specification contains DTD and text definitions of all all properties
(Section 15) and all other XML elements (Section 14) used in (Section 15) and all other XML elements (Section 14) used in
marshalling. WebDAV includes a few special rules on extending marshalling. WebDAV includes a few special rules on extending
(Section 17) WebDAV XML marshalling in backwards-compatible ways. WebDAV XML marshalling in backwards-compatible ways (Section 17).
Finishing off the specification are sections on what it means for a Finishing off the specification are sections on what it means for a
resource to be compliant with this specification (Section 18), on resource to be compliant with this specification (Section 18), on
internationalization support (Section 19), and on security internationalization support (Section 19), and on security
(Section 20). (Section 20).
2. Notational Conventions 2. Notational Conventions
Since this document describes a set of extensions to the HTTP/1.1 Since this document describes a set of extensions to the HTTP/1.1
protocol, the augmented BNF used herein to describe protocol elements protocol, the augmented BNF used herein to describe protocol elements
skipping to change at page 13, line 50 skipping to change at page 13, line 50
to set or retrieve just those properties. to set or retrieve just those properties.
4.3. Property Values 4.3. Property Values
The value of a property is always a (well-formed) XML fragment. The value of a property is always a (well-formed) XML fragment.
XML has been chosen because it is a flexible, self-describing, XML has been chosen because it is a flexible, self-describing,
structured data format that supports rich schema definitions, and structured data format that supports rich schema definitions, and
because of its support for multiple character sets. XML's self- because of its support for multiple character sets. XML's self-
describing nature allows any property's value to be extended by describing nature allows any property's value to be extended by
adding new elements. Older clients will not break when they adding elements. Clients will not break when they encounter
encounter extensions because they will still have the data specified extensions because they will still have the data specified in the
in the original schema and MUST ignore elements they do not original schema and MUST ignore elements they do not understand.
understand.
XML's support for multiple character sets allows any human-readable XML's support for multiple character sets allows any human-readable
property to be encoded and read in a character set familiar to the property to be encoded and read in a character set familiar to the
user. XML's support for multiple human languages, using the "xml: user. XML's support for multiple human languages, using the "xml:
lang" attribute, handles cases where the same character set is lang" attribute, handles cases where the same character set is
employed by multiple human languages. Note that xml:lang scope is employed by multiple human languages. Note that xml:lang scope is
recursive, so an xml:lang attribute on any element containing a recursive, so an xml:lang attribute on any element containing a
property name element applies to the property value unless it has property name element applies to the property value unless it has
been overridden by a more locally scoped attribute. Note that a been overridden by a more locally scoped attribute. Note that a
property only has one value, in one language (or language MAY be left property only has one value, in one language (or language MAY be left
skipping to change at page 18, line 7 skipping to change at page 18, line 7
to one or many to many. There is no mechanism in HTTP to determine to one or many to many. There is no mechanism in HTTP to determine
whether a resource is even dynamic, let alone where its source files whether a resource is even dynamic, let alone where its source files
exist or how to author them. Although this problem would usefully be exist or how to author them. Although this problem would usefully be
solved, interoperable WebDAV implementations have been widely solved, interoperable WebDAV implementations have been widely
deployed without actually solving this problem, by dealing only with deployed without actually solving this problem, by dealing only with
static resources. Thus, the source vs. output problem is not solved static resources. Thus, the source vs. output problem is not solved
in this specification and has been deferred to a separate document. in this specification and has been deferred to a separate document.
5. Collections of Web Resources 5. Collections of Web Resources
This section provides a description of a new type of Web resource, This section provides a description of a type of Web resource, the
the collection, and discusses its interactions with the HTTP URL collection, and discusses its interactions with the HTTP URL
namespace. The purpose of a collection resource is to model namespace and with HTTP methods. The purpose of a collection
collection-like objects (e.g., file system directories) within a resource is to model collection-like objects (e.g., file system
server's namespace. directories) within a server's namespace.
All DAV compliant resources MUST support the HTTP URL namespace model All DAV compliant resources MUST support the HTTP URL namespace model
specified herein. specified herein.
5.1. HTTP URL Namespace Model 5.1. HTTP URL Namespace Model
The HTTP URL namespace is a hierarchical namespace where the The HTTP URL namespace is a hierarchical namespace where the
hierarchy is delimited with the "/" character. hierarchy is delimited with the "/" character.
An HTTP URL namespace is said to be consistent if it meets the An HTTP URL namespace is said to be consistent if it meets the
skipping to change at page 18, line 42 skipping to change at page 18, line 42
a parent collection. However, certain WebDAV methods are prohibited a parent collection. However, certain WebDAV methods are prohibited
from producing results that cause namespace inconsistencies. from producing results that cause namespace inconsistencies.
As is implicit in [RFC2616] and [RFC3986], any resource, including As is implicit in [RFC2616] and [RFC3986], any resource, including
collection resources, MAY be identified by more than one URI. For collection resources, MAY be identified by more than one URI. For
example, a resource could be identified by multiple HTTP URLs. example, a resource could be identified by multiple HTTP URLs.
5.2. Collection Resources 5.2. Collection Resources
Collection resources differ from other resources in that they also Collection resources differ from other resources in that they also
act as containers. A collection is a resource whose state consists act as containers. Some HTTP methods apply only to a collection, but
of at least a set of mappings between path segments and resources, some apply to some or all of the resources inside the container
and a set of properties on the collection itself. In this document, defined by the collection. When the scope of a method is not clear,
a resource B will be said to be contained in the collection resource the client can specify what depth to apply. Depth can be either zero
A if there is a path segment mapping which maps to B and which is levels in (only the collection), one level (the collection and
contained in A. A collection MUST contain at most one mapping for a directly contained resources) or infinite levels (the collection and
given path segment, i.e., it is illegal to have the same path segment all contained resources recursively).
mapped to more than one resource.
A collection's state consists of at least a set of mappings between
path segments and resources, and a set of properties on the
collection itself. In this document, a resource B will be said to be
contained in the collection resource A if there is a path segment
mapping which maps to B and which is contained in A. A collection
MUST contain at most one mapping for a given path segment, i.e., it
is illegal to have the same path segment mapped to more than one
resource.
Properties defined on collections behave exactly as do properties on Properties defined on collections behave exactly as do properties on
non-collection resources. A collection MAY have additional state non-collection resources. A collection MAY have additional state
such as entity bodies returned by GET. such as entity bodies returned by GET.
For all WebDAV compliant resources A and B, identified by URLs "U" For all WebDAV compliant resources A and B, identified by URLs "U"
and "V" respectively, such that "V" is equal to "U/SEGMENT", A MUST and "V" respectively, such that "V" is equal to "U/SEGMENT", A MUST
be a collection that contains a mapping from "SEGMENT" to B. So, if be a collection that contains a mapping from "SEGMENT" to B. So, if
resource B with URL "http://example.com/bar/blah" is WebDAV compliant resource B with URL "http://example.com/bar/blah" is WebDAV compliant
and if resource A with URL "http://example.com/bar/" is WebDAV and if resource A with URL "http://example.com/bar/" is WebDAV
skipping to change at page 21, line 42 skipping to change at page 21, line 42
of that resource creates a new lock. The "lock-root" of the new of that resource creates a new lock. The "lock-root" of the new
lock is that URL. If at the time of the request, the URL is not lock is that URL. If at the time of the request, the URL is not
mapped to a resource, a new empty resource is created and mapped to a resource, a new empty resource is created and
directly locked. directly locked.
3. An exclusive lock (Section 6.2) conflicts with any other kind of 3. An exclusive lock (Section 6.2) conflicts with any other kind of
lock on the same resource, whether either lock is direct or lock on the same resource, whether either lock is direct or
indirect. A server MUST NOT create conflicting locks on a indirect. A server MUST NOT create conflicting locks on a
resource. resource.
4. For a collection that is locked with an infinite depth lock L, 4. For a collection that is locked with a depth-infinity lock L, all
all member resources are indirectly locked. Changes in member resources are indirectly locked. Changes in membership of
membership of a such a collection affect the set of indirectly a such a collection affect the set of indirectly locked
locked resources: resources:
* If a member resource is added to the collection, the new * If a member resource is added to the collection, the new
member resource MUST NOT already have a conflicting lock, member resource MUST NOT already have a conflicting lock,
because the new resource MUST become indirectly locked by L. because the new resource MUST become indirectly locked by L.
* If a member resource stops being a member of the collection, * If a member resource stops being a member of the collection,
then the resource MUST no longer be indirectly locked by L. then the resource MUST no longer be indirectly locked by L.
5. Each lock is identified by a single unique lock token 5. Each lock is identified by a single globally unique lock token
(Section 6.5). (Section 6.5).
6. An UNLOCK request deletes the lock with the specified lock token. 6. An UNLOCK request deletes the lock with the specified lock token.
After a lock is deleted, no resource is locked by that lock. After a lock is deleted, no resource is locked by that lock.
7. A lock token is "submitted" in a request when it appears in an If 7. A lock token is "submitted" in a request when it appears in an
header (the Write Lock (Section 7) section discusses when token "If" header (the Write Lock (Section 7) section discusses when
submission is required for write locks). token submission is required for write locks).
8. If a request causes the lock-root of any lock to become an 8. If a request causes the lock-root of any lock to become an
unmapped URL, then the lock MUST also be deleted by that request. unmapped URL, then the lock MUST also be deleted by that request.
6.2. Exclusive Vs. Shared Locks 6.2. Exclusive Vs. Shared Locks
The most basic form of lock is an exclusive lock. Exclusive locks The most basic form of lock is an exclusive lock. Exclusive locks
avoid having to deal with content change conflicts, without requiring avoid having to deal with content change conflicts, without requiring
any coordination other than the methods described in this any coordination other than the methods described in this
specification. specification.
skipping to change at page 23, line 7 skipping to change at page 23, line 7
decide they trust their collaborators will not overwrite their work decide they trust their collaborators will not overwrite their work
(the potential set of collaborators being the set of principals who (the potential set of collaborators being the set of principals who
have write permission) and use a shared lock, which informs their have write permission) and use a shared lock, which informs their
collaborators that a principal may be working on the resource. collaborators that a principal may be working on the resource.
The WebDAV extensions to HTTP do not need to provide all of the The WebDAV extensions to HTTP do not need to provide all of the
communications paths necessary for principals to coordinate their communications paths necessary for principals to coordinate their
activities. When using shared locks, principals may use any out of activities. When using shared locks, principals may use any out of
band communication channel to coordinate their work (e.g., face-to- band communication channel to coordinate their work (e.g., face-to-
face interaction, written notes, post-it notes on the screen, face interaction, written notes, post-it notes on the screen,
telephone conversation, Email, etc.) The intent of a shared lock is telephone conversation, email, etc.) The intent of a shared lock is
to let collaborators know who else may be working on a resource. to let collaborators know who else may be working on a resource.
Shared locks are included because experience from web distributed Shared locks are included because experience from web distributed
authoring systems has indicated that exclusive locks are often too authoring systems has indicated that exclusive locks are often too
rigid. An exclusive lock is used to enforce a particular editing rigid. An exclusive lock is used to enforce a particular editing
process: take out an exclusive lock, read the resource, perform process: take out an exclusive lock, read the resource, perform
edits, write the resource, release the lock. This editing process edits, write the resource, release the lock. This editing process
has the problem that locks are not always properly released, for has the problem that locks are not always properly released, for
example when a program crashes, or when a lock creator leaves without example when a program crashes, or when a lock creator leaves without
unlocking a resource. While both timeouts (Section 6.6) and unlocking a resource. While both timeouts (Section 6.6) and
skipping to change at page 25, line 19 skipping to change at page 25, line 19
ultimately chooses the timeout value. Timeout is measured in seconds ultimately chooses the timeout value. Timeout is measured in seconds
remaining until lock expiration. remaining until lock expiration.
The timeout counter MUST be restarted if a refresh lock request is The timeout counter MUST be restarted if a refresh lock request is
successful (see Section 9.10.2). The timeout counter SHOULD NOT be successful (see Section 9.10.2). The timeout counter SHOULD NOT be
restarted at any other time. restarted at any other time.
If the timeout expires then the lock SHOULD be removed. In this case If the timeout expires then the lock SHOULD be removed. In this case
the server SHOULD act as if an UNLOCK method was executed by the the server SHOULD act as if an UNLOCK method was executed by the
server on the resource using the lock token of the timed-out lock, server on the resource using the lock token of the timed-out lock,
performed with its override authority. Thus logs should be updated performed with its override authority.
with the disposition of the lock, notifications should be sent, etc.,
just as they would be for an UNLOCK request.
Servers are advised to pay close attention to the values submitted by Servers are advised to pay close attention to the values submitted by
clients, as they will be indicative of the type of activity the clients, as they will be indicative of the type of activity the
client intends to perform. For example, an applet running in a client intends to perform. For example, an applet running in a
browser may need to lock a resource, but because of the instability browser may need to lock a resource, but because of the instability
of the environment within which the applet is running, the applet may of the environment within which the applet is running, the applet may
be turned off without warning. As a result, the applet is likely to be turned off without warning. As a result, the applet is likely to
ask for a relatively small timeout value so that if the applet dies, ask for a relatively small timeout value so that if the applet dies,
the lock can be quickly harvested. However, a document management the lock can be quickly harvested. However, a document management
system is likely to ask for an extremely long timeout because its system is likely to ask for an extremely long timeout because its
skipping to change at page 30, line 27 skipping to change at page 30, line 27
Alternatively and for backwards compatibility to [RFC2518], servers Alternatively and for backwards compatibility to [RFC2518], servers
MAY implement Lock-Null Resources (LNRs) instead (see definition in MAY implement Lock-Null Resources (LNRs) instead (see definition in
Appendix D). Clients can easily interoperate both with servers that Appendix D). Clients can easily interoperate both with servers that
support the old model LNRs and the recommended model of "locked empty support the old model LNRs and the recommended model of "locked empty
resources" by only attempting PUT after a LOCK to an unmapped URL, resources" by only attempting PUT after a LOCK to an unmapped URL,
not MKCOL or GET, and by not relying on specific properties of LNRs. not MKCOL or GET, and by not relying on specific properties of LNRs.
7.4. Write Locks and Collections 7.4. Write Locks and Collections
There are two kinds of collection write locks. A "Depth 0" write There are two kinds of collection write locks. A depth-0 write lock
lock on a collection protects the collection properties plus the on a collection protects the collection properties plus the internal
internal member URLs of that one collection, while not protecting the member URLs of that one collection, while not protecting the content
content or properties of member resources (if the collection itself or properties of member resources (if the collection itself has any
has any entity bodies, those are also protected). A "Depth: entity bodies, those are also protected). A depth-infinity write
infinity" write lock on a collection provides the same protection on lock on a collection provides the same protection on that collection
that collection and also provides write lock protection on every and also provides write lock protection on every member resource.
member resource.
Expressed otherwise, a write lock protects any request that would Expressed otherwise, a write lock protects any request that would
create a new resource in a write locked collection, any request that create a new resource in a write locked collection, any request that
would remove an internal member URL of a write locked collection, and would remove an internal member URL of a write locked collection, and
any request that would change the segment name of any internal any request that would change the segment name of any internal
member. member.
Thus, a collection write lock protects all the following actions: Thus, a collection write lock protects all the following actions:
o DELETE a collection's direct internal member, o DELETE a collection's direct internal member,
skipping to change at page 32, line 40 skipping to change at page 32, line 40
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
In this example, even though both the source and destination are In this example, even though both the source and destination are
locked, only one lock token must be submitted, for the lock on the locked, only one lock token must be submitted, for the lock on the
destination. This is because the source resource is not modified by destination. This is because the source resource is not modified by
a COPY, and hence unaffected by the write lock. In this example, a COPY, and hence unaffected by the write lock. In this example,
user agent authentication has previously occurred via a mechanism user agent authentication has previously occurred via a mechanism
outside the scope of the HTTP protocol, in the underlying transport outside the scope of the HTTP protocol, in the underlying transport
layer. layer.
7.5.2. Example - Deleting a member of a locked collection 7.5.2. Example - Deleting a Member of a Locked Collection
Consider a collection "/locked" exclusively write-locked with Depth: Consider a collection "/locked" with an exclusive, depth-infinity
Infinity, and an attempt to delete an internal member "/locked/ write lock, and an attempt to delete an internal member "/locked/
member": member":
>>Request >>Request
DELETE /locked/member HTTP/1.1 DELETE /locked/member HTTP/1.1
Host: example.com Host: example.com
>>Response >>Response
HTTP/1.1 423 Locked HTTP/1.1 423 Locked
skipping to change at page 33, line 44 skipping to change at page 33, line 44
(<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>) (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
Note that for the purpose of submitting the lock token the actual Note that for the purpose of submitting the lock token the actual
form doesn't matter; what's relevant is that the lock token appears form doesn't matter; what's relevant is that the lock token appears
in the If header, and that the If header itself evaluates to true. in the If header, and that the If header itself evaluates to true.
7.6. Write Locks and COPY/MOVE 7.6. Write Locks and COPY/MOVE
A COPY method invocation MUST NOT duplicate any write locks active on A COPY method invocation MUST NOT duplicate any write locks active on
the source. However, as previously noted, if the COPY copies the the source. However, as previously noted, if the COPY copies the
resource into a collection that is locked with "Depth: infinity", resource into a collection that is locked with a depth-infinity lock,
then the resource will be added to the lock. then the resource will be added to the lock.
A successful MOVE request on a write locked resource MUST NOT move A successful MOVE request on a write locked resource MUST NOT move
the write lock with the resource. However, if there is an existing the write lock with the resource. However, if there is an existing
lock at the destination, the server MUST add the moved resource to lock at the destination, the server MUST add the moved resource to
the destination lock scope. For example, if the MOVE makes the the destination lock scope. For example, if the MOVE makes the
resource a child of a collection that is locked with "Depth: resource a child of a collection that has a depth-infinity lock, then
infinity", then the resource will be added to that collection's lock. the resource will be added to that collection's lock. Additionally,
if a resource with a depth-infinity lock is moved to a destination
Additionally, if a resource locked with "Depth: infinity" is moved to that is within the scope of the same lock (e.g., within the URL
a destination that is within the scope of the same lock (e.g., within namespace tree covered by the lock), the moved resource will again be
the URL namespace tree covered by the lock), the moved resource will a added to the lock. In both these examples, as specified in
again be a added to the lock. In both these examples, as specified Section 7.5, an If header must be submitted containing a lock token
in Section 7.5, an If header must be submitted containing a lock for both the source and destination.
token for both the source and destination.
7.7. Refreshing Write Locks 7.7. Refreshing Write Locks
A client MUST NOT submit the same write lock request twice. Note A client MUST NOT submit the same write lock request twice. Note
that a client is always aware it is resubmitting the same lock that a client is always aware it is resubmitting the same lock
request because it must include the lock token in the If header in request because it must include the lock token in the If header in
order to make the request for a resource that is already locked. order to make the request for a resource that is already locked.
However, a client may submit a LOCK request with an If header but However, a client may submit a LOCK request with an If header but
without a body. A server receiving a LOCK request with no body MUST without a body. A server receiving a LOCK request with no body MUST
skipping to change at page 38, line 7 skipping to change at page 38, line 7
When a client fails to renew the lock, it's quite possible the When a client fails to renew the lock, it's quite possible the
resource can still be relocked and the user can go on editing, as resource can still be relocked and the user can go on editing, as
long as no changes were made in the meantime. ETags are required for long as no changes were made in the meantime. ETags are required for
the client to be able to distinguish this case. Otherwise, the the client to be able to distinguish this case. Otherwise, the
client is forced to ask the user whether to overwrite the resource on client is forced to ask the user whether to overwrite the resource on
the server without even being able to tell the user whether it has the server without even being able to tell the user whether it has
changed. Timestamps do not solve this problem nearly as well as changed. Timestamps do not solve this problem nearly as well as
ETags. 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 (see Section 13.3.3 of [RFC2616]). Semantic equivalence can be
on the document type and the application type, and interoperability a useful concept but that depends on the document type and the
might require some agreement or standard outside the scope of this application type, and interoperability might require some agreement
specification and HTTP. Note also that weak ETags have certain or standard outside the scope of this specification and HTTP. Note
restrictions in HTTP, e.g. these cannot be used in If-Match headers. also that weak ETags have certain 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). This is in the formatting or content of the document upon storage). This is
an HTTP issue, not purely a WebDAV issue, and is being addressed in an HTTP issue, not purely a WebDAV issue.
[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
HTTP and WebDAV did not use the bodies of most error responses for HTTP and WebDAV did not use the bodies of most error responses for
machine-parsable information until DeltaV introduced a mechanism to machine-parsable information until the specification for Versioning
include more specific information in the body of an error response Extensions to WebDAV introduced a mechanism to include more specific
(Section 1.6 of [RFC3253]). The error body mechanism is appropriate information in the body of an error response (Section 1.6 of
to use with any error response that may take a body but does not [RFC3253]). The error body mechanism is appropriate to use with any
already have a body defined. The mechanism is particularly error response that may take a body but does not already have a body
appropriate when a status code can mean many things (for example, 400 defined. The mechanism is particularly appropriate when a status
Bad Request can mean required headers are missing, headers are code can mean many things (for example, 400 Bad Request can mean
incorrectly formatted, or much more). This error body mechanism is required headers are missing, headers are incorrectly formatted, or
covered in Section 16. much more). This error body mechanism is covered in Section 16.
8.8. Impact of Namespace Operations on Cache Validators 8.8. Impact of Namespace Operations on Cache Validators
Note that the HTTP response headers "Etag" and "Last-Modified" (see Note that the HTTP response headers "Etag" and "Last-Modified" (see
[RFC2616], Sections 14.19 and 14.29) are defined per URL (not per [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per
resource), and are used by clients for caching. Therefore servers resource), and are used by clients for caching. Therefore servers
must ensure that executing any operation that affects the URL must ensure that executing any operation that affects the URL
namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does preserve namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does preserve
their semantics, in particular: their semantics, in particular:
skipping to change at page 40, line 21 skipping to change at page 40, line 21
internal members, or on the resource identified by the Request-URI internal members, or on the resource identified by the Request-URI
and potentially its member resources, if the resource is a collection and potentially its member resources, if the resource is a collection
that has internal member URLs. All DAV compliant resources MUST that has internal member URLs. All DAV compliant resources MUST
support the PROPFIND method and the propfind XML element support the PROPFIND method and the propfind XML element
(Section 14.20) along with all XML elements defined for use with that (Section 14.20) along with all XML elements defined for use with that
element. element.
A client MUST submit a Depth header with a value of "0", "1", or A client MUST submit a Depth header with a value of "0", "1", or
"infinity" with a PROPFIND request. Servers MUST support "0" and "1" "infinity" with a PROPFIND request. Servers MUST support "0" and "1"
depth requests on WebDAV-compliant resources and SHOULD support depth requests on WebDAV-compliant resources and SHOULD support
"infinity" requests. In practice, support for depth infinity "infinity" requests. In practice, support for infinite depth
requests MAY be disabled, due to the performance and security requests MAY be disabled, due to the performance and security
concerns associated with this behavior. Since clients weren't concerns associated with this behavior. Since clients weren't
required to include the Depth header in [RFC2518], servers SHOULD required to include the Depth header in [RFC2518], servers SHOULD
treat such a request as if a "Depth: infinity" header was included. treat such a request as if a "Depth: infinity" header was included.
A client may submit a 'propfind' XML element in the body of the A client may submit a 'propfind' XML element in the body of the
request method describing what information is being requested. It is request method describing what information is being requested. It is
possible to: possible to:
o Request particular property values, by naming the properties o Request particular property values, by naming the properties
desired within the 'prop' element (the ordering of properties in desired within the 'prop' element (the ordering of properties in
here MAY be ignored by server), here MAY be ignored by server),
o Request property values for those properties defined in this o Request property values for those properties defined in this
specification plus dead properties, by using the 'allprop' element specification (at a minimum) plus dead properties, by using the
(the 'include' element can be used with 'allprop' to instruct the 'allprop' element (the 'include' element can be used with
server to also include additional live properties that may not 'allprop' to instruct the server to also include additional live
have been returned otherwise), properties that may not have been returned otherwise),
o Request a list of names of all the properties defined on the o Request a list of names of all the properties defined on the
resource, by using the 'propname' element. resource, by using the 'propname' element.
A client may choose not to submit a request body. An empty PROPFIND A client may choose not to submit a request body. An empty PROPFIND
request body MUST be treated as if it were an 'allprop' request. request body MUST be treated as if it were an 'allprop' request.
Note that 'allprop' does not return values for all live properties. Note that 'allprop' does not return values for all live properties.
WebDAV servers increasingly have expensively-calculated or lengthy WebDAV servers increasingly have expensively-calculated or lengthy
properties (see [RFC3253] and [RFC3744]) and do not return all properties (see [RFC3253] and [RFC3744]) and do not return all
skipping to change at page 41, line 38 skipping to change at page 41, line 38
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]).
9.1.1. PROPFIND status codes 9.1.1. PROPFIND Status Codes
This section, as with similar sections for other methods, provides This section, as with similar sections for other methods, provides
some guidance on error codes and preconditions or postconditions some guidance on error codes and preconditions or postconditions
(defined in Section 16) that might be particularly useful with (defined in Section 16) that might be particularly useful with
PROPFIND. PROPFIND.
403 Forbidden - A server MAY reject PROPFIND requests on collections 403 Forbidden - A server MAY reject PROPFIND requests on collections
with depth header of "Infinity", in which case it SHOULD use this with depth header of "Infinity", in which case it SHOULD use this
error with the precondition code 'propfind-finite-depth' inside the error with the precondition code 'propfind-finite-depth' inside the
error body. error body.
9.1.2. Status Codes for use in 'propstat' Element 9.1.2. Status Codes for Use in 'propstat' Element
In PROPFIND responses, information about individual properties is In PROPFIND responses, information about individual properties is
returned inside 'propstat' elements (see Section 14.22), each returned inside 'propstat' elements (see Section 14.22), each
containing an individual 'status' element containing information containing an individual 'status' element containing information
about the properties appearing in it. The list below summarizes the about the properties appearing in it. The list below summarizes the
most common status codes used inside 'propstat', however clients most common status codes used inside 'propstat', however clients
should be prepared to handle other 2/3/4/5xx series status codes as should be prepared to handle other 2/3/4/5xx series status codes as
well. well.
200 OK - A property exists and/or its value is successfully returned. 200 OK - A property exists and/or its value is successfully returned.
skipping to change at page 44, line 5 skipping to change at page 44, line 5
</D:responsedescription> </D:responsedescription>
</D:multistatus> </D:multistatus>
In this example, PROPFIND is executed on a non-collection resource In this example, PROPFIND is executed on a non-collection resource
http://www.example.com/file. The propfind XML element specifies the http://www.example.com/file. The propfind XML element specifies the
name of four properties whose values are being requested. In this name of four properties whose values are being requested. In this
case only two properties were returned, since the principal issuing case only two properties were returned, since the principal issuing
the request did not have sufficient access rights to see the third the request did not have sufficient access rights to see the third
and fourth properties. and fourth properties.
9.1.4. Example - Using so-called 'allprop' 9.1.4. Example - Using 'propname' to Retrieve All Property Names
>>Request
PROPFIND /mycol/ HTTP/1.1
Host: www.example.com
Depth: 1
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:include>
<D:supported-live-property-set/>
<D:supported-report-set/>
</D:include>
</D:propfind>
In this example, PROPFIND is executed on the resource
http://www.example.com/mycol/ and its internal member resources. The
client requests the values of all live properties defined in this
specification, plus all dead properties, plus two more live
properties defined in [RFC3253]. The response is not shown.
9.1.5. Example - Using 'propname' to Retrieve all Property Names
>>Request >>Request
PROPFIND /container/ HTTP/1.1 PROPFIND /container/ HTTP/1.1
Host: www.example.com Host: www.example.com
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:"> <propfind xmlns="DAV:">
skipping to change at page 46, line 24 skipping to change at page 46, line 24
creationdate, displayname, getcontentlength, getcontenttype, getetag, creationdate, displayname, getcontentlength, getcontenttype, getetag,
getlastmodified, resourcetype, and supportedlock in the "DAV:" getlastmodified, resourcetype, and supportedlock in the "DAV:"
namespace. namespace.
This example also demonstrates the use of XML namespace scoping and This example also demonstrates the use of XML namespace scoping and
the default namespace. Since the "xmlns" attribute does not contain the default namespace. Since the "xmlns" attribute does not contain
a prefix, the namespace applies by default to all enclosed elements. a prefix, the namespace applies by default to all enclosed elements.
Hence, all elements which do not explicitly state the namespace to Hence, all elements which do not explicitly state the namespace to
which they belong are members of the "DAV:" namespace. which they belong are members of the "DAV:" namespace.
9.1.6. Example - Using 'allprop' 9.1.5. Example - Using So-called 'allprop'
Note that 'allprop', despite its name which remains for backward- Note that 'allprop', despite its name which remains for backward-
compatibility, does not return every property, but only dead compatibility, does not return every property, but only dead
properties and the live properties defined in this specification. properties and the live properties defined in this specification.
>>Request >>Request
PROPFIND /container/ HTTP/1.1 PROPFIND /container/ HTTP/1.1
Host: www.example.com Host: www.example.com
Depth: 1 Depth: 1
skipping to change at page 49, line 5 skipping to change at page 49, line 5
The DAV-specific properties assert that "front.html" was created on The DAV-specific properties assert that "front.html" was created on
December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT
(DAV:creationdate), has a name of "Example HTML resource" (DAV: (DAV:creationdate), has a name of "Example HTML resource" (DAV:
displayname), a content length of 4525 bytes (DAV:getcontentlength), displayname), a content length of 4525 bytes (DAV:getcontentlength),
a MIME type of "text/html" (DAV:getcontenttype), an entity tag of a MIME type of "text/html" (DAV:getcontenttype), an entity tag of
"zzyzx" (DAV:getetag), was last modified on Monday, January 12, 1998, "zzyzx" (DAV:getetag), was last modified on Monday, January 12, 1998,
at 09:25:56 GMT (DAV:getlastmodified), has an empty resource type, at 09:25:56 GMT (DAV:getlastmodified), has an empty resource type,
meaning that it is not a collection (DAV:resourcetype), and supports meaning that it is not a collection (DAV:resourcetype), and supports
both exclusive write and shared write locks (DAV:supportedlock). both exclusive write and shared write locks (DAV:supportedlock).
9.1.6. Example - Using 'allprop' with 'include'
>>Request
PROPFIND /mycol/ HTTP/1.1
Host: www.example.com
Depth: 1
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:include>
<D:supported-live-property-set/>
<D:supported-report-set/>
</D:include>
</D:propfind>
In this example, PROPFIND is executed on the resource
http://www.example.com/mycol/ and its internal member resources. The
client requests the values of all live properties defined in this
specification, plus all dead properties, plus two more live
properties defined in [RFC3253]. The response is not shown.
9.2. PROPPATCH Method 9.2. PROPPATCH Method
The PROPPATCH method processes instructions specified in the request The PROPPATCH method processes instructions specified in the request
body to set and/or remove properties defined on the resource body to set and/or remove properties defined on the resource
identified by the Request-URI. identified by the Request-URI.
All DAV compliant resources MUST support the PROPPATCH method and All DAV compliant resources MUST support the PROPPATCH method and
MUST process instructions that are specified using the MUST process instructions that are specified using the
propertyupdate, set, and remove XML elements. Execution of the propertyupdate, set, and remove XML elements. Execution of the
directives in this method is, of course, subject to access control directives in this method is, of course, subject to access control
skipping to change at page 49, line 37 skipping to change at page 50, line 13
instructions in Section 14.23 and Section 14.26. instructions in Section 14.23 and Section 14.26.
If a server attempts to make any of the property changes in a If a server attempts to make any of the property changes in a
PROPPATCH request (i.e. the request is not rejected for high-level PROPPATCH request (i.e. the request is not rejected for high-level
errors before processing the body), the response MUST be a Multi- errors before processing the body), the response MUST be a Multi-
Status response as described in Section 9.2.1. Status response as described in Section 9.2.1.
This method is idempotent, but not safe (see Section 9.1 of This method is idempotent, but not safe (see Section 9.1 of
[RFC2616]). Responses to this method MUST NOT be cached. [RFC2616]). Responses to this method MUST NOT be cached.
9.2.1. Status Codes for use in 'propstat' Element 9.2.1. Status Codes for Use in 'propstat' Element
In PROPPATCH responses, information about individual properties is In PROPPATCH responses, information about individual properties is
returned inside 'propstat' elements (see Section 14.22), each returned inside 'propstat' elements (see Section 14.22), each
containing an individual 'status' element containing information containing an individual 'status' element containing information
about the properties appearing in it. The list below summarizes the about the properties appearing in it. The list below summarizes the
most common status codes used inside 'propstat', however clients most common status codes used inside 'propstat', however clients
should be prepared to handle other 2/3/4/5xx series status codes as should be prepared to handle other 2/3/4/5xx series status codes as
well. well.
200 (OK) - The property set or change succeeded. Note that if this 200 (OK) - The property set or change succeeded. Note that if this
skipping to change at page 57, line 33 skipping to change at page 58, line 33
have their values set accordingly. have their values set accordingly.
9.8.3. COPY for Collections 9.8.3. COPY for Collections
The COPY method on a collection without a Depth header MUST act as if The COPY method on a collection without a Depth header MUST act as if
a Depth header with value "infinity" was included. A client may a Depth header with value "infinity" was included. A client may
submit a Depth header on a COPY on a collection with a value of "0" submit a Depth header on a COPY on a collection with a value of "0"
or "infinity". Servers MUST support the "0" and "infinity" Depth or "infinity". Servers MUST support the "0" and "infinity" Depth
header behaviors on WebDAV-compliant resources. header behaviors on WebDAV-compliant resources.
A COPY of depth infinity instructs that the collection resource An infinite depth COPY instructs that the collection resource
identified by the Request-URI is to be copied to the location identified by the Request-URI is to be copied to the location
identified by the URI in the Destination header, and all its internal identified by the URI in the Destination header, and all its internal
member resources are to be copied to a location relative to it, member resources are to be copied to a location relative to it,
recursively through all levels of the collection hierarchy. Note recursively through all levels of the collection hierarchy. Note
that a depth infinity COPY of /A/ into /A/B/ could lead to infinite that an infinite depth COPY of /A/ into /A/B/ could lead to infinite
recursion if not handled correctly. recursion if not handled correctly.
A COPY of "Depth: 0" only instructs that the collection and its A COPY of "Depth: 0" only instructs that the collection and its
properties but not resources identified by its internal member URLs, properties but not resources identified by its internal member URLs,
are to be copied. are to be copied.
Any headers included with a COPY MUST be applied in processing every Any headers included with a COPY MUST be applied in processing every
resource to be copied with the exception of the Destination header. resource to be copied with the exception of the Destination header.
The Destination header only specifies the destination URI for the The Destination header only specifies the destination URI for the
skipping to change at page 66, line 20 skipping to change at page 67, line 20
These sections on the LOCK method describe only those semantics that These sections on the LOCK method describe only those semantics that
are specific to the LOCK method and are independent of the access are specific to the LOCK method and are independent of the access
type of the lock being requested. type of the lock being requested.
Any resource which supports the LOCK method MUST, at minimum, support Any resource which supports the LOCK method MUST, at minimum, support
the XML request and response formats defined herein. the XML request and response formats defined herein.
This method is neither idempotent nor safe (see Section 9.1 of This method is neither idempotent nor safe (see Section 9.1 of
[RFC2616]). Responses to this method MUST NOT be cached. [RFC2616]). Responses to this method MUST NOT be cached.
9.10.1. Creating a lock on existing resource 9.10.1. Creating a Lock on an Existing Resource
A LOCK request to an existing resource will create a lock on the A LOCK request to an existing resource will create a lock on the
resource identified by the Request-URI, provided the resource is not resource identified by the Request-URI, provided the resource is not
already locked with a conflicting lock. The resource identified in already locked with a conflicting lock. The resource identified in
the Request-URI becomes the root of the lock. Lock method requests the Request-URI becomes the root of the lock. Lock method requests
to create a new lock MUST have an XML request body. The server MUST to create a new lock MUST have an XML request body. The server MUST
preserve the information provided by the client in the 'owner' field preserve the information provided by the client in the 'owner' field
in the request body when the lock information is requested. The LOCK in the request body when the lock information is requested. The LOCK
request MAY have a Timeout header. request MAY have a Timeout header.
skipping to change at page 75, line 17 skipping to change at page 76, line 17
All DAV headers follow the same basic formatting rules as HTTP All DAV headers follow the same basic formatting rules as HTTP
headers. This includes rules like line continuation and how to headers. This includes rules like line continuation and how to
combine (or separate) multiple instances of the same header using combine (or separate) multiple instances of the same header using
commas. commas.
WebDAV adds two new conditional headers to the set defined in HTTP: WebDAV adds two new conditional headers to the set defined in HTTP:
the If and Overwrite headers. the If and Overwrite headers.
10.1. DAV Header 10.1. DAV Header
DAV = "DAV" ":" #( compliance-class ) DAV = "DAV" ":" #( compliance-class )
compliance-class = ( "1" | "2" | "3" | extend ) compliance-class = ( "1" | "2" | "3" | extend )
extend = Coded-URL | token extend = Coded-URL | token
Coded-URL = "<" absolute-URI ">" Coded-URL = "<" absolute-URI ">"
; No LWS allowed in Coded-URL ; No linear white space (LWS) allowed in Coded-URL
; absolute-URI is defined in RFC3986 ; absolute-URI is defined in RFC3986
This general-header appearing in the response indicates that the This general-header appearing in the response indicates that the
resource supports the DAV schema and protocol as specified. All DAV resource supports the DAV schema and protocol as specified. All DAV
compliant resources MUST return the DAV header with compliance-class compliant resources MUST return the DAV header with compliance-class
"1" on all OPTIONS responses. In cases where WebDAV is only "1" on all OPTIONS responses. In cases where WebDAV is only
supported in part of the server namespace, an OPTIONS request to non- supported in part of the server namespace, an OPTIONS request to non-
WebDAV resources (including "/") SHOULD NOT advertise WebDAV support. WebDAV resources (including "/") SHOULD NOT advertise WebDAV support.
The value is a comma-separated list of all compliance class The value is a comma-separated list of all compliance class
identifiers that the resource supports. Class identifiers may be identifiers that the resource supports. Class identifiers may be
skipping to change at page 83, line 8 skipping to change at page 84, line 8
Overwrite = "Overwrite" ":" ("T" | "F") Overwrite = "Overwrite" ":" ("T" | "F")
The Overwrite request header specifies whether the server should The Overwrite request header specifies whether the server should
overwrite a resource mapped to the destination URL during a COPY or overwrite a resource mapped to the destination URL during a COPY or
MOVE. A value of "F" states that the server must not perform the MOVE. A value of "F" states that the server must not perform the
COPY or MOVE operation if the destination URL does map to a resource. COPY or MOVE operation if the destination URL does map to a resource.
If the overwrite header is not included in a COPY or MOVE request If the overwrite header is not included in a COPY or MOVE request
then the resource MUST treat the request as if it has an overwrite then the resource MUST treat the request as if it has an overwrite
header of value "T". While the Overwrite header appears to duplicate header of value "T". While the Overwrite header appears to duplicate
the functionality of the If-Match: * header of HTTP/1.1, If-Match the functionality of using a "If-Match: *" header (see [RFC2616]),
applies only to the Request-URI, and not to the Destination of a COPY If-Match applies only to the Request-URI, and not to the Destination
or MOVE. of a COPY or MOVE.
If a COPY or MOVE is not performed due to the value of the Overwrite If a COPY or MOVE is not performed due to the value of the Overwrite
header, the method MUST fail with a 412 (Precondition Failed) status header, the method MUST fail with a 412 (Precondition Failed) status
code. The server MUST do authorization checks before checking this code. The server MUST do authorization checks before checking this
or any conditional header. or any conditional header.
All DAV compliant resources MUST support the Overwrite header. All DAV compliant resources MUST support the Overwrite header.
10.7. Timeout Request Header 10.7. Timeout Request Header
skipping to change at page 86, line 30 skipping to change at page 87, line 30
The 'multistatus' root element holds zero or more 'response' elements The 'multistatus' root element holds zero or more 'response' elements
in any order, each with information about an individual resource. in any order, each with information about an individual resource.
Each 'response' element MUST have an 'href' element to identify the Each 'response' element MUST have an 'href' element to identify the
resource. resource.
A Multi-Status response uses one out of two distinct formats for A Multi-Status response uses one out of two distinct formats for
representing the status: representing the status:
1. A 'status' element as child of the 'response' element indicates 1. A 'status' element as child of the 'response' element indicates
the status of the message excecution for the identified resource the status of the message execution for the identified resource
as a whole (for instance, see Section 9.6.2). Some method as a whole (for instance, see Section 9.6.2). Some method
definitions provide information about specific status codes definitions provide information about specific status codes
clients should be prepared to see in a response. However, clients should be prepared to see in a response. However,
clients MUST be able to handle other status codes, using the clients MUST be able to handle other status codes, using the
generic rules defined in Section 10 of [RFC2616]. generic rules defined in Section 10 of [RFC2616].
2. For PROPFIND and PROPPATCH, the format has been extended using 2. For PROPFIND and PROPPATCH, the format has been extended using
the 'propstat' element instead of 'status', providing information the 'propstat' element instead of 'status', providing information
about individual properties of a resource. This format is about individual properties of a resource. This format is
specific to PROPFIND and PROPPATCH, and is described in detail in specific to PROPFIND and PROPPATCH, and is described in detail in
Section 9.1 and Section 9.2. Section 9.1 and Section 9.2.
13.1. Response headers 13.1. Response Headers
HTTP defines the Location header to indicate a preferred URL for the HTTP defines the Location header to indicate a preferred URL for the
resource that was addressed in the Request-URI (e.g. in response to resource that was addressed in the Request-URI (e.g. in response to
successful PUT requests or in redirect responses). However, use of successful PUT requests or in redirect responses). However, use of
this header creates ambiguity when there are URLs in the body of the this header creates ambiguity when there are URLs in the body of the
response, as with Multi-Status. Thus, use of the Location header response, as with Multi-Status. Thus, use of the Location header
with the Multi-Status response is intentionally undefined. with the Multi-Status response is intentionally undefined.
13.2. Handling redirected child resources 13.2. Handling Redirected Child Resources
Redirect responses (300-303, 305 and 307) defined in HTTP 1.1 Redirect responses (300-303, 305 and 307) defined in HTTP 1.1
normally take a Location header to indicate the new URI for the normally take a Location header to indicate the new URI for the
single resource redirected from the Request-URI. Multi-Status single resource redirected from the Request-URI. Multi-Status
responses contain many resource addresses, but the original responses contain many resource addresses, but the original
definition in [RFC2518] did not have any place for the server to definition in [RFC2518] did not have any place for the server to
provide the new URI for redirected resources. This specification provide the new URI for redirected resources. This specification
does define a 'location' element for this information (see does define a 'location' element for this information (see
Section 14.9). Servers MUST use this new element with redirect Section 14.9). Servers MUST use this new element with redirect
responses in Multi-Status. responses in Multi-Status.
skipping to change at page 92, line 42 skipping to change at page 93, line 42
of interoperability between different client implementations, if of interoperability between different client implementations, if
clients have URI-formatted contact information for the lock clients have URI-formatted contact information for the lock
creator suitable for user display, then clients SHOULD put those creator suitable for user display, then clients SHOULD put those
URIs in 'href' child elements of the 'owner' element. URIs in 'href' child elements of the 'owner' element.
Extensibility: MAY be extended with child elements, mixed content, Extensibility: MAY be extended with child elements, mixed content,
text content or attributes. text content or attributes.
<!ELEMENT owner ANY > <!ELEMENT owner ANY >
14.18. prop XML element 14.18. prop XML Element
Name: prop Name: prop
Purpose: Contains properties related to a resource. Purpose: Contains properties related to a resource.
Description: A generic container for properties defined on Description: A generic container for properties defined on
resources. All elements inside a 'prop' XML element MUST define resources. All elements inside a 'prop' XML element MUST define
properties related to the resource, although possible property properties related to the resource, although possible property
names are in no way limited to those property names defined in names are in no way limited to those property names defined in
this document or other standards. This element MUST NOT contain this document or other standards. This element MUST NOT contain
text or mixed content. text or mixed content.
<!ELEMENT prop ANY > <!ELEMENT prop ANY >
14.19. propertyupdate XML element 14.19. propertyupdate XML Element
Name: propertyupdate Name: propertyupdate
Purpose: Contains a request to alter the properties on a resource. Purpose: Contains a request to alter the properties on a resource.
Description: This XML element is a container for the information Description: This XML element is a container for the information
required to modify the properties on the resource. required to modify the properties on the resource.
<!ELEMENT propertyupdate (remove | set)+ > <!ELEMENT propertyupdate (remove | set)+ >
skipping to change at page 94, line 16 skipping to change at page 95, line 16
Description: The propstat XML element MUST contain one prop XML Description: The propstat XML element MUST contain one prop XML
element and one status XML element. The contents of the prop XML element and one status XML element. The contents of the prop XML
element MUST only list the names of properties to which the result element MUST only list the names of properties to which the result
in the status element applies. The optional precondition/ in the status element applies. The optional precondition/
postcondition element and 'responsedescription' text also apply to postcondition element and 'responsedescription' text also apply to
the properties named in 'prop'. the properties named in 'prop'.
<!ELEMENT propstat (prop, status, error?, responsedescription?) > <!ELEMENT propstat (prop, status, error?, responsedescription?) >
14.23. remove XML element 14.23. remove XML Element
Name: remove Name: remove
Purpose: Lists the properties to be removed from a resource. Purpose: Lists the properties to be removed from a resource.
Description: Remove instructs that the properties specified in prop Description: Remove instructs that the properties specified in prop
should be removed. Specifying the removal of a property that does should be removed. Specifying the removal of a property that does
not exist is not an error. All the XML elements in a 'prop' XML not exist is not an error. All the XML elements in a 'prop' XML
element inside of a 'remove' XML element MUST be empty, as only element inside of a 'remove' XML element MUST be empty, as only
the names of properties to be removed are required. the names of properties to be removed are required.
skipping to change at page 95, line 18 skipping to change at page 96, line 18
Name: responsedescription Name: responsedescription
Purpose: Contains information about a status response within a Purpose: Contains information about a status response within a
Multi-Status. Multi-Status.
Description: Provides information suitable to be presented to a Description: Provides information suitable to be presented to a
user. user.
<!ELEMENT responsedescription (#PCDATA) > <!ELEMENT responsedescription (#PCDATA) >
14.26. set XML element 14.26. set XML Element
Name: set Name: set
Purpose: Lists the property values to be set for a resource. Purpose: Lists the property values to be set for a resource.
Description: The 'set' element MUST contain only a 'prop' element. Description: The 'set' element MUST contain only a 'prop' element.
The elements contained by the 'prop' element inside the 'set' The elements contained by the 'prop' element inside the 'set'
element MUST specify the name and value of properties that are set element MUST specify the name and value of properties that are set
on the resource identified by Request-URI. If a property already on the resource identified by Request-URI. If a property already
exists then its value is replaced. Language tagging information exists then its value is replaced. Language tagging information
skipping to change at page 101, line 48 skipping to change at page 102, line 48
Protected: MUST be protected. Clients change the list of locks Protected: MUST be protected. Clients change the list of locks
through LOCK and UNLOCK, not through PROPPATCH. through LOCK and UNLOCK, not through PROPPATCH.
COPY/MOVE behaviour: The value of this property depends on the lock COPY/MOVE behaviour: The value of this property depends on the lock
state of the destination, not on the locks of the source resource. state of the destination, not on the locks of the source resource.
Recall that locks are not moved in a MOVE operation. Recall that locks are not moved in a MOVE operation.
Description: Returns a listing of who has a lock, what type of lock Description: Returns a listing of who has a lock, what type of lock
he has, the timeout type and the time remaining on the timeout, he has, the timeout type and the time remaining on the timeout,
and the associated lock token. If there are no locks, but the and the associated lock token. Owner information MAY be omitted
if it is considered sensitive. If there are no locks, but the
server supports locks, the property will be present but contain server supports locks, the property will be present but contain
zero 'activelock' elements. If there is one or more lock, an zero 'activelock' elements. If there is one or more lock, an
'activelock' element appears for each lock on the resource. This 'activelock' element appears for each lock on the resource. This
property is NOT lockable with respect to write locks (Section 7). property is NOT lockable with respect to write locks (Section 7).
<!ELEMENT lockdiscovery (activelock)* > <!ELEMENT lockdiscovery (activelock)* >
15.8.1. Example - Retrieving DAV:lockdiscovery 15.8.1. Example - Retrieving DAV:lockdiscovery
>>Request >>Request
skipping to change at page 106, line 5 skipping to change at page 107, line 5
<D:lockscope><D:shared/></D:lockscope> <D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype> <D:locktype><D:write/></D:locktype>
</D:lockentry> </D:lockentry>
</D:supportedlock> </D:supportedlock>
</D:prop> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status> <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
16. Precondition/postcondition XML elements 16. Precondition/Postcondition XML Elements
As introduced in Section 8.7, extra information on error conditions As introduced in Section 8.7, extra information on error conditions
can be included in the body of many status responses. This section can be included in the body of many status responses. This section
makes requirements on the use of the error body mechanism and makes requirements on the use of the error body mechanism and
introduces a number of precondition and postcondition codes. introduces a number of precondition and postcondition codes.
A "precondition" of a method describes the state of the server that A "precondition" of a method describes the state of the server that
must be true for that method to be performed. A "postcondition" of a must be true for that method to be performed. A "postcondition" of a
method describes the state of the server that must be true after that method describes the state of the server that must be true after that
method has been completed. method has been completed.
skipping to change at page 107, line 17 skipping to change at page 108, line 17
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:"> <D:error xmlns:D="DAV:">
<D:lock-token-submitted> <D:lock-token-submitted>
<D:href>/workspace/webdav/</D:href> <D:href>/workspace/webdav/</D:href>
</D:lock-token-submitted> </D:lock-token-submitted>
</D:error> </D:error>
In this example, a client unaware of a "Depth: infinity" lock on the In this example, a client unaware of a depth-infinity lock on the
parent collection "/workspace/webdav/" attempted to modify the parent collection "/workspace/webdav/" attempted to modify the
collection member "/workspace/webdav/proposal.doc". collection member "/workspace/webdav/proposal.doc".
Some other useful preconditions and postconditions have been defined Some other useful preconditions and postconditions have been defined
in other specifications extending WebDAV, such as [RFC3744] (see in other specifications extending WebDAV, such as [RFC3744] (see
particularly Section 7.1.1), [RFC3253], and [RFC3648]. particularly Section 7.1.1), [RFC3253], and [RFC3648].
All these elements are in the "DAV:" namespace. If not specified All these elements are in the "DAV:" namespace. If not specified
otherwise, the content for each condition's XML element is defined to otherwise, the content for each condition's XML element is defined to
be empty. be empty.
skipping to change at page 116, line 33 skipping to change at page 117, line 33
authentication. authentication.
A password sent in the clear over an insecure channel is an A password sent in the clear over an insecure channel is an
inadequate means for protecting the accessibility and integrity of a inadequate means for protecting the accessibility and integrity of a
resource as the password may be intercepted. Since Basic resource as the password may be intercepted. Since Basic
authentication for HTTP/1.1 performs essentially clear text authentication for HTTP/1.1 performs essentially clear text
transmission of a password, Basic authentication MUST NOT be used to transmission of a password, Basic authentication MUST NOT be used to
authenticate a WebDAV client to a server unless the connection is authenticate a WebDAV client to a server unless the connection is
secure. Furthermore, a WebDAV server MUST NOT send a Basic secure. Furthermore, a WebDAV server MUST NOT send a Basic
authentication challenge in a WWW-Authenticate header unless the authentication challenge in a WWW-Authenticate header unless the
connection is secure. An examples of a secure connections would be a connection is secure. An example of a secure connection would be a
Transport Layer Security (TLS) connection employing a strong cipher Transport Layer Security (TLS) connection employing a strong cipher
suite and server authentication. suite and server authentication.
WebDAV applications MUST support the Digest authentication scheme WebDAV applications MUST support the Digest authentication scheme
[RFC2617]. Since Digest authentication verifies that both parties to [RFC2617]. Since Digest authentication verifies that both parties to
a communication know a shared secret, a password, without having to a communication know a shared secret, a password, without having to
send that secret in the clear, Digest authentication avoids the send that secret in the clear, Digest authentication avoids the
security problems inherent in Basic authentication while providing a security problems inherent in Basic authentication while providing a
level of authentication which is useful in a wide range of scenarios. level of authentication which is useful in a wide range of scenarios.
skipping to change at page 128, line 7 skipping to change at page 129, 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., "Design Considerations for State
Identifiers in HTTP and WebDAV",
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 132, line 5 skipping to change at page 133, line 5
request against a WebDAV collection, this concern is more theoretical request against a WebDAV collection, this concern is more theoretical
than practical. Thus, servers are likely to be completely successful than practical. Thus, servers are likely to be completely successful
at interoperating with HTTP clients even if they treat any collection at interoperating with HTTP clients even if they treat any collection
DELETE request as a WebDAV request and send a 207 Multistatus DELETE request as a WebDAV request and send a 207 Multistatus
response. response.
In general server implementations are encouraged to use the detailed In general server implementations are encouraged to use the detailed
responses and other mechanisms defined in this document rather than responses and other mechanisms defined in this document rather than
make changes for theoretical interoperability concerns. 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
extension. Servers can create new UUIDs for each new lock token. If extension. Servers can create new UUIDs for each new lock token. If
a server wishes to reuse UUIDs the server MUST add an extension and a server wishes to reuse UUIDs the server MUST add an extension and
the algorithm generating the extension MUST guarantee that the same the algorithm generating the extension MUST guarantee that the same
extension will never be used twice with the associated UUID. extension will never be used twice with the associated UUID.
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
; UUID is defined in Section 3 of [RFC4122]. Note that linear ; UUID is defined in Section 3 of [RFC4122]. Note that LWS
; white space (LWS) is not allowed between elements of ; is not allowed between elements of
; this production. ; this production.
Extension = path Extension = path
; path is defined in Section 3.3 of [RFC3986] ; path is defined in Section 3.3 of [RFC3986]
Appendix D. Lock-null Resources Appendix D. Lock-null Resources
The original WebDAV model for locking unmapped URLs created "lock- The original WebDAV model for locking unmapped URLs created "lock-
null resources". This model was over-complicated and some null resources". This model was over-complicated and some
interoperability and implementation problems were discovered. The interoperability and implementation problems were discovered. The
skipping to change at page 134, line 5 skipping to change at page 134, line 47
o Property values were defined for DAV:lockdiscovery and DAV: o Property values were defined for DAV:lockdiscovery and DAV:
supportedlock properties but not necessarily for other properties supportedlock properties but not necessarily for other properties
like DAV:getcontenttype. like DAV:getcontenttype.
Clients can easily interoperate both with servers that support the Clients can easily interoperate both with servers that support the
old model "lock-null resources" and the recommended model of "locked old model "lock-null resources" and the recommended model of "locked
empty resources" by only attempting PUT after a LOCK to an unmapped empty resources" by only attempting PUT after a LOCK to an unmapped
URL, not MKCOL or GET. URL, not MKCOL or GET.
D.1. Guidance for Clients Using LOCK to Create Resources
A WebDAV client implemented to this specification might find servers
that create lock-null resources (implemented before this
specification using [RFC2518]) as well as servers that create locked
empty resources. The response to the LOCK request will not indicate
what kind of resource was created. There are a few techniques which
help the client deal with either type.
If the client wishes to avoid accidentally creating either lock-
null or empty locked resources, an "If-Match: *" header can be
included with LOCK requests to prevent the server from creating a
new resource.
If a LOCK request creates a resource and the client subsequently
wants to overwrite that resource using a COPY or MOVE request, the
client should include an "Overwrite: T" header.
If a LOCK request creates a resource and the client then decides
to get rid of that resource, a DELETE request is supposed to fail
on a lock-null resource and UNLOCK should be used instead. But
with a locked empty resource, UNLOCK doesn't make the resource
disappear. Therefore, the client might have to try both requests
and ignore an error in one of the two requests.
Appendix E. Guidance for Clients Desiring to Authenticate Appendix E. Guidance for Clients Desiring to Authenticate
Many WebDAV clients already implemented have account settings Many WebDAV clients already implemented have account settings
(similar to the way email clients store IMAP account settings). (similar to the way email clients store IMAP account settings).
Thus, the WebDAV client would be able to authenticate with its first Thus, the WebDAV client would be able to authenticate with its first
couple requests to the server, provided it had a way to get the couple requests to the server, provided it had a way to get the
authentication challenge from the server with realm name, nonce and authentication challenge from the server with realm name, nonce and
other challenge information. Note that the results of some requests other challenge information. Note that the results of some requests
might vary according to whether the client is authenticated or not -- might vary according to whether the client is authenticated or not --
a PROPFIND might return more visible resources if the client is a PROPFIND might return more visible resources if the client is
skipping to change at page 136, line 18 skipping to change at page 138, line 18
starting with those that are likely to result in implementation starting with those that are likely to result in implementation
changes. Servers will advertise support for all changes in this changes. Servers will advertise support for all changes in this
specification by returning the compliance class "3" in the DAV specification by returning the compliance class "3" in the DAV
response header (see Sections 10.1 and 18.3). response header (see Sections 10.1 and 18.3).
F.1. Changes for both Client and Server Implementations F.1. Changes for both Client and Server Implementations
Collections and Namespace Operations Collections and Namespace Operations
o The semantics of PROPFIND 'allprop' (Section 9.1) have been o The semantics of PROPFIND 'allprop' (Section 9.1) have been
relaxed so that servers may leave out live properties defined in relaxed so that servers return results including, at a minimum,
other specifications, such as [RFC3253] and [RFC3744]. Related to the live properties defined in this specification, but not
this, 'allprop' requests can now be extended with the 'include' necessarily return other live properties. The 'allprop' directive
syntax to include specific named properties, thereby avoiding therefore means something more like "return all properties that
additional requests due to changed 'allprop' semantics. are supposed to be returned when 'allprop' is requested" -- a set
of properties which may include custom properties and properties
defined in other specifications if those other specifications so
require. 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.
o Servers are now allowed to reject PROPFIND requests with Depth: o Servers are now allowed to reject PROPFIND requests with Depth:
Infinity. Clients that used this will need to be able to do a Infinity. Clients that used this will need to be able to do a
series of Depth:1 requests instead. series of Depth:1 requests instead.
o Multistatus response bodies now can transport the value of HTTP's o Multistatus response bodies now can transport the value of HTTP's
Location response header in the new 'location' element. Clients Location response header in the new 'location' element. Clients
may use this to avoid additional roundtrips to the server when may use this to avoid additional roundtrips to the server when
there is a 'response' element with a 3xx status (see there is a 'response' element with a 3xx status (see
Section 14.24). Section 14.24).
skipping to change at page 144, line 9 skipping to change at page 147, line 9
G.11. Changes in -16 G.11. Changes in -16
Fixed factual errors in Security Considerations authentication Fixed factual errors in Security Considerations authentication
section. section.
Fixed example of refreshing a lock -- didn't use "If" header as Fixed example of refreshing a lock -- didn't use "If" header as
required in the text. required in the text.
Fixed example of using so-called 'all-prop' with the 'include' Fixed example of using so-called 'all-prop' with the 'include'
directive, so that it would actually be a useful example, by directivenotifi, so that it would actually be a useful example, by
including live properties that wouldn't already be covered by 'all- including live properties that wouldn't already be covered by 'all-
prop'. prop'.
Clarified requirement in section 7.7 paragraph 2 -- a clear Clarified requirement in section 7.7 paragraph 2 -- a clear
requirement for the server to meet, rather than passive voice "this requirement for the server to meet, rather than passive voice "this
request MUST only be used". request MUST only be used".
Made explicit requirement for successful response format for Made explicit requirement for successful response format for
PROPPATCH (bug 238) PROPPATCH (bug 238)
skipping to change at page 145, line 5 skipping to change at page 147, line 37
Change reference for PROPFIND MultiStatus response format from Change reference for PROPFIND MultiStatus response format from
section 15 to section 9.2.1 section 15 to section 9.2.1
Add another "except" clause to statement requiring pre/postcondition Add another "except" clause to statement requiring pre/postcondition
codes to appear in 'error' codes to appear in 'error'
Remove requirement to use TLS -- back to requiring channel to be Remove requirement to use TLS -- back to requiring channel to be
secure. secure.
G.13. Changes in -18
Text clarifications and typo fixes in response to IETF Last Call
comments
Removed suggestive/confusing text about lock notifications
Add section with guidance for clients dealing with both lock-null
resources and locked empty resources.
Allow servers to omit owner information in lockdiscovery property.
Clarify what 'allprop' means, mostly fixing misleading text in change
summary
Author's Address Author's Address
Lisa Dusseault (editor) Lisa Dusseault (editor)
CommerceNet CommerceNet
2064 Edgewood Dr. 2064 Edgewood Dr.
Palo Alto, CA 94303 Palo Alto, CA 94303
US US
Email: ldusseault@commerce.net Email: ldusseault@commerce.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 68 change blocks. 
340 lines changed or deleted 386 lines changed or added

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