draft-ietf-webdav-rfc2518bis-09.txt   draft-ietf-webdav-rfc2518bis-10.txt 
WebDAV L. Dusseault WebDAV L. Dusseault
Internet-Draft OSAF Internet-Draft OSAF
Obsoletes: 2518 (if approved) November 2005 Obsoletes: 2518 (if approved) December 30, 2005
Expires: May 5, 2006 Expires: July 3, 2006
HTTP Extensions for Distributed Authoring - WebDAV HTTP Extensions for Distributed Authoring - WebDAV
draft-ietf-webdav-rfc2518bis-09 draft-ietf-webdav-rfc2518bis-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2006. This Internet-Draft will expire on July 3, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
6.5. Active Lock Discovery . . . . . . . . . . . . . . . . . 21 6.5. Active Lock Discovery . . . . . . . . . . . . . . . . . 21
6.6. Locks and Multiple Bindings . . . . . . . . . . . . . . 22 6.6. Locks and Multiple Bindings . . . . . . . . . . . . . . 22
7. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Write Lock . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Lock Owner . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. Lock Owner . . . . . . . . . . . . . . . . . . . . . . . 23
7.2. Methods Restricted by Write Locks . . . . . . . . . . . 23 7.2. Methods Restricted by Write Locks . . . . . . . . . . . 23
7.3. Write Locks and Lock Tokens . . . . . . . . . . . . . . 24 7.3. Write Locks and Lock Tokens . . . . . . . . . . . . . . 24
7.4. Write Locks and Properties . . . . . . . . . . . . . . . 24 7.4. Write Locks and Properties . . . . . . . . . . . . . . . 24
7.5. Avoiding Lost Updates . . . . . . . . . . . . . . . . . 24 7.5. Avoiding Lost Updates . . . . . . . . . . . . . . . . . 24
7.6. Write Locks and Unmapped URLs . . . . . . . . . . . . . 25 7.6. Write Locks and Unmapped URLs . . . . . . . . . . . . . 25
7.7. Write Locks and Collections . . . . . . . . . . . . . . 27 7.7. Write Locks and Collections . . . . . . . . . . . . . . 27
7.8. Write Locks and the If Request Header . . . . . . . . . 28 7.8. Write Locks and the If Request Header . . . . . . . . . 29
7.8.1. Example - Write Lock . . . . . . . . . . . . . . . . 29 7.8.1. Example - Write Lock . . . . . . . . . . . . . . . . 29
7.9. Write Locks and COPY/MOVE . . . . . . . . . . . . . . . 29 7.9. Write Locks and COPY/MOVE . . . . . . . . . . . . . . . 30
7.10. Refreshing Write Locks . . . . . . . . . . . . . . . . . 30 7.10. Refreshing Write Locks . . . . . . . . . . . . . . . . . 30
8. HTTP Methods for Distributed Authoring . . . . . . . . . . . 31 8. HTTP Methods for Distributed Authoring . . . . . . . . . . . 31
8.1. General Request and Response Handling . . . . . . . . . 31 8.1. General Request and Response Handling . . . . . . . . . 31
8.1.1. Use of XML . . . . . . . . . . . . . . . . . . . . . 31 8.1.1. Use of XML . . . . . . . . . . . . . . . . . . . . . 31
8.1.2. Required Bodies in Requests . . . . . . . . . . . . 31 8.1.2. Required Bodies in Requests . . . . . . . . . . . . 31
8.1.3. HTTP Headers for use in WebDAV . . . . . . . . . . . 31 8.1.3. HTTP Headers for use in WebDAV . . . . . . . . . . . 31
8.1.4. ETag . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1.4. ETag . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1.5. Including error response bodies . . . . . . . . . . 32 8.1.5. Including error response bodies . . . . . . . . . . 32
8.2. PROPFIND . . . . . . . . . . . . . . . . . . . . . . . . 33 8.2. PROPFIND . . . . . . . . . . . . . . . . . . . . . . . . 32
8.2.1. PROPFIND status codes . . . . . . . . . . . . . . . 35 8.2.1. PROPFIND status codes . . . . . . . . . . . . . . . 34
8.2.2. Status codes for use with 207 (Multi-Status) . . . . 35 8.2.2. Status codes for use with 207 (Multi-Status) . . . . 34
8.2.3. Example - Retrieving Named Properties . . . . . . . 35 8.2.3. Example - Retrieving Named Properties . . . . . . . 35
8.2.4. Example - Retrieving Named and Dead Properties . . . 37 8.2.4. Example - Retrieving Named and Dead Properties . . . 37
8.2.5. Example - Using 'propname' to Retrieve all 8.2.5. Example - Using 'propname' to Retrieve all
Property Names . . . . . . . . . . . . . . . . . . . 37 Property Names . . . . . . . . . . . . . . . . . . . 37
8.2.6. Example - Using 'allprop' . . . . . . . . . . . . . 39 8.2.6. Example - Using 'allprop' . . . . . . . . . . . . . 39
8.3. PROPPATCH . . . . . . . . . . . . . . . . . . . . . . . 41 8.3. PROPPATCH . . . . . . . . . . . . . . . . . . . . . . . 41
8.3.1. Status Codes for use in 207 (Multi-Status) . . . . . 42 8.3.1. Status Codes for use in 207 (Multi-Status) . . . . . 42
8.3.2. Example - PROPPATCH . . . . . . . . . . . . . . . . 43 8.3.2. Example - PROPPATCH . . . . . . . . . . . . . . . . 43
8.4. MKCOL Method . . . . . . . . . . . . . . . . . . . . . . 44 8.4. MKCOL Method . . . . . . . . . . . . . . . . . . . . . . 44
8.4.1. MKCOL Status Codes . . . . . . . . . . . . . . . . . 45 8.4.1. MKCOL Status Codes . . . . . . . . . . . . . . . . . 45
skipping to change at page 4, line 4 skipping to change at page 4, line 4
8.11.6. Example - Simple Lock Request . . . . . . . . . . . 62 8.11.6. Example - Simple Lock Request . . . . . . . . . . . 62
8.11.7. Example - Refreshing a Write Lock . . . . . . . . . 64 8.11.7. Example - Refreshing a Write Lock . . . . . . . . . 64
8.11.8. Example - Multi-Resource Lock Request . . . . . . . 65 8.11.8. Example - Multi-Resource Lock Request . . . . . . . 65
8.12. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . 66 8.12. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . 66
8.12.1. Status Codes . . . . . . . . . . . . . . . . . . . . 66 8.12.1. Status Codes . . . . . . . . . . . . . . . . . . . . 66
8.12.2. Example - UNLOCK . . . . . . . . . . . . . . . . . . 67 8.12.2. Example - UNLOCK . . . . . . . . . . . . . . . . . . 67
9. HTTP Headers for Distributed Authoring . . . . . . . . . . . 68 9. HTTP Headers for Distributed Authoring . . . . . . . . . . . 68
9.1. DAV Header . . . . . . . . . . . . . . . . . . . . . . . 68 9.1. DAV Header . . . . . . . . . . . . . . . . . . . . . . . 68
9.2. Depth Header . . . . . . . . . . . . . . . . . . . . . . 68 9.2. Depth Header . . . . . . . . . . . . . . . . . . . . . . 68
9.3. Destination Header . . . . . . . . . . . . . . . . . . . 70 9.3. Destination Header . . . . . . . . . . . . . . . . . . . 70
9.4. Force-Authentication Header . . . . . . . . . . . . . . 70 9.4. If Header . . . . . . . . . . . . . . . . . . . . . . . 70
9.5. If Header . . . . . . . . . . . . . . . . . . . . . . . 70 9.4.1. No-tag-list Production . . . . . . . . . . . . . . . 71
9.5.1. No-tag-list Production . . . . . . . . . . . . . . . 71 9.4.2. Tagged-list Production . . . . . . . . . . . . . . . 71
9.5.2. Tagged-list Production . . . . . . . . . . . . . . . 71 9.4.3. Example - Tagged List If header in COPY . . . . . . 72
9.5.3. Example - Tagged List If header in COPY . . . . . . 72 9.4.4. Not Production . . . . . . . . . . . . . . . . . . . 72
9.5.4. Not Production . . . . . . . . . . . . . . . . . . . 72 9.4.5. Matching Function . . . . . . . . . . . . . . . . . 73
9.5.5. Matching Function . . . . . . . . . . . . . . . . . 73 9.4.6. If Header and Non-DAV Aware Proxies . . . . . . . . 73
9.5.6. If Header and Non-DAV Aware Proxies . . . . . . . . 73 9.5. Lock-Token Header . . . . . . . . . . . . . . . . . . . 74
9.6. Lock-Token Header . . . . . . . . . . . . . . . . . . . 74 9.6. Overwrite Header . . . . . . . . . . . . . . . . . . . . 74
9.7. Overwrite Header . . . . . . . . . . . . . . . . . . . . 74 9.7. Timeout Request Header . . . . . . . . . . . . . . . . . 74
9.8. Timeout Request Header . . . . . . . . . . . . . . . . . 74
10. Status Code Extensions to HTTP/1.1 . . . . . . . . . . . . . 76 10. Status Code Extensions to HTTP/1.1 . . . . . . . . . . . . . 76
10.1. 207 Multi-Status . . . . . . . . . . . . . . . . . . . . 76 10.1. 207 Multi-Status . . . . . . . . . . . . . . . . . . . . 76
10.2. 422 Unprocessable Entity . . . . . . . . . . . . . . . . 76 10.2. 422 Unprocessable Entity . . . . . . . . . . . . . . . . 76
10.3. 423 Locked . . . . . . . . . . . . . . . . . . . . . . . 76 10.3. 423 Locked . . . . . . . . . . . . . . . . . . . . . . . 76
10.4. 424 Failed Dependency . . . . . . . . . . . . . . . . . 76 10.4. 424 Failed Dependency . . . . . . . . . . . . . . . . . 76
10.5. 507 Insufficient Storage . . . . . . . . . . . . . . . . 76 10.5. 507 Insufficient Storage . . . . . . . . . . . . . . . . 76
11. Use of HTTP Status Codes . . . . . . . . . . . . . . . . . . 77 11. Use of HTTP Status Codes . . . . . . . . . . . . . . . . . . 77
11.1. 412 Precondition Failed . . . . . . . . . . . . . . . . 77 11.1. 412 Precondition Failed . . . . . . . . . . . . . . . . 77
11.2. 414 Request-URI Too Long . . . . . . . . . . . . . . . . 77 11.2. 414 Request-URI Too Long . . . . . . . . . . . . . . . . 77
12. Multi-Status Response . . . . . . . . . . . . . . . . . . . . 78 12. Multi-Status Response . . . . . . . . . . . . . . . . . . . . 78
skipping to change at page 5, line 17 skipping to change at page 5, line 16
13.26. set XML element . . . . . . . . . . . . . . . . . . . . 88 13.26. set XML element . . . . . . . . . . . . . . . . . . . . 88
13.27. shared XML Element . . . . . . . . . . . . . . . . . . . 89 13.27. shared XML Element . . . . . . . . . . . . . . . . . . . 89
13.28. status XML Element . . . . . . . . . . . . . . . . . . . 89 13.28. status XML Element . . . . . . . . . . . . . . . . . . . 89
13.29. timeout XML Element . . . . . . . . . . . . . . . . . . 89 13.29. timeout XML Element . . . . . . . . . . . . . . . . . . 89
13.30. write XML Element . . . . . . . . . . . . . . . . . . . 90 13.30. write XML Element . . . . . . . . . . . . . . . . . . . 90
14. DAV Properties . . . . . . . . . . . . . . . . . . . . . . . 91 14. DAV Properties . . . . . . . . . . . . . . . . . . . . . . . 91
14.1. creationdate Property . . . . . . . . . . . . . . . . . 91 14.1. creationdate Property . . . . . . . . . . . . . . . . . 91
14.2. displayname Property . . . . . . . . . . . . . . . . . . 92 14.2. displayname Property . . . . . . . . . . . . . . . . . . 92
14.3. getcontentlanguage Property . . . . . . . . . . . . . . 92 14.3. getcontentlanguage Property . . . . . . . . . . . . . . 92
14.4. getcontentlength Property . . . . . . . . . . . . . . . 93 14.4. getcontentlength Property . . . . . . . . . . . . . . . 93
14.5. getcontenttype Property . . . . . . . . . . . . . . . . 93 14.5. getcontenttype Property . . . . . . . . . . . . . . . . 94
14.6. getetag Property . . . . . . . . . . . . . . . . . . . . 94 14.6. getetag Property . . . . . . . . . . . . . . . . . . . . 94
14.7. getlastmodified Property . . . . . . . . . . . . . . . . 94 14.7. getlastmodified Property . . . . . . . . . . . . . . . . 95
14.8. lockdiscovery Property . . . . . . . . . . . . . . . . . 95 14.8. lockdiscovery Property . . . . . . . . . . . . . . . . . 95
14.8.1. Example - Retrieving the lockdiscovery Property . . 96 14.8.1. Example - Retrieving the lockdiscovery Property . . 96
14.9. resourcetype Property . . . . . . . . . . . . . . . . . 97 14.9. resourcetype Property . . . . . . . . . . . . . . . . . 97
14.10. supportedlock Property . . . . . . . . . . . . . . . . . 98 14.10. supportedlock Property . . . . . . . . . . . . . . . . . 98
14.10.1. Example - Retrieving the DAV:supportedlock 14.10.1. Example - Retrieving the DAV:supportedlock
Property . . . . . . . . . . . . . . . . . . . . . . 99 Property . . . . . . . . . . . . . . . . . . . . . . 99
15. Precondition/postcondition XML elements . . . . . . . . . . . 100 15. Precondition/postcondition XML elements . . . . . . . . . . . 100
15.1. Example - Response with precondition code . . . . . . . 101
16. Instructions for Processing XML in DAV . . . . . . . . . . . 103 16. Instructions for Processing XML in DAV . . . . . . . . . . . 103
17. DAV Compliance Classes . . . . . . . . . . . . . . . . . . . 104 17. DAV Compliance Classes . . . . . . . . . . . . . . . . . . . 104
17.1. Class 1 . . . . . . . . . . . . . . . . . . . . . . . . 104 17.1. Class 1 . . . . . . . . . . . . . . . . . . . . . . . . 104
17.2. Class 2 . . . . . . . . . . . . . . . . . . . . . . . . 104 17.2. Class 2 . . . . . . . . . . . . . . . . . . . . . . . . 104
17.3. Class 'bis' . . . . . . . . . . . . . . . . . . . . . . 104 17.3. Class 'bis' . . . . . . . . . . . . . . . . . . . . . . 104
18. Internationalization Considerations . . . . . . . . . . . . . 106 18. Internationalization Considerations . . . . . . . . . . . . . 105
19. Security Considerations . . . . . . . . . . . . . . . . . . . 108 19. Security Considerations . . . . . . . . . . . . . . . . . . . 107
19.1. Authentication of Clients . . . . . . . . . . . . . . . 108 19.1. Authentication of Clients . . . . . . . . . . . . . . . 107
19.2. Denial of Service . . . . . . . . . . . . . . . . . . . 108 19.2. Denial of Service . . . . . . . . . . . . . . . . . . . 107
19.3. Security through Obscurity . . . . . . . . . . . . . . . 109 19.3. Security through Obscurity . . . . . . . . . . . . . . . 108
19.4. Privacy Issues Connected to Locks . . . . . . . . . . . 109 19.4. Privacy Issues Connected to Locks . . . . . . . . . . . 108
19.5. Privacy Issues Connected to Properties . . . . . . . . . 109 19.5. Privacy Issues Connected to Properties . . . . . . . . . 108
19.6. Implications of XML Entities . . . . . . . . . . . . . . 110 19.6. Implications of XML Entities . . . . . . . . . . . . . . 109
19.7. Risks Connected with Lock Tokens . . . . . . . . . . . . 111 19.7. Risks Connected with Lock Tokens . . . . . . . . . . . . 110
19.8. Hosting malicious scripts executed on client machines . 111 19.8. Hosting malicious scripts executed on client machines . 110
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 112
21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 114 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 113
21.1. Previous Authors' Addresses . . . . . . . . . . . . . . 115 21.1. Previous Authors' Addresses . . . . . . . . . . . . . . 114
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 116 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 115
22.1. Normative References . . . . . . . . . . . . . . . . . . 116 22.1. Normative References . . . . . . . . . . . . . . . . . . 115
22.2. Informational References . . . . . . . . . . . . . . . . 116 22.2. Informational References . . . . . . . . . . . . . . . . 115
Appendix A. Notes on Processing XML Elements . . . . . . . . . . 118 Appendix A. Notes on Processing XML Elements . . . . . . . . . . 117
A.1. Notes on Empty XML Elements . . . . . . . . . . . . . . 118 A.1. Notes on Empty XML Elements . . . . . . . . . . . . . . 117
A.2. Notes on Illegal XML Processing . . . . . . . . . . . . 118 A.2. Notes on Illegal XML Processing . . . . . . . . . . . . 117
A.3. Example - XML Syntax Error . . . . . . . . . . . . . . . 118 A.3. Example - XML Syntax Error . . . . . . . . . . . . . . . 117
A.4. Example - Unknown XML Element . . . . . . . . . . . . . 119 A.4. Example - Unknown XML Element . . . . . . . . . . . . . 118
Appendix B. Notes on HTTP Client Compatibility . . . . . . . . . 120 Appendix B. Notes on HTTP Client Compatibility . . . . . . . . . 119
Appendix C. The opaquelocktoken scheme and URIs . . . . . . . . 121 Appendix C. The opaquelocktoken scheme and URIs . . . . . . . . 120
Appendix D. Summary of changes from RFC2518 . . . . . . . . . . 122 Appendix D. Guidance for Clients Desiring to Authenticate . . . 121
D.1. Changes Notable to Server Implementors . . . . . . . . . 122 Appendix E. Summary of changes from RFC2518 . . . . . . . . . . 123
D.2. Changes Notable to Client Implementors . . . . . . . . . 123 E.1. Changes Notable to Server Implementors . . . . . . . . . 123
Appendix E. Change Log (to be removed by RFC Editor before E.2. Changes Notable to Client Implementors . . . . . . . . . 124
publication) . . . . . . . . . . . . . . . . . . . . 124 Appendix F. Change Log (to be removed by RFC Editor before
E.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . 124 publication) . . . . . . . . . . . . . . . . . . . . 126
E.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 124 F.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . 126
E.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 125 F.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 126
E.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 126 F.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 127
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 128 F.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 128
Intellectual Property and Copyright Statements . . . . . . . . . 129 F.5. Chandles in -10 . . . . . . . . . . . . . . . . . . . . 129
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 130
Intellectual Property and Copyright Statements . . . . . . . . . 131
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 14, line 40 skipping to change at page 14, line 40
added='2005-11-27'>http://www.example.com</x:uri> added='2005-11-27'>http://www.example.com</x:uri>
<x:notes xmlns:h='http://www.w3.org/1999/xhtml'> <x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
Jane has been working way <h:em>too</h:em> long on the Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <![CDATA[<RFC2518>]]>. long-awaited revision of <![CDATA[<RFC2518>]]>.
</x:notes> </x:notes>
</x:author> </x:author>
</D:prop> </D:prop>
When this property is requested, a server might return: When this property is requested, a server might return:
<author xmlns:x='http://example.com/ns' xml:lang="en" <D:prop><author xmlns:x='http://example.com/ns' xml:lang="en"
xmlns='http://example.com/ns' xmlns='http://example.com/ns'
xmlns:ns1='http://www.w3.org/1999/xhtml'> xmlns:ns1='http://www.w3.org/1999/xhtml'>
<x:name>Jane Doe</name> <x:name>Jane Doe</name>
<x:uri added="2005-11-26" type="email" <x:uri added="2005-11-26" type="email"
>mailto:jane.doe@example.com</uri> >mailto:jane.doe@example.com</x:uri>
<x:uri added="2005-11-27" type="web" <x:uri added="2005-11-27" type="web"
>http://www.example.com</uri> >http://www.example.com</x:uri>
<x:notes> <x:notes>
Jane has been working way <h:em>too</h:em> long on the Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of &lt;RFC2518&gt;. long-awaited revision of &lt;RFC2518&gt;.
</x:notes> </x:notes>
</author> </author>
</D:prop>
Note in this example: Note in this example:
o The [prefix] for the property name itself was not preserved, being o The [prefix] for the property name itself was not preserved, being
non-significant non-significant
o attribute values have been rewritten with double quotes instead of o attribute values have been rewritten with double quotes instead of
single quotes (quoting style is not significant), and attribute single quotes (quoting style is not significant), and attribute
order has not been preserved, order has not been preserved,
o the xml:lang attribute has been returned on the property name o the xml:lang attribute has been returned on the property name
skipping to change at page 20, line 50 skipping to change at page 20, line 50
6.3. Lock Tokens 6.3. Lock Tokens
A lock token is a type of state token, represented as a URI, which A lock token is a type of state token, represented as a URI, which
identifies a particular lock. Each lock has exactly one unique lock identifies a particular lock. Each lock has exactly one unique lock
token generated by the server. Clients MUST NOT attempt to interpret token generated by the server. Clients MUST NOT attempt to interpret
lock tokens in any way. lock tokens in any way.
Lock token URIs MUST be unique across all resources for all time. Lock token URIs MUST be unique across all resources for all time.
This uniqueness constraint allows lock tokens to be submitted across This uniqueness constraint allows lock tokens to be submitted across
resources and servers without fear of confusion. resources and servers without fear of confusion. Since lock tokens
are unique, a client MAY submit a lock token in an If header on a
resource other than the one that returned it.
When a LOCK operation creates a new lock, the new lock token is When a LOCK operation creates a new lock, the new lock token is
returned in the Lock-Token response header defined in Section 9.6, returned in the Lock-Token response header defined in Section 9.5,
and also in the body of the response. and also in the body of the response.
Submitting a lock token does not confer full privilege to use the Submitting a lock token does not confer full privilege to use the
lock token or modify the locked resource. Anyone can find out anyone lock token or modify the locked resource. Write access and other
else's lock token by performing lock discovery. Write access and privileges MUST be enforced through normal privilege or
other privileges MUST be enforced through normal privilege or authentication mechanisms, not based on the possible obscurity of
authentication mechanisms, not based on the slight obscurity of lock lock token values.
token values.
Since lock tokens are unique, a client MAY submit a lock token in an Servers MAY make lock tokens publicly readable (e.g. in the DAV:
If header on a resource other than the one that returned it. lockdiscovery property). One use case for making lock tokens
readable is so that a long-lived lock can be removed by the resource
owner (the client that obtained the lock might have crashed or
disconnected before cleaning up the lock). Except for the case of
using UNLOCK under user guidance, a client SHOULD NOT use a lock
tokens created by another client instance.
This specification encourages servers to create UUIDs for lock This specification encourages servers to create UUIDs for lock
tokens, and to use the URI form defined by "A Universally Unique tokens, and to use the URI form defined by "A Universally Unique
Identifier (UUID) URN Namespace" ([RFC4122]). However servers are Identifier (UUID) URN Namespace" ([RFC4122]). However servers are
free to use any URI (e.g. from another scheme) so long as it meets free to use any URI (e.g. from another scheme) so long as it meets
the uniqueness requirements. For example, a valid lock token might the uniqueness requirements. For example, a valid lock token might
be constructed using the "opaquelocktoken" scheme defined in be constructed using the "opaquelocktoken" scheme defined in
Appendix C. Appendix C.
Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
skipping to change at page 22, line 7 skipping to change at page 22, line 10
access, it is useful for the second principal to be able to find out access, it is useful for the second principal to be able to find out
who the first principal is. For this purpose the DAV:lockdiscovery who the first principal is. For this purpose the DAV:lockdiscovery
property is provided. This property lists all outstanding locks, property is provided. This property lists all outstanding locks,
describes their type, and MAY even provide the lock tokens. describes their type, and MAY even provide the lock tokens.
Any DAV compliant resource that supports the LOCK method MUST support Any DAV compliant resource that supports the LOCK method MUST support
the DAV:lockdiscovery property. the DAV:lockdiscovery property.
6.6. Locks and Multiple Bindings 6.6. Locks and Multiple Bindings
A resource may be made available through more than one URI. However A resource may be made available through more than one URI. A lock
locks apply to resources, not URIs. Therefore a LOCK request on a MUST cover the resource as well as the URI to which the LOCK request
resource MUST NOT succeed if can not be honored by all the URIs was addressed. The lock MAY cover other URIs mapped to the same
through which the resource is addressable. resource as well.
7. Write Lock 7. Write Lock
This section describes the semantics specific to the write lock type. This section describes the semantics specific to the write lock type.
The write lock is a specific instance of a lock type, and is the only The write lock is a specific instance of a lock type, and is the only
lock type described in this specification. lock type described in this specification.
An exclusive write lock will prevent parallel changes to a resource An exclusive write lock will prevent parallel changes to a resource
by any principal other than the write lock holder. In general terms, by any principal other than the write lock holder. In general terms,
changes affected by write locks include changes to: changes affected by write locks include changes to:
skipping to change at page 23, line 50 skipping to change at page 23, line 50
If an anonymous user requests a lock, the server MAY refuse the If an anonymous user requests a lock, the server MAY refuse the
request. request.
7.2. Methods Restricted by Write Locks 7.2. Methods Restricted by Write Locks
A server MUST reject any write request that alters a write-locked A server MUST reject any write request that alters a write-locked
resource unless a valid lock token is provided. The write operations resource unless a valid lock token is provided. The write operations
defined in HTTP and WebDAV are PUT, POST, PROPPATCH, LOCK, UNLOCK, defined in HTTP and WebDAV are PUT, POST, PROPPATCH, LOCK, UNLOCK,
MOVE, COPY (for the destination resource), DELETE, and MKCOL. All MOVE, COPY (for the destination resource), DELETE, and MKCOL. All
other HTTP/WebDAV methods, GET in particular, function independently other HTTP/WebDAV methods, GET in particular, function independently
of the lock. A shared write lock prevents the same operations, of the lock. A shared write lock prevents the same operations
however it also allows access by any principal that has a shared (except additional requests for shared write locks), however it also
write lock on the same resource. allows access by any principal that has a shared write lock on the
same resource.
Note, however, that as new methods are created it will be necessary Note, however, that as new methods are created it will be necessary
to specify how they interact with a write lock. to specify how they interact with a write lock.
7.3. Write Locks and Lock Tokens 7.3. Write Locks and Lock Tokens
A successful request for an exclusive or shared write lock MUST A successful request for an exclusive or shared write lock MUST
result in the generation of a unique lock token associated with the result in the generation of a unique lock token associated with the
requesting principal. Thus if five principals have a shared write requesting principal. Thus if five principals have a shared write
lock on the same resource there will be five lock tokens, one for lock on the same resource there will be five lock tokens, one for
skipping to change at page 25, line 23 skipping to change at page 25, line 25
HTTP 1.1 clients can be good citizens, avoiding overwriting other HTTP 1.1 clients can be good citizens, avoiding overwriting other
clients' changes, by using entity tags in If-Match headers with any clients' changes, by using entity tags in If-Match headers with any
requests that would modify resources. requests that would modify resources.
Information managers may attempt to prevent overwrites by Information managers may attempt to prevent overwrites by
implementing client-side procedures requiring locking before implementing client-side procedures requiring locking before
modifying WebDAV resources. modifying WebDAV resources.
7.6. Write Locks and Unmapped URLs 7.6. Write Locks and Unmapped URLs
It is possible to lock an unmapped URL in order to lock the name for WebDAV provides the ability to lock an unmapped URL in order to
use. This is a simple way to avoid the lost-update problem on the reserve the name for use. This is a simple way to avoid the lost-
creation of a new resource (another way is to use If-None-Match update problem on the creation of a new resource (another way is to
header specified in HTTP 1.1). It has the side benefit of locking use If-None-Match header specified in HTTP 1.1). It has the side
the new resource immediately for use of the creator. benefit of locking the new resource immediately for use of the
creator.
The lost-update problem is not an issue for collections because MKCOL Note that the lost-update problem is not an issue for collections
can only be used to create a collection, not to overwrite an existing because MKCOL can only be used to create a collection, not to
collection. When trying to lock a collection upon creation, clients overwrite an existing collection. When trying to lock a collection
may attempt to increase the likelihood of getting the lock by upon creation, clients may attempt to increase the likelihood of
pipelining the MKCOL and LOCK requests together (but because this getting the lock by pipelining the MKCOL and LOCK requests together
doesn't convert two separate operations into one atomic operation (but because this doesn't convert two separate operations into one
there's no guarantee this will work). atomic operation there's no guarantee this will work).
A successful lock request to an unmapped URL MUST result in the A successful lock request to an unmapped URL MUST result in the
creation of an locked resource with empty content. Subsequently, a creation of an locked resource with empty content. Subsequently, a
successful PUT request (with the correct lock token) provides the successful PUT request (with the correct lock token) provides the
content for the resource, and the server MUST also use the content- content for the resource, and the server MUST also use the content-
type and content-language information from this request. type and content-language information from this request.
In this situation, a WebDAV server that was implemented from The original WebDAV model for locking unmapped URLs created "lock-
[RFC2518] MAY create "lock-null" resources which are special and null resources". This model was over-complicated and some
unusual resources. Historically, a lock-null resource: interoperability and implementation problems were discovered. The
new WebDAV model for locking unmapped URLs creates "locked empty
resources". Servers MUST implement either lock-null resources or
locked empty resources, but servers SHOULD implement locked empty
resources. This section discusses the original model briefly and the
new model more completely, because clients MUST be able to handle
either model.
o Responds with a 404 or 405 to any DAV method except for PUT, In the original "lock-null resource" model, which is no longer
recommended for implementation:
o A lock-null resource sometimes appeared as "Not Found". The
server responds with a 404 or 405 to any method except for PUT,
MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK. MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
o Appears as a member of its parent collection. o A lock-null resource does however show up as a member of its
parent collection.
o Disappears (URI becomes unmapped) if its lock goes away before it o The server removes the lock-null resource entirely (its URI
is converted to a regular resource. (This must also happen if it becomes unmapped) if its lock goes away before it is converted to
is renamed or moved, or if any parent collection is renamed or a regular resource. Recall that locks go away not only when they
moved, because locks are tied to URLs). expire or are unlcoked, but are also removed if a resource is
renamed or moved, or if any parent collection is renamed or moved.
o May be turned into a regular resource when a PUT request to the o The server converts the lock-null resource into a regular resource
URL is successful. Ceases to be a lock-null resource. if a PUT request to the URL is successful.
o May be turned into a collection when a MKCOL request to the URL is o The server converts the lock-null resource into a collection if a
successful. Ceases to be a lock-null resource. MKCOL request to the URL is successful (though interoperability
experience showed that not all servers followed this requirement).
o Has defined values for DAV:lockdiscovery and DAV:supportedlock o Property values were defined for DAV:lockdiscovery and DAV:
properties. supportedlock properties but not necessarily for other properties
like DAV:getcontenttype.
However, interoperability and compliance problems have been found In the "locked empty resource" model, which is now the recommended
with lock-null resources. Therefore, they are deprecated. WebDAV implementation, a resource created with a LOCK is empty but otherwise
servers SHOULD create regular locked empty resources, which are and behaves in every way as a normal resource. A locked empty resource:
behave in every way as normal resources. A locked empty resource:
o Can be read, deleted, moved, copied, and in all ways behave as a o Can be read, deleted, moved, copied, and in all ways behave as a
regular resource, not a lock-null resource. regular resource, not a lock-null resource.
o Appears as a member of its parent collection. o Appears as a member of its parent collection.
o SHOULD NOT disappear when its lock goes away (clients must o SHOULD NOT disappear when its lock goes away (clients must
therefore be responsible for cleaning up their own mess, as with therefore be responsible for cleaning up their own mess, as with
any other operation) any other operation or any non-empty resource)
o SHOULD default to having no content type. o SHOULD default to having no content type.
o MAY NOT have values for properties like DAV:getcontentlanguage o MAY NOT have values for properties like DAV:getcontentlanguage
which haven't been specified yet by the client. which haven't been specified yet by the client.
o May have content added with a PUT request. MUST be able to change o Can be updated (have content added) with a PUT request. The
content type. server MUST be able to set the content type as specified in the
PUT request.
o MUST NOT be turned into a collection. A MKCOL request must fail o MUST NOT be converted into a collection. The server MUST fail a
as it would to any existing resource. MKCOL request (as it would with a MKCOL request to any existing
non-collection resource).
o MUST have defined values for DAV:lockdiscovery and DAV: o MUST have defined values for DAV:lockdiscovery and DAV:
supportedlock properties. supportedlock properties.
o The response MUST indicate that a resource was created, by use of o The response MUST indicate that a resource was created, by use of
the "201 Created" response code (a LOCK request to an existing the "201 Created" response code (a LOCK request to an existing
resource instead will result in 200 OK). The body must still resource instead will result in 200 OK). The body must still
include the DAV:lockdiscovery property, as with a LOCK request to include the DAV:lockdiscovery property, as with a LOCK request to
an existing resource. an existing resource.
The client is expected to update the locked empty resource shortly The client is expected to update the locked empty resource shortly
after locking it, using PUT and possibly PROPPATCH. When the client after locking it, using PUT and possibly PROPPATCH. When the client
uses PUT to overwrite a locked empty resource the client MUST supply uses PUT to overwrite a locked empty resource the client MUST supply
a Content-Type if any is known. If the client supplies a Content- a Content-Type if any is known. If the client supplies a Content-
Type value the server MUST set that value (this requirement actually Type value the server MUST set that value (this requirement actually
applies to any resource that is overwritten but is particularly applies to any resource that is overwritten but is particularly
necessary for locked empty resources which are initially created with necessary for locked empty resources which are initially created with
no Content-Type. no Content-Type).
Clients can easily interoperate both with servers that support the Clients can easily interoperate both with servers that support the
deprecated lock-null resources and servers that support simpler old model "lock-null resources" and the recommended model of "locked
locked empty resources by only attempting PUT after a LOCK to an empty resources" by only attempting PUT after a LOCK to an unmapped
unmapped URL, not MKCOL or GET. URL, not MKCOL or GET.
7.7. Write Locks and Collections 7.7. Write Locks and Collections
A write lock on a collection, whether created by a "Depth: 0" or A write lock on a collection, whether created by a "Depth: 0" or
"Depth: infinity" lock request, prevents the addition or removal of "Depth: infinity" lock request, prevents the addition or removal of
member URLs of the collection by non-lock owners. member URLs of the collection by non-lock owners.
A zero-depth lock on a collection affects changes to the direct A zero-depth lock on a collection affects changes to the direct
membership of that collection. When a principal issues a write membership of that collection. When a principal issues a write
request to create a new resource in a write locked collection, or request to create a new resource in a write locked collection, or
skipping to change at page 29, line 40 skipping to change at page 30, line 13
layer. layer.
7.9. Write Locks and COPY/MOVE 7.9. 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 "Depth: infinity",
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, the resource is subject the write lock with the resource. However, if there is an existing
to being added to an existing lock at the destination (see lock at the destination, the server MUST add the moved resource to
Section 7.7). For example, if the MOVE makes the resource a child of the destination lock scope. For example, if the MOVE makes the
a collection that is locked with "Depth: infinity", then the resource resource a child of a collection that is locked with "Depth:
will be added to that collection's lock. Additionally, if a resource infinity", then the resource will be added to that collection's lock.
locked with "Depth: infinity" is moved to a destination that is Additionally, if a resource locked with "Depth: infinity" is moved to
within the scope of the same lock (e.g., within the URL namespace a destination that is within the scope of the same lock (e.g., within
tree covered by the lock), the moved resource will again be a added the URL namespace tree covered by the lock), the moved resource will
to the lock. In both these examples, as specified in Section 7.8, an again be a added to the lock. In both these examples, as specified
If header must be submitted containing a lock token for both the in Section 7.8, an If header must be submitted containing a lock
source and destination. token for both the source and destination.
7.10. Refreshing Write Locks 7.10. 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 method with an If header but However, a client may submit a LOCK method with an If header but
without a body. This form of LOCK MUST only be used to "refresh" a without a body. This form of LOCK MUST only be used to "refresh" a
skipping to change at page 31, line 46 skipping to change at page 31, line 46
extension) that the body could not be processed as they intended. extension) that the body could not be processed as they intended.
8.1.3. HTTP Headers for use in WebDAV 8.1.3. HTTP Headers for use in WebDAV
HTTP defines many headers that can be used in WebDAV requests and HTTP defines many headers that can be used in WebDAV requests and
responses. Not all of these are appropriate in all situations and responses. Not all of these are appropriate in all situations and
some interactions may be undefined. Note that HTTP 1.1 requires the some interactions may be undefined. Note that HTTP 1.1 requires the
Date header in all responses if possible (see section 14.18, Date header in all responses if possible (see section 14.18,
[RFC2616]). [RFC2616]).
The server MUST do authorization checks before checking any HTTP
conditional header.
8.1.4. ETag 8.1.4. ETag
HTTP 1.1 recommends the use of the ETag header in responses to GET HTTP 1.1 recommends the use of the ETag header in responses to GET
and PUT requests. Correct use of ETags is even more important in a and PUT requests. Correct use of ETags is even more important in a
distributed authoring environment, because ETags are necessary along distributed authoring environment, because ETags are necessary along
with locks to avoid the lost-update problem. A client might fail to with locks to avoid the lost-update problem. A client might fail to
renew a lock, for example when the lock times out and the client is renew a lock, for example when the lock times out and the client is
accidentally offline or in the middle of a long upload. When a accidentally offline or in the middle of a long upload. When a
client fails to renew the lock, it's quite possible the resource can client fails to renew the lock, it's quite possible the resource can
still be relocked and the user can go on editing, as long as no still be relocked and the user can go on editing, as long as no
changes were made in the meantime. ETags are required for the client changes were made in the meantime. ETags are required for the client
to be able to distinguish this case. Otherwise, the client is forced to be able to distinguish this case. Otherwise, the client is forced
to ask the user whether to overwrite the resource on the server to ask the user whether to overwrite the resource on the server
without even being able to tell the user whether it has changed. without even being able to tell the user whether it has changed.
Timestamps do not solve this problem nearly as well as ETags. Timestamps do not solve this problem nearly as well as ETags.
WebDAV servers SHOULD support strong ETags for all resources that may WebDAV servers SHOULD support strong ETags for all resources that may
be PUT. If ETags are supported for a resource, the server MUST be PUT. If ETags are supported for a resource, the server MUST
return the ETag header in all PUT and GET responses to that resource, return the ETag header in all PUT and GET responses to that resource.
as well as provide the same value for the DAV:getetag property.
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 DAV:getlastmodified value) for a resource that has an ETag (or the Last-Modified time) for a resource that has an unchanged
unchanged body. 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.1.5. Including error response bodies 8.1.5. 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 DeltaV introduced a mechanism to
include more specific information in the body of an error response include more specific information in the body of an error response
(section 1.6 of [RFC3253]). The mechanism is appropriate to use with (section 1.6 of [RFC3253]). The error body mechanism is appropriate
any error response that may take a body but does not already have a to use with any error response that may take a body but does not
body defined. The mechanism is particularly appropriate when a already have a body defined. The mechanism is particularly
status code can mean many things (for example, 400 Bad Request can appropriate when a status code can mean many things (for example, 400
mean required headers are missing, headers are incorrectly formatted, Bad Request can mean required headers are missing, headers are
or much more). incorrectly formatted, or much more). This error body mechanism is
covered in Section 15
This mechanism does not take the place of using a correct numeric
error code as defined here or in HTTP, because the client MUST always
be able to take a reasonable course of action based only on the
numeric error. However, it does remove the need to define new
numeric error codes, avoiding the confusion of who is allowed to
define such new codes. The codes used in this mechanism are XML
elements in a namespace, so naturally any group defining a new error
code can use their own namespace. As always, the "DAV:" namespace is
reserved for use by IETF-chartered WebDAV working groups.
A server supporting "bis" SHOULD include a specific XML error code in
a "DAV:error" response body element, when a specific XML error code
is defined in this document. The DAV:error element may contain
multiple elements describing specific errors. For error conditions
not specified in this document, the server MAY simply choose an
appropriate numeric status and leave the response body blank.
8.1.5.1. Example - Response with precondition code
>>Response
HTTP/1.1 403 Forbidden
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:no-external-entities/>
</D:error>
In this specification, both the numeric and the XML error code are
defined for some failure situations, in which case the XML error code
must have the "DAV:" namespace, appear in the "error" root element,
and be returned in a body with the numeric error code specified.
8.2. PROPFIND 8.2. PROPFIND
The PROPFIND method retrieves properties defined on the resource The PROPFIND method retrieves properties defined on the resource
identified by the Request-URI, if the resource does not have any identified by the Request-URI, if the resource does not have any
internal members, or on the resource identified by the Request-URI internal members, or on the resource identified by the Request-URI
and potentially its member resources, if the resource is a collection and potentially its member resources, if the resource is a collection
that has internal member URLs. All DAV compliant resources MUST that has internal member URLs. All DAV compliant resources MUST
support the PROPFIND method and the propfind XML element support the PROPFIND method and the propfind XML element
(Section 13.20) along with all XML elements defined for use with that (Section 13.20) along with all XML elements defined for use with that
skipping to change at page 35, line 7 skipping to change at page 34, line 23
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.
The results of this method SHOULD NOT be cached. The results of this method SHOULD NOT be cached.
8.2.1. PROPFIND status codes 8.2.1. PROPFIND status codes
A server MAY fail an entire PROPFIND request with an appropriate This section, as with similar sections for other methods, provides
status code and MAY redirect the entire request. In addition, the some guidance on error codes and preconditions or postconditions
following error codes are specifically defined for PROPFIND requests: (defined in Section 15) that might be particularly useful with
PROPFIND.
403 Forbidden - A server MAY reject all PROPFIND requests on 403 Forbidden - A server MAY reject all PROPFIND requests on
collections with depth header of "Infinity", in which case it SHOULD collections with depth header of "Infinity", in which case it SHOULD
use this error with the precondition code 'propfind-finite-depth' use this error with the precondition code 'propfind-finite-depth'
inside the error body. inside the error body.
8.2.2. Status codes for use with 207 (Multi-Status) 8.2.2. Status codes for use with 207 (Multi-Status)
The following status codes are defined for use within the PROPFIND The following status codes are defined for use within the PROPFIND
Multi-Status response: Multi-Status response:
skipping to change at page 40, line 36 skipping to change at page 40, line 36
<D:response> <D:response>
<D:href>/container/front.html</D:href> <D:href>/container/front.html</D:href>
<D:propstat> <D:propstat>
<D:prop xmlns:R="http://www.foo.bar/boxschema/"> <D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox><R:BoxType>Box type B</R:BoxType> <R:bigbox><R:BoxType>Box type B</R:BoxType>
</R:bigbox> </R:bigbox>
<D:creationdate>1997-12-01T18:27:21-08:00</D:creationdate> <D:creationdate>1997-12-01T18:27:21-08:00</D:creationdate>
<D:displayname>Example HTML resource</D:displayname> <D:displayname>Example HTML resource</D:displayname>
<D:getcontentlength>4525</D:getcontentlength> <D:getcontentlength>4525</D:getcontentlength>
<D:getcontenttype>text/html</D:getcontenttype> <D:getcontenttype>text/html</D:getcontenttype>
<D:getetag>zzyzx</D:getetag> <D:getetag>"zzyzx"</D:getetag>
<D:getlastmodified <D:getlastmodified
>Monday, 12-Jan-98 09:25:56 GMT</D:getlastmodified> >Monday, 12-Jan-98 09:25:56 GMT</D:getlastmodified>
<D:resourcetype/> <D:resourcetype/>
<D:supportedlock> <D:supportedlock>
<D:lockentry> <D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope> <D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype> <D:locktype><D:write/></D:locktype>
</D:lockentry> </D:lockentry>
<D:lockentry> <D:lockentry>
<D:lockscope><D:shared/></D:lockscope> <D:lockscope><D:shared/></D:lockscope>
skipping to change at page 47, line 33 skipping to change at page 47, line 33
consistent URL namespace. consistent URL namespace.
If an error occurs deleting an internal resource (a resource other If an error occurs deleting an internal resource (a resource other
than the resource identified in the Request-URI) then the response than the resource identified in the Request-URI) then the response
can be a 207 (Multi-Status). Multi-Status is used here to indicate can be a 207 (Multi-Status). Multi-Status is used here to indicate
which internal resources could NOT be deleted, including an error which internal resources could NOT be deleted, including an error
code which should help the client understand which resources caused code which should help the client understand which resources caused
the failure. For example, the Multi-Status body could include a the failure. For example, the Multi-Status body could include a
response with status 423 (Locked) if an internal resource was locked. response with status 423 (Locked) if an internal resource was locked.
The server MAY return a 4xx status response, rather than a Multi- The server MAY return a 4xx status response, rather than a 207, if
Status, if the request failed. the request failed completely.
424 (Failed Dependency) status codes SHOULD NOT be in the 207 (Multi- 424 (Failed Dependency) status codes SHOULD NOT be in the 207 (Multi-
Status) response for DELETE. They can be safely left out because the Status) response for DELETE. They can be safely left out because the
client will know that the ancestors of a resource could not be client will know that the ancestors of a resource could not be
deleted when the client receives an error for the ancestor's progeny. deleted when the client receives an error for the ancestor's progeny.
Additionally 204 (No Content) errors SHOULD NOT be returned in the Additionally 204 (No Content) errors SHOULD NOT be returned in the
207 (Multi-Status). The reason for this prohibition is that 204 (No 207 (Multi-Status). The reason for this prohibition is that 204 (No
Content) is the default success code. Content) is the default success code.
8.7.2. Example - DELETE 8.7.2. Example - DELETE
skipping to change at page 49, line 11 skipping to change at page 49, line 11
treated as an error (405 Method Not Allowed). treated as an error (405 Method Not Allowed).
The MKCOL method is defined to create collections. The MKCOL method is defined to create collections.
8.9. COPY 8.9. COPY
The COPY method creates a duplicate of the source resource identified The COPY method creates a duplicate of the source resource identified
by the Request-URI, in the destination resource identified by the URI by the Request-URI, in the destination resource identified by the URI
in the Destination header. The Destination header MUST be present. in the Destination header. The Destination header MUST be present.
The exact behavior of the COPY method depends on the type of the The exact behavior of the COPY method depends on the type of the
source resource. The state of the resource to be copied is fixed at source resource.
the point the server begins processing the COPY request.
All WebDAV compliant resources MUST support the COPY method. All WebDAV compliant resources MUST support the COPY method.
However, support for the COPY method does not guarantee the ability However, support for the COPY method does not guarantee the ability
to copy a resource. For example, separate programs may control to copy a resource. For example, separate programs may control
resources on the same server. As a result, it may not be possible to resources on the same server. As a result, it may not be possible to
copy a resource to a location that appears to be on the same server. copy a resource to a location that appears to be on the same server.
8.9.1. COPY for Non-collection Resources 8.9.1. COPY for Non-collection Resources
When the source resource is not a collection the result of the COPY When the source resource is not a collection the result of the COPY
skipping to change at page 50, line 17 skipping to change at page 50, line 17
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 A COPY of depth infinity 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. recursively through all levels of the collection hierarchy. Note
that a depth infinity COPY of /A/ into /A/B/ could lead to infinite
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
Request-URI. When applied to members of the collection identified by Request-URI. When applied to members of the collection identified by
skipping to change at page 51, line 27 skipping to change at page 51, line 28
default success codes. default success codes.
8.9.4. COPY and Overwriting Destination Resources 8.9.4. COPY and Overwriting Destination Resources
If a COPY request has an Overwrite header with a value of "F", and a If a COPY request has an Overwrite header with a value of "F", and a
resource exists at the Destination URL, the server MUST fail the resource exists at the Destination URL, the server MUST fail the
request. request.
When a server executes a COPY request and overwrites a destination When a server executes a COPY request and overwrites a destination
resource, the exact behavior MAY depend on many factors, including resource, the exact behavior MAY depend on many factors, including
WebDAV extension capabilities (see particularly [RFC3253]). Some WebDAV extension capabilities (see particularly [RFC3253]). For
considerations: example, when an ordinary resource is overwritten, the server could
delete the target resource before doing the copy, or could do an in-
When an ordinary resource is overwritten, the server could delete place overwrite to preserve live properties.
the target resource before doing the copy, or could do an in-place
overwrite to preserve live properties.
When a collection is overwritten, the source collection membership When a collection is overwritten, the membership of the destination
could completely replace the destination collection membership, or collection after the successful COPY request MUST be the same
the source collection membership could be combined with the membership as the source collection immediately before the COPY.
destination collection membership. Thus, merging the membership of the source and destination
collections together in the destination is not a compliant behavior.
In general, if clients require the state of the destination URL to be In general, if clients require the state of the destination URL to be
wiped out prior to a COPY (e.g. to force live properties to be reset wiped out prior to a COPY (e.g. to force live properties to be
or to force collection membership to be reset), then the client could reset), then the client could send a DELETE to the destination before
send a DELETE to the destination before the COPY request to ensure the COPY request to ensure this reset.
this reset.
8.9.5. Status Codes 8.9.5. Status Codes
In addition to the general status codes possible, the following In addition to the general status codes possible, the following
status codes have specific applicability to COPY: status codes have specific applicability to COPY:
201 (Created) - The source resource was successfully copied. The 201 (Created) - The source resource was successfully copied. The
COPY operation resulted in the creation of a new resource. COPY operation resulted in the creation of a new resource.
204 (No Content) - The source resource was successfully copied to a 204 (No Content) - The source resource was successfully copied to a
skipping to change at page 68, line 20 skipping to change at page 68, line 20
commas. WebDAV adds two new conditional headers to the set defined commas. WebDAV adds two new conditional headers to the set defined
in HTTP: the If and Overwrite headers. in HTTP: the If and Overwrite headers.
9.1. DAV Header 9.1. DAV Header
DAV = "DAV" ":" #( compliance-class ) DAV = "DAV" ":" #( compliance-class )
compliance-class = ( "1" | "2" | "bis" | extend ) compliance-class = ( "1" | "2" | "bis" | extend )
extend = Coded-URL | token extend = Coded-URL | token
Coded-URL = "<" absolute-URI ">" Coded-URL = "<" absolute-URI ">"
; No LWS allowed in Coded-URL ; No LWS allowed in Coded-URL
; 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. "1" on all OPTIONS responses.
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
Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can
appear in any order. Identifiers that are standardized through the appear in any order. Identifiers that are standardized through the
skipping to change at page 70, line 24 skipping to change at page 70, line 26
The Destination request header specifies the URI which identifies a The Destination request header specifies the URI which identifies a
destination resource for methods such as COPY and MOVE, which take destination resource for methods such as COPY and MOVE, which take
two URIs as parameters. Note that the absolute-URI production is two URIs as parameters. Note that the absolute-URI production is
defined in [RFC3986]. defined in [RFC3986].
If the Destination value is an absolute URI, it may name a different If the Destination value is an absolute URI, it may name a different
server (or different port or scheme). If the source server cannot server (or different port or scheme). If the source server cannot
attempt a copy to the remote server, it MUST fail the request with a attempt a copy to the remote server, it MUST fail the request with a
502 (Bad Gateway) response. 502 (Bad Gateway) response.
9.4. Force-Authentication Header 9.4. If Header
Force-Authentication = "Force-Authentication" ":" Method
The Force-Authentication request header is used with the OPTIONS
method to specify that the client wants to be challenged for
authentication credentials to the resource identified by the Request-
URI. If present on a request to a WebDAV-compliant resource, the
server MUST respond with either 401 (Unauthorized) or 501 (Not
Implemented) status code. The Method value is used for the client to
indicate what method it intends to use first on the resource
identified in the Request-URI.
9.5. If Header
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
No-tag-list = List No-tag-list = List
Tagged-list = Resource 1*List Tagged-list = Resource 1*List
Resource = Coded-URL Resource = Coded-URL
List = #( "(" List | Clause ")" ) List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
Clause = ["Not"] State-token | State-token ; No LWS allowed between "[", entity-tag and "]"
State-token = Coded-URL | "[" entity-tag "]" State-token = Coded-URL
The If request header is intended to have similar functionality to The If request header is intended to have similar functionality to
the If-Match header defined in section 14.24 of [RFC2616]. However the If-Match header defined in section 14.24 of [RFC2616]. However
the If header is intended for use with any URI which represents state the If header is intended for use with any URI which represents state
information, referred to as a state token, about a resource as well information, referred to as a state token, about a resource as well
as ETags. A typical example of a state token is a lock token, and as ETags. A typical example of a state token is a lock token, and
lock tokens are the only state tokens defined in this specification. lock tokens are the only state tokens defined in this specification.
The <DAV:no-lock> state token is an example of a state token that The <DAV:no-lock> state token is an example of a state token that
will never match an actual valid lock token. The purpose of this is will never match an actual valid lock token. The purpose of this is
described in Section 9.5.4. described in Section 9.4.4.
The If header's purpose is to describe a series of state lists. If The If header's purpose is to describe a series of state lists. If
the state of the resource to which the header is applied does not the state of the resource to which the header is applied does not
match any of the specified state lists then the request MUST fail match any of the specified state lists then the request MUST fail
with a 412 (Precondition Failed). If one of the described state with a 412 (Precondition Failed). If one of the described state
lists matches the state of the resource then the request may succeed. lists matches the state of the resource then the request may succeed.
The server must parse the If header when it appears on any request, The server MUST do authorization checks before checking this or any
evaluate all the clauses, and if the conditional evaluates to false, conditional header. Assuming no other errors, the server MUST parse
fail the request. the If header when it appears on any request, evaluate all the
clauses, and if the conditional evaluates to false, fail as described
Note that the absolute-URI production is defined in [RFC3986]. above.
9.5.1. No-tag-list Production 9.4.1. No-tag-list Production
The No-tag-list production describes a series of state tokens and The No-tag-list production describes a series of state tokens and
ETags. If multiple No-tag-list productions are used then one only ETags. If multiple No-tag-list productions are used then one only
needs to match the state of the resource for the method to be allowed needs to match the state of the resource for the method to be allowed
to continue. All untagged tokens apply to the resource identified in to continue. All untagged tokens apply to the resource identified in
the Request-URI. the Request-URI.
Example - no-tag-list production Example - no-tag-list production
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
["I am an ETag"]) (["I am another ETag"]) ["I am an ETag"]) (["I am another ETag"])
The previous header would require that the resource identified in the The previous header would require that the resource identified in the
Request-URI be locked with the specified lock token and in the state Request-URI be locked with the specified lock token and in the state
identified by the "I am an ETag" ETag or in the state identified by identified by the "I am an ETag" ETag or in the state identified by
the second ETag "I am another ETag". To put the matter more plainly the second ETag "I am another ETag". To put the matter more plainly
one can think of the previous If header as being in the form (or (and one can think of the previous If header as being in the form (or (and
<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> ["I am an ETag"]) <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> ["I am an ETag"])
(and ["I am another ETag"])). (and ["I am another ETag"])).
9.5.2. Tagged-list Production 9.4.2. Tagged-list Production
The tagged-list production may be used instead of the no-tag-list The tagged-list production may be used instead of the no-tag-list
production, in order to scope each token to a specific resource. production, in order to scope each token to a specific resource.
That is, it specifies that the lists following the resource That is, it specifies that the lists following the resource
specification only apply to the specified resource. The scope of the specification only apply to the specified resource. The scope of the
resource production begins with the list production immediately resource production begins with the list production immediately
following the resource production and ends with the next resource following the resource production and ends with the next resource
production, if any. All clauses must be evaluated. If the state of production, if any. All clauses must be evaluated. If the state of
the resource named in the tag does not match any of the associated the resource named in the tag does not match any of the associated
state lists then the request MUST fail with a 412 (Precondition state lists then the request MUST fail with a 412 (Precondition
Failed). Failed).
The same URI MUST NOT appear more than once in a resource production The same URI MUST NOT appear more than once in a resource production
in an If header. in an If header.
9.5.3. Example - Tagged List If header in COPY 9.4.3. Example - Tagged List If header in COPY
>>Request >>Request
COPY /resource1 HTTP/1.1 COPY /resource1 HTTP/1.1
Host: www.example.com Host: www.example.com
Destination: http://www.example.com/resource2 Destination: http://www.example.com/resource2
If: <http://www.example.com/resource1> If: <http://www.example.com/resource1>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
[W/"A weak ETag"]) (["strong ETag"]) [W/"A weak ETag"]) (["strong ETag"])
<http://www.example.com/random> <http://www.example.com/random>
skipping to change at page 72, line 37 skipping to change at page 72, line 32
weak ETag"]) (["strong ETag"])", that is, it either must be locked weak ETag"]) (["strong ETag"])", that is, it either must be locked
with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2" with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2"
and have a weak entity tag W/"A weak ETag" or it must have a strong and have a weak entity tag W/"A weak ETag" or it must have a strong
entity tag "strong ETag". entity tag "strong ETag".
That is the only success condition since the resource That is the only success condition since the resource
http://www.example.com/random never has the method applied to it (the http://www.example.com/random never has the method applied to it (the
only other resource listed in the If header) and only other resource listed in the If header) and
http://www.example.com/resource2 is not listed in the If header. http://www.example.com/resource2 is not listed in the If header.
9.5.4. Not Production 9.4.4. Not Production
Every state token or ETag is either current, and hence describes the Every state token or ETag is either current, and hence describes the
state of a resource, or is not current, and does not describe the state of a resource, or is not current, and does not describe the
state of a resource. The boolean operation of matching a state token state of a resource. The boolean operation of matching a state token
or ETag to the current state of a resource thus resolves to a true or or ETag to the current state of a resource thus resolves to a true or
false value. The "Not" production is used to reverse that value. false value. The "Not" production is used to reverse that value.
The scope of the not production is the state-token or entity-tag The scope of the not production is the state-token or entity-tag
immediately following it. immediately following it.
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>) <urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
When submitted with a request, this If header requires that all When submitted with a request, this If header requires that all
operand resources must not be locked with operand resources must not be locked with
urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked with urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked with
urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092. urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.
The Not production is particularly useful with the "<DAV:no-lock>" The Not production is particularly useful with a state token known
state token. The clause "Not <DAV:no-lock>" MUST evaluate to true. not to ever identify a lock, such as the "<DAV:no-lock>" state token.
Thus, any "OR" statement containing the clause "Not <DAV:no-lock>" The clause "Not <DAV:no-lock>" MUST evaluate to true. Thus, any "OR"
MUST also evaluate to true. statement containing the clause "Not <DAV:no-lock>" MUST also
evaluate to true.
9.5.5. Matching Function 9.4.5. Matching Function
When performing If header processing, the definition of a matching When performing If header processing, the definition of a matching
state token or entity tag is as follows. state token or entity tag is as follows.
Identifying a resource: The resource is identified by the URI along Identifying a resource: The resource is identified by the URI along
with the token, in tagged list production, or by the Request-URI in with the token, in tagged list production, or by the Request-URI in
untagged list production. untagged list production.
Matching entity tag: Where the entity tag matches an entity tag Matching entity tag: Where the entity tag matches an entity tag
associated with the identified resource. associated with the identified resource.
skipping to change at page 73, line 47 skipping to change at page 73, line 42
resource, which is the 'specs' collection identified by the URL in resource, which is the 'specs' collection identified by the URL in
the tagged list production. If the 'specs' collection is not locked the tagged list production. If the 'specs' collection is not locked
or has a lock with a different token, the request MUST fail. If the or has a lock with a different token, the request MUST fail. If the
'specs' collection is locked (depth infinity) with that lock token, 'specs' collection is locked (depth infinity) with that lock token,
then this request could succeed, both because the If header evaluates then this request could succeed, both because the If header evaluates
to true, and because the lock token for the lock affecting the to true, and because the lock token for the lock affecting the
affected resource has been provided. Alternatively, a request where affected resource has been provided. Alternatively, a request where
the 'rfc2518.txt' URL is associated with the lock token in the If the 'rfc2518.txt' URL is associated with the lock token in the If
header could also succeed. header could also succeed.
9.5.6. If Header and Non-DAV Aware Proxies 9.4.6. If Header and Non-DAV Aware Proxies
Non-DAV aware proxies will not honor the If header, since they will Non-DAV aware proxies will not honor the If header, since they will
not understand the If header, and HTTP requires non-understood not understand the If header, and HTTP requires non-understood
headers to be ignored. When communicating with HTTP/1.1 proxies, the headers to be ignored. When communicating with HTTP/1.1 proxies, the
"Cache-Control: no-cache" request header MUST be used so as to "Cache-Control: no-cache" request header MUST be used so as to
prevent the proxy from improperly trying to service the request from prevent the proxy from improperly trying to service the request from
its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache"
request header MUST be used for the same reason. request header MUST be used for the same reason.
9.6. Lock-Token Header 9.5. Lock-Token Header
Lock-Token = "Lock-Token" ":" Coded-URL Lock-Token = "Lock-Token" ":" Coded-URL
The Lock-Token request header is used with the UNLOCK method to The Lock-Token request header is used with the UNLOCK method to
identify the lock to be removed. The lock token in the Lock-Token identify the lock to be removed. The lock token in the Lock-Token
request header MUST identify a lock that contains the resource request header MUST identify a lock that contains the resource
identified by Request-URI as a member. identified by Request-URI as a member.
The Lock-Token response header is used with the LOCK method to The Lock-Token response header is used with the LOCK method to
indicate the lock token created as a result of a successful LOCK indicate the lock token created as a result of a successful LOCK
request to create a new lock. request to create a new lock.
9.7. Overwrite Header 9.6. Overwrite Header
Overwrite = "Overwrite" ":" ("T" | "F") Overwrite = "Overwrite" ":" ("T" | "F")
The Overwrite request header specifies whether the server should The Overwrite request header specifies whether the server should
overwrite a resource mapped to the destination URL during a COPY or overwrite a resource mapped to the destination URL during a COPY or
MOVE. A value of "F" states that the server must not perform the MOVE. A value of "F" states that the server must not perform the
COPY or MOVE operation if the state of the destination URL does map COPY or MOVE operation if the state of the destination URL does map
to a resource. If the overwrite header is not included in a COPY or to a resource. 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 MOVE request then the resource MUST treat the request as if it has an
overwrite header of value "T". While the Overwrite header appears to overwrite header of value "T". While the Overwrite header appears to
duplicate the functionality of the If-Match: * header of HTTP/1.1, duplicate the functionality of the If-Match: * header of HTTP/1.1,
If-Match applies only to the Request-URI, and not to the Destination If-Match applies only to the Request-URI, and not to the Destination
of a COPY or MOVE. of a COPY or MOVE.
If a COPY or MOVE is not performed due to the value of the Overwrite If a COPY or MOVE is not performed due to the value of the Overwrite
header, the method MUST fail with a 412 (Precondition Failed) status header, the method MUST fail with a 412 (Precondition Failed) status
code. code. The server MUST do authorization checks before checking this
or any conditional header.
All DAV compliant resources MUST support the Overwrite header. All DAV compliant resources MUST support the Overwrite header.
9.8. Timeout Request Header 9.7. Timeout Request Header
TimeOut = "Timeout" ":" 1#TimeType TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite") TimeType = ("Second-" DAVTimeOutVal | "Infinite")
; No LWS allowed within TimeType ; No LWS allowed within TimeType
DAVTimeOutVal = 1*DIGIT DAVTimeOutVal = 1*DIGIT
Clients may include Timeout request headers in their LOCK requests. Clients may include Timeout request headers in their LOCK requests.
However, the server is not required to honor or even consider these However, the server is not required to honor or even consider these
requests. Clients MUST NOT submit a Timeout request header with any requests. Clients MUST NOT submit a Timeout request header with any
method other than a LOCK method. method other than a LOCK method.
skipping to change at page 77, line 12 skipping to change at page 77, line 12
request MUST NOT be repeated until it is requested by a separate user request MUST NOT be repeated until it is requested by a separate user
action. action.
11. Use of HTTP Status Codes 11. Use of HTTP Status Codes
These HTTP codes are not redefined, but their use is somewhat These HTTP codes are not redefined, but their use is somewhat
extended by WebDAV methods and requirements. In general, many HTTP extended by WebDAV methods and requirements. In general, many HTTP
status codes can be used in response to any request, not just in status codes can be used in response to any request, not just in
cases described in this document. Note also that WebDAV servers are cases described in this document. Note also that WebDAV servers are
known to use 300-level redirect responses (and early interoperability known to use 300-level redirect responses (and early interoperability
tests found clients unprepared to see those responses). tests found clients unprepared to see those responses). A 300-level
request MUST NOT be used when the server has created a new resource
in response to the request.
11.1. 412 Precondition Failed 11.1. 412 Precondition Failed
Any request can contain a conditional header defined in HTTP (If- Any request can contain a conditional header defined in HTTP (If-
Match, If-Modified-Since, etc.) or the "If" or "Overwrite" Match, If-Modified-Since, etc.) or the "If" or "Overwrite"
conditional headers defined in this specification. If the request conditional headers defined in this specification. If the request
contains a conditional header, and if that condition fails to hold, contains a conditional header, and if that condition fails to hold,
then this error code MUST be returned unless some other error is then this error code MUST be returned unless some other error is
returned. On the other hand, if the client did not include a returned. On the other hand, if the client did not include a
conditional header in the request, then the server MUST NOT use this conditional header in the request, then the server MUST NOT use this
skipping to change at page 81, line 48 skipping to change at page 81, line 48
<!ELEMENT depth (#PCDATA) > <!ELEMENT depth (#PCDATA) >
13.6. error XML Element 13.6. error XML Element
Name: error Name: error
Purpose: Error responses, particularly 403 Forbidden and 409 Purpose: Error responses, particularly 403 Forbidden and 409
Conflict, sometimes need more information to indicate what went Conflict, sometimes need more information to indicate what went
wrong. When an error response contains a body in WebDAV, the body wrong. When an error response contains a body in WebDAV, the body
is in XML with the root element 'error'. The 'error' element is in XML with the root element 'error'. The 'error' element
SHOULD include a standard precondition element defined in this SHOULD include an XML element with the code of a failed
specification or another specification. The 'error' tag MAY precondition or postcondition.
include custom error tags (in custom XML namespaces) which a
client can safely ignore.
Description: Contains any XML element Description: Contains any XML element
Extensibility: Fully extensible with additional child elements or Extensibility: Fully extensible with additional child elements,
attributes which SHOULD be ignored if not recognized. attributes or text (possibly mixed content). Unrecognized
information items SHOULD be ignored if not recognized.
<!ELEMENT error ANY > <!ELEMENT error ANY >
13.7. exclusive XML Element 13.7. exclusive XML Element
Name: exclusive Name: exclusive
Purpose: Specifies an exclusive lock Purpose: Specifies an exclusive lock
Extensibility: Normally empty, but MAY be extended with additional Extensibility: Normally empty, but MAY be extended with additional
skipping to change at page 82, line 34 skipping to change at page 82, line 35
13.8. href XML Element 13.8. href XML Element
Name: href Name: href
Purpose: Identifies the content of the element as a URI or a Purpose: Identifies the content of the element as a URI or a
relative reference. There may be limits on the value of 'href' relative reference. There may be limits on the value of 'href'
depending on the context of its use. Refer to the specification depending on the context of its use. Refer to the specification
text where 'href' is used to see what limitations apply in each text where 'href' is used to see what limitations apply in each
case. case.
Value: URI (See section 3 of [RFC3986]) Value: URI-reference (See section 4.1 of [RFC3986])
Extensibility: MAY be extended with attributes which SHOULD be Extensibility: MAY be extended with attributes which SHOULD be
ignored if not recognized. ignored if not recognized.
<!ELEMENT href (#PCDATA)> <!ELEMENT href (#PCDATA)>
13.9. location XML Element 13.9. location XML Element
Name: location Name: location
Purpose: HTTP defines the "Location" header (section 14.30) to Purpose: HTTP defines the "Location" header (see [RFC2616], section
provide the new URI in the response to a request for a single 14.30) for use with some status codes (such as 201 and the 300
redirected resource. When a redirection status code is used in a series codes). When these codes are used inside a Multi-Status
Multi-Status response, this element MAY be used to provide that response, the 'location' element can be used to provide the
new URI. accompanying 'Location' header.
Description: Contains a single href element with the same value that Description: Contains a single href element with the same value that
would be used in a Location header. would be used in a Location header.
Extensibility: MAY be extended with additional child elements or Extensibility: MAY be extended with additional child elements or
attributes which SHOULD be ignored if not recognized. attributes which SHOULD be ignored if not recognized.
<!ELEMENT location (href)> <!ELEMENT location (href)>
13.10. lockentry XML Element 13.10. lockentry XML Element
skipping to change at page 89, line 47 skipping to change at page 89, line 47
ignored. ignored.
<!ELEMENT status (#PCDATA) > <!ELEMENT status (#PCDATA) >
13.29. timeout XML Element 13.29. timeout XML Element
Name: timeout Name: timeout
Purpose: The number of seconds remaining before a lock expires. Purpose: The number of seconds remaining before a lock expires.
Value: TimeType (defined in Section 9.8). Value: TimeType (defined in Section 9.7).
Extensibility: MAY be extended with attributes which SHOULD be Extensibility: MAY be extended with attributes which SHOULD be
ignored. ignored.
<!ELEMENT timeout (#PCDATA) > <!ELEMENT timeout (#PCDATA) >
13.30. write XML Element 13.30. write XML Element
Name: write Name: write
skipping to change at page 91, line 17 skipping to change at page 91, line 17
For DAV properties, the name of the property is also the same as the For DAV properties, the name of the property is also the same as the
name of the XML element that contains its value. In the section name of the XML element that contains its value. In the section
below, the final line of each section gives the element type below, the final line of each section gives the element type
declaration using the format defined in [XML]. The "Value" field, declaration using the format defined in [XML]. The "Value" field,
where present, specifies further restrictions on the allowable where present, specifies further restrictions on the allowable
contents of the XML element using BNF (i.e., to further restrict the contents of the XML element using BNF (i.e., to further restrict the
values of a PCDATA element). Note that a resource may have only one values of a PCDATA element). Note that a resource may have only one
value for a property of a given name, so the property may only show value for a property of a given name, so the property may only show
up once in PROPFIND responses or PROPPATCH requests. up once in PROPFIND responses or PROPPATCH requests.
Some property values are calculated by the server and it is not A protected property is one which cannot be changed with a PROPPATCH
appropriate to allow client changes, thus they are protected. request. There may be other requests which would result in a change
Existing server implementations already have different sets of to a protected property (as when a PUT request to an existing
RFC2518 properties protected, but clients can have some expectations resource causes DAV:contentlength to change to a new value). Note
which properties are normally protected. The value of a protected that a given property could be protected on one type of resource, but
property may not be changed even by a user with permission to edit not protected on another type of resource.
other properties. The value of an unprotected property may be
changed by some users with appropriate permissions. A computed property is one with a value defined in terms of a
computation (based on the content and other properties of that
resource, or even of some other resource). A computed property is
always a protected property.
COPY and MOVE behavior refers to local COPY and MOVE operations. COPY and MOVE behavior refers to local COPY and MOVE operations.
For properties defined based on HTTP GET response headers (DAV:get*), For properties defined based on HTTP GET response headers (DAV:get*),
the value could include LWS as defined in [RFC2616], section 4.2. the value could include LWS as defined in [RFC2616], section 4.2.
Server implementors SHOULD NOT include extra LWS in these values, Server implementors SHOULD NOT include extra LWS in these values,
however client implementors MUST be prepared to handle extra LWS. however client implementors MUST be prepared to handle extra LWS.
14.1. creationdate Property 14.1. creationdate Property
skipping to change at page 92, line 25 skipping to change at page 92, line 29
14.2. displayname Property 14.2. displayname Property
Name: displayname Name: displayname
Purpose: Provides a name for the resource that is suitable for Purpose: Provides a name for the resource that is suitable for
presentation to a user. presentation to a user.
Value: Any text Value: Any text
Protected: SHOULD NOT be protected Protected: SHOULD NOT be protected. Note that servers implementing
RFC2518 might have made this a protected property as this is a new
requirement.
COPY/MOVE behaviour: This property value SHOULD be preserved in COPY COPY/MOVE behaviour: This property value SHOULD be preserved in COPY
and MOVE operations. and MOVE operations.
Description: The DAV:displayname property should be defined on all Description: The DAV:displayname property should be defined on all
DAV compliant resources. If present, the property contains a DAV compliant resources. If present, the property contains a
description of the resource that is suitable for presentation to a description of the resource that is suitable for presentation to a
user. user. This property is defined on the resource, and hence SHOULD
have the same value independent of the Request-URI used to
retrieve it (thus computing this property based on the Request-URI
is deprecated).
Extensibility: MAY contain attributes which SHOULD be ignored if not Extensibility: MAY contain attributes which SHOULD be ignored if not
recognized. recognized.
<!ELEMENT displayname (#PCDATA) > <!ELEMENT displayname (#PCDATA) >
14.3. getcontentlanguage Property 14.3. getcontentlanguage Property
Name: getcontentlanguage Name: getcontentlanguage
Purpose: Contains the Content-Language header returned by a GET Purpose: Contains the Content-Language header value (from section
without accept headers 14.12 of [RFC2616]) as it would be returned by a GET without
accept headers.
Value: language-tag (language-tag is defined in section 3.10 of
[RFC2616]).
Value: language-tag (language-tag is defined in section 14.13 of
[RFC2616])
Protected: SHOULD NOT be protected, so that clients can reset the Protected: SHOULD NOT be protected, so that clients can reset the
language. language. Note that servers implementing RFC2518 might have made
this a protected property as this is a new requirement.
COPY/MOVE behaviour: This property value SHOULD be preserved in COPY COPY/MOVE behaviour: This property value SHOULD be preserved in COPY
and MOVE operations. and MOVE operations.
Description: The DAV:getcontentlanguage property MUST be defined on Description: The DAV:getcontentlanguage property MUST be defined on
any DAV compliant resource that returns the Content-Language any DAV compliant resource that returns the Content-Language
header on a GET. header on a GET.
Extensibility: MAY contain attributes which SHOULD be ignored if not Extensibility: MAY contain attributes which SHOULD be ignored if not
recognized. recognized.
<!ELEMENT getcontentlanguage (#PCDATA) > <!ELEMENT getcontentlanguage (#PCDATA) >
14.4. getcontentlength Property 14.4. getcontentlength Property
Name: getcontentlength Name: getcontentlength
Purpose: Contains the Content-Length header returned by a GET Purpose: Contains the Content-Length header returned by a GET
without accept headers. without accept headers.
Value: content-length (see section 14.14 of [RFC2616]) Value: See section 14.13 of [RFC2616].
Protected: SHOULD be protected so clients cannot set to misleading Protected: This property is computed, therefore protected.
values
Description: The DAV:getcontentlength property MUST be defined on Description: The DAV:getcontentlength property MUST be defined on
any DAV compliant resource that returns the Content-Length header any DAV compliant resource that returns the Content-Length header
in response to a GET. in response to a GET.
COPY/MOVE behaviour: This property value is dependent on the size of COPY/MOVE behaviour: This property value is dependent on the size of
the destination resource, not the value of the property on the the destination resource, not the value of the property on the
source resource. source resource.
Extensibility: MAY contain attributes which SHOULD be ignored if not Extensibility: MAY contain attributes which SHOULD be ignored if not
recognized. recognized.
<!ELEMENT getcontentlength (#PCDATA) > <!ELEMENT getcontentlength (#PCDATA) >
14.5. getcontenttype Property 14.5. getcontenttype Property
Name: getcontenttype Name: getcontenttype
Purpose: Contains the Content-Type header returned by a GET without Purpose: Contains the Content-Type header value (from section 14.17
accept headers. of [RFC2616]) as it would be returned by a GET without accept
headers.
Value: media-type (defined in section 3.7 of [RFC2616]) Value: media-type (defined in section 3.7 of [RFC2616])
Protected: SHOULD NOT be protected, so clients may fix this value Protected: SHOULD NOT be protected, so clients may fix this value.
Note that servers implementing RFC2518 might have made this a
protected property as this is a new requirement.
COPY/MOVE behaviour: This property value SHOULD be preserved in COPY COPY/MOVE behaviour: This property value SHOULD be preserved in COPY
and MOVE operations. and MOVE operations.
Description: This property MUST be defined on any DAV compliant Description: This property MUST be defined on any DAV compliant
resource that returns the Content-Type header in response to a resource that returns the Content-Type header in response to a
GET. GET.
Extensibility: MAY contain attributes which SHOULD be ignored if not Extensibility: MAY contain attributes which SHOULD be ignored if not
recognized. recognized.
<!ELEMENT getcontenttype (#PCDATA) > <!ELEMENT getcontenttype (#PCDATA) >
14.6. getetag Property 14.6. getetag Property
Name: getetag Name: getetag
Purpose: Contains the ETag header returned by a GET without accept Purpose: Contains the ETag header value (from section 14.19 of
[RFC2616]) as it would be returned by a GET without accept
headers. headers.
Value: entity-tag (defined in section 3.11 of [RFC2616]) Value: entity-tag (defined in section 3.11 of [RFC2616])
Protected: MUST be protected because this value is created and Protected: MUST be protected because this value is created and
controlled by the server. controlled by the server.
COPY/MOVE behaviour: This property value is dependent on the final COPY/MOVE behaviour: This property value is dependent on the final
state of the destination resource, not the value of the property state of the destination resource, not the value of the property
on the source resource. on the source resource.
skipping to change at page 95, line 4 skipping to change at page 95, line 11
for a complete definition of the semantics of an ETag. Note that for a complete definition of the semantics of an ETag. Note that
changes in properties or lock state MUST not cause a resource's changes in properties or lock state MUST not cause a resource's
ETag to change. ETag to change.
Extensibility: MAY contain attributes which SHOULD be ignored if not Extensibility: MAY contain attributes which SHOULD be ignored if not
recognized. recognized.
<!ELEMENT getetag (#PCDATA) > <!ELEMENT getetag (#PCDATA) >
14.7. getlastmodified Property 14.7. getlastmodified Property
Name: getlastmodified Name: getlastmodified
Purpose: Contains the Last-Modified header returned by a GET method Purpose: Contains the Last-Modified header value (from section 14.29
without accept headers. of [RFC2616]) as it would be returned by a GET method without
accept headers.
Value: rfc1123-date (defined in section 3.3.1 of [RFC2616]) Value: rfc1123-date (defined in section 3.3.1 of [RFC2616])
Protected: SHOULD be protected because some clients may rely on the Protected: SHOULD be protected because some clients may rely on the
value for appropriate caching behavior, or on the value of the value for appropriate caching behavior, or on the value of the
Last-Modified header to which this property is linked. Last-Modified header to which this property is linked.
COPY/MOVE behaviour: This property value is dependent on the last COPY/MOVE behaviour: This property value is dependent on the last
modified date of the destination resource, not the value of the modified date of the destination resource, not the value of the
property on the source resource. Note that some server property on the source resource. Note that some server
skipping to change at page 98, line 8 skipping to change at page 98, line 8
Purpose: Specifies the nature of the resource. Purpose: Specifies the nature of the resource.
Protected: SHOULD be protected. Resource type is generally decided Protected: SHOULD be protected. Resource type is generally decided
through the operation creating the resource (MKCOL vs PUT), not by through the operation creating the resource (MKCOL vs PUT), not by
PROPPATCH. PROPPATCH.
COPY/MOVE behaviour: Generally a COPY/MOVE of a resource results in COPY/MOVE behaviour: Generally a COPY/MOVE of a resource results in
the same type of resource at the destination. the same type of resource at the destination.
Description: MUST be defined on all DAV compliant resources. The Description: MUST be defined on all DAV compliant resources. Each
default value is empty. child element identifies a specific type the resource belongs to,
such as 'collection', which is the only resource type defined by
this specification (see Section 13.3). If the element contains
the 'collection' child element plus additional unrecognized
elements, it should generally be treated as a collection. If the
element contains no recognized child elements, it should be
treated as a non-collection resource. The default value is empty.
Extensibility: MAY be extended with any child elements or attributes Extensibility: MAY be extended with any child elements or attributes
which SHOULD be ignored if not recognized. If the element which SHOULD be ignored if not recognized.
contains the 'collection' child element plus additional
unrecognized elements/attributes, it should generally be treated
as a collection. If the element contains no recognized child
elements it should be treated as a non-collection WebDAV-compliant
resource.
Example: (fictional example to show extensibility) Example: (fictional example to show extensibility)
<x:resourcetype xmlns:x="DAV:"> <x:resourcetype xmlns:x="DAV:">
<x:collection/> <x:collection/>
<f:search-results xmlns:f="http://www.example.com/ns"/> <f:search-results xmlns:f="http://www.example.com/ns"/>
</x:resourcetype> </x:resourcetype>
14.10. supportedlock Property 14.10. supportedlock Property
skipping to change at page 100, line 7 skipping to change at page 100, line 7
</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>
15. Precondition/postcondition XML elements 15. Precondition/postcondition XML elements
The numerical status codes used in HTTP responses are not As introduced in section Section 8.1.5, extra information on error
sufficiently granular or informative for all purposes. Some conditions can be included in the body of many status responses.
extensions to HTTP have used the error response body along with some This section makes requirements on the use of the error body
status codes in order to provide additional machine-readable response mechanism and introduces a number of precondition and postcondition
detail. The machine-readable codes are XML elements classified as codes.
preconditions and postconditions. Even if clients do not
automatically recognize the error bodies they can be quite useful in
interoperability testing and debugging.
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. If a method precondition or postcondition method has been completed.
for a request is not satisfied, the response status of the request
MUST be either 403 (Forbidden) if the request should not be repeated
because it will always fail, or 409 (Conflict) if it is expected that
the user might be able to resolve the conflict and resubmit the
request.
The XML element associated with the precondition or postcondition Each precondition and postcondition has a unique XML element
MUST be returned as the child of a top-level DAV:error element in the associated with it. In a 207 Multi-Status response, the XML element
response body, unless otherwise negotiated by the request. In a 207 MUST appear inside a DAV:error element in the appropriate DAV:
Multi-Status response, the DAV:error element would appear in the responsedescription element. In all other error responses, the XML
appropriate DAV:responsedescription element. element MUST be returned as the child of a top-level DAV:error
element in the response body, unless otherwise negotiated by the
request, along with an appropriate response status. The most common
response status codes are 403 (Forbidden) if the request should not
be repeated because it will always fail, and 409 (Conflict) if it is
expected that the user might be able to resolve the conflict and
resubmit the request. The DAV:error element MAY contain child
elements with specific error information and MAY be extended with
custom child elements and text (mixed content).
Some useful preconditions and postconditions have been defined in This mechanism does not take the place of using a correct numeric
other specifications extending this one, such as [RFC3744] (see error code as defined here or in HTTP, because the client MUST always
be able to take a reasonable course of action based only on the
numeric error. However, it does remove the need to define new
numeric error codes. The machine-readable codes used for this
purpose are XML elements classified as preconditions and
postconditions, so naturally any group defining a new error code can
use their own namespace. As always, the "DAV:" namespace is reserved
for use by IETF-chartered WebDAV working groups.
A server supporting "bis" SHOULD use the XML error whenever a
precondition or postcondition defined in this document is violated.
For error conditions not specified in this document, the server MAY
simply choose an appropriate numeric status and leave the response
body blank. However, a server MAY instead use a custom error code
and other supporting text, because even when clients do not
automatically recognize error codes they can be quite useful in
interoperability testing and debugging.
15.1. Example - Response with precondition code
>>Response
HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:lock-token-present>
<D:href>/workspace/webdav/</D:href>
</D:lock-token-present>
</D:error>
In this example, a client unaware of a "Depth: infinity" lock on the
parent collection "/workspace/webdav/" attempted to modify the
collection member "/workspace/webdav/proposal.doc".
Some other useful preconditions and postconditions have been defined
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. All these elements are in the "DAV:" namespace.
Name: no-external-entities Name: no-external-entities
Use with: 403 Forbidden Use with: 403 Forbidden
Purpose: (precondition) -- If the server rejects a client request Purpose: (precondition) -- If the server rejects a client request
because the request body contains an external entity, the server because the request body contains an external entity, the server
skipping to change at page 104, line 47 skipping to change at page 104, line 47
lockdiscovery property, the Time-Out response header and the Lock- lockdiscovery property, the Time-Out response header and the Lock-
Token request header. A class "2" compliant resource SHOULD also Token request header. A class "2" compliant resource SHOULD also
support the Time-Out request header and the owner XML element. support the Time-Out request header and the owner XML element.
Class 2 compliant resources MUST return, at minimum, the values "1" Class 2 compliant resources MUST return, at minimum, the values "1"
and "2" in the DAV header on all responses to the OPTIONS method. and "2" in the DAV header on all responses to the OPTIONS method.
17.3. Class 'bis' 17.3. Class 'bis'
A resource can explicitly advertise its support for the revisions to A resource can explicitly advertise its support for the revisions to
RFC2518 made in this document. In particular, this allows clients to RFC2518 made in this document. Class 1 must be supported as well.
use the Force-Authentication header on requests. Class 1 must be Class 2 MAY be supported.
supported as well. Class 2 MAY be supported.
A resource that supports "bis" MUST support:
o the Force-Authentication header.
o Any behavior that it supports, in the manner specified in this
document, rather than in the manner specified in RFC2518, for all
client requests. A server MAY use an older behavior for specific
clients that are discovered to have interoperability problems with
the requirements of this specification, but MUST NOT use an older
behavior indiscriminately.
Example: Example:
DAV: 1, bis DAV: 1, bis
18. Internationalization Considerations 18. Internationalization Considerations
In the realm of internationalization, this specification complies In the realm of internationalization, this specification complies
with the IETF Character Set Policy [RFC2277]. In this specification, with the IETF Character Set Policy [RFC2277]. In this specification,
human-readable fields can be found either in the value of a property, human-readable fields can be found either in the value of a property,
skipping to change at page 114, line 48 skipping to change at page 113, line 48
We would also like to thank John Turner for developing the XML DTD. We would also like to thank John Turner for developing the XML DTD.
The authors of RFC2518 were Yaron Goland, Jim Whitehead, A. Faizi, The authors of RFC2518 were Yaron Goland, Jim Whitehead, A. Faizi,
Steve Carter and D. Jensen. Although their names had to be removed Steve Carter and D. Jensen. Although their names had to be removed
due to IETF author count restrictions they can take credit for the due to IETF author count restrictions they can take credit for the
majority of the design of WebDAV. majority of the design of WebDAV.
Additional Contributors to This Specification Additional Contributors to This Specification
Valuable contributions to this specification came from some already Valuable contributions to this specification came from some already
named. New contributors must also be gratefully acknowledged. named. New and significant contributors to this specification must
Julian Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed also be gratefully acknowledged. Julian Reschke, Geoff Clemm, Joel
out specific text on the list or in meetings. Ilya Kirnos supplied Soderberg, and Dan Brotsky hashed out specific text on the list or in
text for Force-Authentication header. Joe Hildebrand contributed as meetings. Joe Hildebrand and Cullen Jennings helped close many
co-chair. Barry Lind described an additional security consideration. issues. Barry Lind described an additional security consideration.
Jason Crawford tracked issue status for this document for a period of Jason Crawford tracked issue status for this document for a period of
years, followed by Elias Sinderson. years, followed by Elias Sinderson. Elias and Jim Whitehead
collaborated on specific document text.
21.1. Previous Authors' Addresses 21.1. Previous Authors' Addresses
Y. Y. Goland, Microsoft Corporation, One Microsoft Way, Redmond, WA Y. Y. Goland, Microsoft Corporation, One Microsoft Way, Redmond, WA
98052-6399. Email: yarong@microsoft.com. 98052-6399. Email: yarong@microsoft.com.
E. J. Whitehead, Jr., Dept. Of Information and Computer Science, E. J. Whitehead, Jr., Dept. Of Information and Computer Science,
University of California, Irvine, Irvine, CA 92697-3425. Email: University of California, Irvine, Irvine, CA 92697-3425. Email:
ejw@ics.uci.edu. ejw@ics.uci.edu.
skipping to change at page 122, line 5 skipping to change at page 121, line 5
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 white ; UUID is defined in section 3 of RFC4122. Note that linear white
; space (LWS) is not allowed between elements of this production. ; space (LWS) is not allowed between elements of 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. Summary of changes from RFC2518 Appendix D. Guidance for Clients Desiring to Authenticate
Many WebDAV clients already implemented have account settings
(similar to the way email clients store IMAP account settings).
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
authentication challenge from the server with realm name, nonce and
other challenge information. Note that the results of some requests
might vary according to whether the client is authenticated or not --
a PROPFIND might return more visible resources if the client is
authenticated, yet not fail if the client is anonymous.
There are a number of ways the client might be able to trigger the
server do provide an authentication challenge. This appendix
describes a couple approaches that seem particularly likely to work.
The first approach is to perform a request that ought to require
authentication. However, it's possible that a server might handle
any request even without authentication, so to be entirely safe the
client could add a conditional header to ensure that even if the
request passes permissions checks it's not actually handled by the
server. An example of following this approach would be to use a PUT
request with an "If-Match" header with a made-up ETag value. This
approach might fail to result in an authentication challenge if the
server does not test authorization before testing conditionals as is
required (see Section 8.1.3), or if the server does not need to test
authorization.
Example - forcing auth challenge with write request
>>Request
PUT /forceauth.txt HTTP/1.1
Host: www.example.com
If-Match: "xxx"
Content-Type: text/plain
Content-Length: 0
The second approach is to use an Authorization header (defined in
[RFC2617]) which is likely to be rejected by the server but which
will then prompt a proper authentication challenge. For example, the
client could start with a PROPFIND request containing an
Authorization header containing a made-up Basic userid:password
string or with actual plausible credentials. This approach relies on
the server responding with a "401 Unauthorized" along with a
challenge if it receives an Authorization header with an unrecognized
username, invalid password, or if it doesn't even handle Basic
authentication. This seems likely to work because of the
requirements of RFC2617:
"If the origin server does not wish to accept the credentials sent
with a request, it SHOULD return a 401 (Unauthorized) response. The
response MUST include a WWW-Authenticate header field containing at
least one (possibly new) challenge applicable to the requested
resource."
Example - forcing auth challenge with Authorization header
>>Request
PROPFIND /docs/ HTTP/1.1
Host: www.example.com
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-type: application/xml; charset="utf-8"
Content-Length: xxxx
[body omitted]
Appendix E. Summary of changes from RFC2518
This section describes changes that are likely to result in This section describes changes that are likely to result in
implementation changes due to tightened requirements or changed implementation changes due to tightened requirements or changed
behavior. behavior.
D.1. Changes Notable to Server Implementors E.1. Changes Notable to Server Implementors
Tightened requirements for storing property values (Section 4.4) when Tightened requirements for storing property values (Section 4.4) when
"xml:lang" appears and also when values are XML fragments "xml:lang" appears and also when values are XML fragments
(specifically on preserving prefixes, namespaces and whitespace.) (specifically on preserving prefixes, namespaces and whitespace.)
Tightened requirements on which properties are protected and computed
(Section 14).
Several tightened requirements for general response handling Several tightened requirements for general response handling
(Section 8.1), including response bodies for use with errors, ETag (Section 8.1), including response bodies for use with errors, ETag
and Location header, and reminder to use Date header. and Location header, and reminder to use Date header.
Tightened requirements for URL construction in PROPFIND (Section 8.2) Tightened requirements for URL construction in PROPFIND (Section 8.2)
responses. responses.
Tightened requirements for checking identity of lock owners Tightened requirements for checking identity of lock owners
(Section 7.1) during operations affected by locks. (Section 7.1) during operations affected by locks.
skipping to change at page 122, line 40 skipping to change at page 123, line 43
Tightened requirements on preserving owner field in locks Tightened requirements on preserving owner field in locks
(Section 8.11). Added "lockroot" element to lockdiscovery (Section 8.11). Added "lockroot" element to lockdiscovery
information. information.
New value for "DAV:" header (Section 9.1) to advertise support for New value for "DAV:" header (Section 9.1) to advertise support for
this specification. this specification.
Tightened requirement for "Destination:" header (Section 9.3) to work Tightened requirement for "Destination:" header (Section 9.3) to work
with path values with path values
New "Force-Authentication:" (Section 9.4) header added. Some changes for "If:" header (Section 9.4), including "DAV:no-lock"
state token and requirement to evaluate entire header.
Some changes for "If:" header (Section 9.5), including "DAV:no-lock"
state token.
Support for UTF-16 now required (ref (Section 18)). Support for UTF-16 now required (ref (Section 18)).
Removed definition of "source" property and special handling for Removed definition of "source" property and special handling for
dynamic resources dynamic resources
Replaced lock-null resources with simpler locked empty resources. Replaced lock-null resources with simpler locked empty resources
Lock-null resources are now not compliant with the requirements in (Section 7.6). Lock-null resources are now not compliant with the
this specification. (Section 7.6) requirements in this specification.
Encouraged servers to change ETags (Section 8.1.4) only when body of Encouraged servers to change ETags (Section 8.1.4) only when body of
resource changes. resource changes.
The definition of the 102 Processing response was removed and servers The definition of the 102 Processing response was removed and servers
ought to stop sending that response when they implement this ought to stop sending that response when they implement this
specification. specification.
Previously, servers were encouraged to return 409 status code in Previously, servers were encouraged to return 409 status code in
response to a collection LOCK request if some resource could not be response to a collection LOCK request if some resource could not be
locked. Now servers should use 207 Multi-Status instead. locked. Now servers should use 207 Multi-Status instead.
Only 'rfc1123-date' productions are legal as values for DAV: Only 'rfc1123-date' productions are legal as values for DAV:
getlastmodified. getlastmodified.
D.2. Changes Notable to Client Implementors New explicit requirement to do authorization checks before
conditional checks (Section 8.1.3).
E.2. Changes Notable to Client Implementors
Tightened requirements for supporting WebDAV collections Tightened requirements for supporting WebDAV collections
(Section 5.2) within resources that do not support WebDAV (e.g. (Section 5.2) within resources that do not support WebDAV (e.g.
servlet containers). servlet containers).
Redefined 'allprop' PROPFIND requests so that the server does not Redefined 'allprop' PROPFIND requests so that the server does not
have to return all properties. have to return all properties.
Required to handle empty multistatus responses in PROPFIND responses Required to handle empty multistatus responses in PROPFIND responses
(Section 8.2) (Section 8.2)
skipping to change at page 124, line 5 skipping to change at page 124, line 51
that cleanup happening. that cleanup happening.
Support for UTF-16 now required (ref (Section 18)). Support for UTF-16 now required (ref (Section 18)).
Removed definition of "source" property and special handling for Removed definition of "source" property and special handling for
dynamic resources. dynamic resources.
The definition of the 102 Processing response was removed and clients The definition of the 102 Processing response was removed and clients
can safely remove code (if any) that deals with this. can safely remove code (if any) that deals with this.
Appendix E. Change Log (to be removed by RFC Editor before publication) Servers may now reject PROPFIND depth "infinity" requests.
E.1. Changes from -05 to -06 Clients use Lock-Token header, not the If header, to provide lock
token when renewing lock. Section 8.11.1
Appendix F. Change Log (to be removed by RFC Editor before publication)
F.1. Changes from -05 to -06
Specified that a successful LOCK request to an unmapped URL creates a Specified that a successful LOCK request to an unmapped URL creates a
new, empty locked resource. new, empty locked resource.
Resolved UNLOCK_NEEDS_IF_HEADER by clarifying that only Lock-Token Resolved UNLOCK_NEEDS_IF_HEADER by clarifying that only Lock-Token
header is needed on UNLOCK. header is needed on UNLOCK.
Added Section 15 on preconditions and postconditions and defined a Added Section 15 on preconditions and postconditions and defined a
number of preconditions and postconditions. The 'lock-token-present' number of preconditions and postconditions. The 'lock-token-present'
precondition resolves the REPORT_OTHER_RESOURCE_LOCKED issue. precondition resolves the REPORT_OTHER_RESOURCE_LOCKED issue.
skipping to change at page 124, line 33 skipping to change at page 126, line 33
keep consistent with other places where client provides URLs (If keep consistent with other places where client provides URLs (If
header, href element in request body) header, href element in request body)
Clarified the href element - that it generally contains HTTP URIs but Clarified the href element - that it generally contains HTTP URIs but
not always. not always.
Attempted to fix the BNF describing the If header to allow commas Attempted to fix the BNF describing the If header to allow commas
Clarified presence of Depth header on LOCK refresh requests. Clarified presence of Depth header on LOCK refresh requests.
E.2. Changes in -07 F.2. Changes in -07
Added text to "COPY and the Overwrite Header" section to resolve Added text to "COPY and the Overwrite Header" section to resolve
issue OVERWRITE_DELETE_ALL_TOO_STRONG. issue OVERWRITE_DELETE_ALL_TOO_STRONG.
Added text to "HTTP URL Namespace Model" section to provide more Added text to "HTTP URL Namespace Model" section to provide more
clarification and examples on what consistency means and what is not clarification and examples on what consistency means and what is not
required, to resolve issue CONSISTENCY. required, to resolve issue CONSISTENCY.
Resolve DEFINE_PRINCIPAL by importing definition of principal from Resolve DEFINE_PRINCIPAL by importing definition of principal from
RFC3744. RFC3744.
skipping to change at page 125, line 43 skipping to change at page 127, line 43
Added section on lock owner (7.1) and what to do if lock requested by Added section on lock owner (7.1) and what to do if lock requested by
unauthenticated user unauthenticated user
Removed section 4.2 -- justification on why to have metadata, not Removed section 4.2 -- justification on why to have metadata, not
needed now needed now
Removed paragraph in section 5.2 about collections with resource type Removed paragraph in section 5.2 about collections with resource type
"DAV:collection" but which are non-WebDAV compliant -- not "DAV:collection" but which are non-WebDAV compliant -- not
implemented. implemented.
E.3. Changes in -08 F.3. Changes in -08
Added security considerations section on scripts and cookie sessions, Added security considerations section on scripts and cookie sessions,
suggested by Barry Lind suggested by Barry Lind
Clarified which error codes are defined and undefined in MultiStatus Clarified which error codes are defined and undefined in MultiStatus
Moved opaquelocktoken definition to an appendix and refer to RFC4122 Moved opaquelocktoken definition to an appendix and refer to RFC4122
for use of 'urn:uuid:' URI scheme; fix all lock token examples to use for use of 'urn:uuid:' URI scheme; fix all lock token examples to use
this. this.
skipping to change at page 126, line 17 skipping to change at page 128, line 17
limitations. (bug 12) limitations. (bug 12)
Moved status code sections before example sections within PROPFIND Moved status code sections before example sections within PROPFIND
section for section ordering consistency. section for section ordering consistency.
Clarified use of Location header with Multi-Status Clarified use of Location header with Multi-Status
Bugzilla issue resolutions: bugs 9, 12, 14, 19, 20, 29, 30, 34, 36, Bugzilla issue resolutions: bugs 9, 12, 14, 19, 20, 29, 30, 34, 36,
102 and 172. 102 and 172.
E.4. Changes in -09 F.4. Changes in -09
Bugzilla editorial issues: bugs 30, 57, 63, 68, 88, 89, 168, 180, Bugzilla editorial issues: bugs 30, 57, 63, 68, 88, 89, 168, 180,
182, 185, 187. 182, 185, 187.
More clarity between URL namespaces and XML namespaces, particularly More clarity between URL namespaces and XML namespaces, particularly
at the beginning of paragraphs using the word namespace at the beginning of paragraphs using the word namespace
More consistency in referring to properties with the namespace, as in More consistency in referring to properties with the namespace, as in
"DAV:lockdiscovery", and referring to XML element names in single "DAV:lockdiscovery", and referring to XML element names in single
quotes, e.g. 'allprop' element. quotes, e.g. 'allprop' element.
skipping to change at page 128, line 5 skipping to change at page 129, line 8
Fix bug 46, 105, 107, 120, 140 and 201. Fix bug 46, 105, 107, 120, 140 and 201.
Another stab at bug 12 - relative v. absolute URLs in Multi-Status Another stab at bug 12 - relative v. absolute URLs in Multi-Status
response hrefs response hrefs
Fix bug 6, 11, 15, 16, 28, 32, 42, 51, 52, 53, 58, 60, 62, 186, 189, Fix bug 6, 11, 15, 16, 28, 32, 42, 51, 52, 53, 58, 60, 62, 186, 189,
191, 199, 200 191, 199, 200
Fix bug 96 Fix bug 96
F.5. Chandles in -10
Clarify lock intro text on when a client might use another client's
lock token - suggestion by Geoff, Nov 15
Removed Force-Authenticate header and instead added an appendix
explaining how existing mechanisms might resolve the need of clients
to get an authentication challenge (bug 18).
Bug 62, 113, 125, 131, 143, 144, 171, 193
Bug 176, 177, 179, 181, 184, 206, 207, 208
Author's Address Author's Address
Lisa Dusseault Lisa Dusseault
Open Source Application Foundation Open Source Application Foundation
2064 Edgewood Dr. 2064 Edgewood Dr.
Palo Alto, CA 94303 Palo Alto, CA 94303
US US
Email: lisa@osafoundation.org Email: lisa@osafoundation.org
 End of changes. 106 change blocks. 
334 lines changed or deleted 454 lines changed or added

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