idnits 2.17.1
draft-reschke-webdav-locking-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3667, Section 5.1 on line 14.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 2190.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2167.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2174.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2180.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
2196), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 36.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 28 instances of too long lines in the document, the longest
one being 7 characters in excess of 72.
** The abstract seems to contain references ([2], [1]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
-- The draft header indicates that this document updates RFC2518, but the
abstract doesn't seem to directly say this. It does mention RFC2518
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
(Using the creation date from RFC2518, updated by this document, for
RFC5378 checks: 1997-07-21)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (June 18, 2004) is 7245 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'Extension' is mentioned on line 1489, but not defined
-- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-11578'
** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986)
** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML'
Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Network Working Group J. Reschke
2 Internet-Draft greenbytes
3 Updates: 2518 (if approved) June 18, 2004
4 Expires: December 17, 2004
6 Web Distributed Authoring and Versioning (WebDAV) Locking Protocol
7 draft-reschke-webdav-locking-03
9 Status of this Memo
11 By submitting this Internet-Draft, I certify that any applicable
12 patent or other IPR claims of which I am aware have been disclosed,
13 and any of which I become aware will be disclosed, in accordance with
14 RFC 3668.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as
19 Internet-Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on December 17, 2004.
34 Copyright Notice
36 Copyright (C) The Internet Society (2004). All Rights Reserved.
38 Abstract
40 This document specifies a set of methods and headers ancillary to
41 HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV,
42 RFC2518) for the management of resource locking (collision
43 avoidance). It updates those sections from RFC2518 that specify
44 WebDAV's locking features.
46 Editorial Note
48 [[anchor1: Note that this document is not a product of the WebDAV
49 working group. It is just an experiment to study the feasability of
50 extracing the locking feature into a separate specification.
51 --reschke]]
53 Distribution of this document is unlimited. Please send comments to
54 the WebDAV working group at w3c-dist-auth@w3.org [1], which may be
55 joined by sending a message with subject "subscribe" to
56 w3c-dist-auth-request@w3.org [2].
58 Discussions of the WEBDAV working group are archived at URL: .
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
63 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
64 1.2 Method Preconditions and Postconditions . . . . . . . . . 5
65 2. Overview of Locking . . . . . . . . . . . . . . . . . . . . . 6
66 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 6
67 3.1 Common XML elements used in property values . . . . . . . 6
68 3.1.1 Lock Scopes . . . . . . . . . . . . . . . . . . . . . 6
69 3.1.2 Lock Types . . . . . . . . . . . . . . . . . . . . . . 6
70 3.2 DAV:lockdiscovery property . . . . . . . . . . . . . . . . 6
71 3.2.1 Examples for the DAV:lockdiscovery . . . . . . . . . . 7
72 3.3 DAV:supportedlock property . . . . . . . . . . . . . . . . 8
73 3.3.1 Examples for the DAV:supportedlock property . . . . . 9
74 4. LOCK Method . . . . . . . . . . . . . . . . . . . . . . . . . 9
75 4.1 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 9
76 4.1.1 Example - Simple Lock Request . . . . . . . . . . . . 10
77 4.1.2 Example - Multi-Resource Lock Request . . . . . . . . 12
78 4.2 Refreshing Locks . . . . . . . . . . . . . . . . . . . . . 13
79 4.2.1 Example - Refreshing a Write Lock . . . . . . . . . . 14
80 5. UNLOCK Method . . . . . . . . . . . . . . . . . . . . . . . . 15
81 5.1 Example - UNLOCK . . . . . . . . . . . . . . . . . . . . . 16
82 6. Additional status codes . . . . . . . . . . . . . . . . . . . 16
83 6.1 423 Locked . . . . . . . . . . . . . . . . . . . . . . . . 16
84 7. Additional marshalling and method semantics for other
85 methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
86 7.1 Additional marshalling . . . . . . . . . . . . . . . . . . 16
87 7.2 Additional method semantics . . . . . . . . . . . . . . . 17
88 8. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
89 8.1 Lock-Token request/response header . . . . . . . . . . . . 17
90 9. Capability discovery . . . . . . . . . . . . . . . . . . . . . 17
91 9.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 17
92 10. Security considerations . . . . . . . . . . . . . . . . . . 18
93 10.1 Privacy Issues Connected to Locks . . . . . . . . . . . . 18
94 11. Internationalization Considerations . . . . . . . . . . . . 18
95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
96 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
98 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
99 14.2 Informative References . . . . . . . . . . . . . . . . . . . 20
100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20
101 A. Changes to RFC2518 . . . . . . . . . . . . . . . . . . . . . . 20
102 A.1 Removed/Deprecated features . . . . . . . . . . . . . . . 20
103 A.1.1 Implicit lock refresh . . . . . . . . . . . . . . . . 20
104 A.1.2 Lock-null resources . . . . . . . . . . . . . . . . . 21
105 A.2 Additional features . . . . . . . . . . . . . . . . . . . 21
106 A.2.1 DAV:lockroot element in DAV:activelock . . . . . . . . 21
107 B. Text to be integrated from RFC2518 . . . . . . . . . . . . . . 21
108 B.1 Locking . . . . . . . . . . . . . . . . . . . . . . . . . 21
109 B.1.1 Exclusive Vs. Shared Locks . . . . . . . . . . . . . . 22
110 B.1.2 Required Support . . . . . . . . . . . . . . . . . . . 23
111 B.1.3 Lock Tokens . . . . . . . . . . . . . . . . . . . . . 23
112 B.1.4 Lock Capability Discovery . . . . . . . . . . . . . . 23
113 B.1.5 Active Lock Discovery . . . . . . . . . . . . . . . . 24
114 B.1.6 Usage Considerations . . . . . . . . . . . . . . . . . 24
115 B.2 Write Lock . . . . . . . . . . . . . . . . . . . . . . . . 25
116 B.2.1 Methods Restricted by Write Locks . . . . . . . . . . 25
117 B.2.2 Write Locks and Lock Tokens . . . . . . . . . . . . . 25
118 B.2.3 Write Locks and Properties . . . . . . . . . . . . . . 26
119 B.2.4 Write Locks and Collections . . . . . . . . . . . . . 26
120 B.2.5 Write Locks and the If Request Header . . . . . . . . 26
121 B.2.6 Write Locks and COPY/MOVE . . . . . . . . . . . . . . 27
122 B.2.7 Refreshing Write Locks . . . . . . . . . . . . . . . . 28
123 B.3 HTTP Methods for Distributed Authoring . . . . . . . . . . 28
124 B.3.1 LOCK Method . . . . . . . . . . . . . . . . . . . . . 28
125 B.4 HTTP Headers for Distributed Authoring . . . . . . . . . . 30
126 B.4.1 Depth Header . . . . . . . . . . . . . . . . . . . . . 30
127 B.4.2 If Header . . . . . . . . . . . . . . . . . . . . . . 31
128 B.4.3 Timeout Request Header . . . . . . . . . . . . . . . . 31
129 B.5 XML Element Definitions . . . . . . . . . . . . . . . . . 32
130 B.5.1 lockinfo XML Element . . . . . . . . . . . . . . . . . 32
131 C. GULP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
132 C.1 Directly vs Indirectly . . . . . . . . . . . . . . . . . . 32
133 C.2 Creating Locks . . . . . . . . . . . . . . . . . . . . . . 32
134 C.3 Lock Inheritance . . . . . . . . . . . . . . . . . . . . . 32
135 C.4 Removing Locks . . . . . . . . . . . . . . . . . . . . . . 33
136 C.5 Submitting Lock Tokens . . . . . . . . . . . . . . . . . . 33
137 C.6 Locked State . . . . . . . . . . . . . . . . . . . . . . . 33
138 C.7 URL protection . . . . . . . . . . . . . . . . . . . . . . 33
139 C.8 Exclusive vs Shared . . . . . . . . . . . . . . . . . . . 33
140 D. 'opaquelocktoken' URI Scheme . . . . . . . . . . . . . . . . . 33
141 D.1 Node Field Generation Without the IEEE 802 Address . . . . 34
142 E. Change Log (to be removed by RFC Editor before publication) . 36
143 E.1 Since draft-reschke-webdav-locking-00 . . . . . . . . . . 36
144 E.2 Since draft-reschke-webdav-locking-01 . . . . . . . . . . 36
145 E.3 Since draft-reschke-webdav-locking-02 . . . . . . . . . . 37
146 F. Resolved issues (to be removed by RFC Editor before
147 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 37
148 F.1 065_UNLOCK_WHAT_URL . . . . . . . . . . . . . . . . . . . 37
149 F.2 067_UNLOCK_NEEDS_IF_HEADER . . . . . . . . . . . . . . . . 38
150 F.3 068_UNLOCK_WITHOUT_GOOD_TOKEN . . . . . . . . . . . . . . 38
151 F.4 040_LOCK_ISSUES_08 . . . . . . . . . . . . . . . . . . . . 39
152 F.5 040_LOCK_ISSUES_03 . . . . . . . . . . . . . . . . . . . . 40
153 F.6 7.5_DELETE_vs_URIs . . . . . . . . . . . . . . . . . . . . 40
154 F.7 040_LOCK_ISSUES_04 . . . . . . . . . . . . . . . . . . . . 40
155 F.8 053_LOCK_INHERITANCE . . . . . . . . . . . . . . . . . . . 41
156 F.9 057_LOCK_SEMANTICS . . . . . . . . . . . . . . . . . . . . 41
157 G. Open issues (to be removed by RFC Editor prior to
158 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 41
159 G.1 import-rfc3253-stuff . . . . . . . . . . . . . . . . . . . 42
160 G.2 import-gulp . . . . . . . . . . . . . . . . . . . . . . . 42
161 G.3 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
162 G.4 008_URI_URL . . . . . . . . . . . . . . . . . . . . . . . 42
163 G.5 040_LOCK_ISSUES_06 . . . . . . . . . . . . . . . . . . . . 43
164 G.6 056_DEPTH_LOCK_AND_IF . . . . . . . . . . . . . . . . . . 43
165 G.7 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY . . . . . 44
166 G.8 088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED . . . . . . . . . . 44
167 G.9 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION . . . . . . 45
168 G.10 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION . . . . . . . . . . 45
169 G.11 072_LOCK_URL_WITH_NO_PARENT_COLLECTION . . . . . . . . . . 45
170 G.12 044_REPORT_OTHER_RESOURCE_LOCKED . . . . . . . . . . . . . 46
171 G.13 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL . . . . . . . 46
172 G.14 015_MOVE_SECTION_6.4.1_TO_APPX . . . . . . . . . . . . . . 47
173 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
174 Intellectual Property and Copyright Statements . . . . . . . . 50
176 1. Introduction
178 This document describes the "locking" extension to the Web
179 Distributed Authoring and Versioning (WebDAV) protocol that allows to
180 keep more than one person from working on a document at the same
181 time. This helps preventing the "lost update problem," in which
182 modifications are lost as first one author then another writes
183 changes without merging the other author's changes.
185 1.1 Terminology
187 The terminology used here follows and extends that in the WebDAV
188 Distributed Authoring Protocol specification [RFC2518].
190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
192 document are to be interpreted as described in [RFC2119].
194 This document uses XML DTD fragments ([XML]) as a purely notational
195 convention. WebDAV request and response bodies cannot be validated
196 due to the specific extensibility rules defined in section 23 of
197 [RFC2518] and due to the fact that all XML elements defined by this
198 specification use the XML namespace name "DAV:". In particular:
200 o Element names use the "DAV:" namespace.
202 o Element ordering is irrelevant.
204 o Extension elements/attributes (elements/attributes not already
205 defined as valid child elements) may be added anywhere, except
206 when explicitly stated otherwise.
208 1.2 Method Preconditions and Postconditions
210 A "precondition" of a method describes the state on the server that
211 must be true for that method to be performed. A "postcondition" of a
212 method describes the state on the server that must be true after that
213 method has completed. If a method precondition or postcondition for
214 a request is not satisfied and unless a more specific HTTP status
215 code applies, the response status of the request MUST be either 403
216 (Forbidden) if the request should not be repeated because it will
217 always fail, or 409 (Conflict) if it is expected that the user might
218 be able to resolve the conflict and resubmit the request.
220 In order to allow better client handling of error responses, a
221 distinct XML element type is associated with each method precondition
222 and postcondition of a request. When a particular precondition is
223 not satisfied or a particular postcondition cannot be achieved, the
224 appropriate XML element MUST be returned as the child of a top-level
225 DAV:error element in the response body, unless otherwise negotiated
226 by the request. In a 207 Multi-Status response, the DAV:error
227 element would appear in the appropriate DAV:responsedescription
228 element.
230 2. Overview of Locking
232 3. Properties
234 The locking feature introduces the following properties for a
235 resource.
237 3.1 Common XML elements used in property values
239 3.1.1 Lock Scopes
241
242
243
245 3.1.2 Lock Types
247
248
250 At present, this specification only defines one lock type, the write
251 lock.
253 3.2 DAV:lockdiscovery property
255 The DAV:lockdiscovery property returns a listing of who has a lock,
256 what type of lock he has, the timeout type, the time remaining on the
257 timeout, the associated lock token and the root of the lock. The
258 server is free to withhold any or all of this information if the
259 requesting principal does not have sufficient access rights to see
260 the requested data.
262
264
267 depth: the value of the Depth header (see Appendix B.4.1; takes the
268 values "0", "1" or "infinity").
270
272 owner: provides information about the principal taking out a lock;
273 should be sufficient for either directly contacting a principal (such
274 as a telephone number or email URI), or for discovering the principal
275 (such as the URL of a homepage).
277
279 timeout: the timeout associated with a lock (defined in Appendix
280 B.4.3).
282
284 locktoken: the lock token associated with a lock; the href element
285 contains the lock token.
287
289 lockroot: the URL of the resource that was addressed in the LOCK
290 request; the href element contains the URL of the resource to which
291 the LOCK request has been applied.
293
295 href: defined in [RFC2518], section 12.3.
297
299 3.2.1 Examples for the DAV:lockdiscovery
300 DAV:lockdiscovery property for a resource that has two shared write
301 locks on it, with infinite timeouts:
303
304
305
306
307 0
308 Jane Smith
309 Infinite
310
311 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
313
314
315 http://example.com/container/
317
318
319
320
321
322
323
324 0
325 John Doe
326 Infinite
327
328 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d77
330
331
332 http://example.com/container/
334
335
336
338 DAV:lockdiscovery property for a resource with no locks on it:
340
342 3.3 DAV:supportedlock property
344 The DAV:supportedlock property of a resource returns a listing of the
345 combinations of scope and access types which may be specified in a
346 lock request on the resource. Note that the actual contents are
347 themselves controlled by access controls so a server is not required
348 to provide information the client is not authorized to see.
350
351
353 3.3.1 Examples for the DAV:supportedlock property
355 DAV:supportedlock property for a resource that supports both
356 exclusive and shares write locks:
358
359
360
361
362
363
364
365
366
367
369 DAV:supportedlock property for a resource that doesn't support any
370 locks at all:
372
374 4. LOCK Method
376 The following sections describe the LOCK method, which is used to
377 take out a lock of any access type or to refresh an existing lock.
379 4.1 Creating Locks
381 [[anchor13: TODO: move method description from appendix --reschke]]
383 4.1.1 Example - Simple Lock Request
385 >>Request
387 LOCK /workspace/webdav/proposal.doc HTTP/1.1
388 Host: example.com
389 Timeout: Infinite, Second-4100000000
390 Content-Type: text/xml; charset="utf-8"
391 Content-Length: xxxx
392 Authorization: Digest username="ejw",
393 realm="ejw@example.com", nonce="...",
394 uri="/workspace/webdav/proposal.doc",
395 response="...", opaque="..."
397
398
399
400
401
402 http://example.org/~ejw/contact.html
403
404
406 >>Response
408 HTTP/1.1 200 OK
409 Lock-Token:
410 Content-Type: text/xml; charset="utf-8"
411 Content-Length: xxxx
413
414
415
416
417
418
419 Infinity
420
421 http://example.org/~ejw/contact.html
423
424 Second-604800
425
426 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
428
429
430 http://example.com/workspace/webdav/proposal.doc
432
433
434
435
437 This example shows the successful creation of an exclusive write lock
438 on resource http://example.com/workspace/webdav/proposal.doc. The
439 resource http:/example.org/~ejw/contact.html contains contact
440 information for the owner of the lock. The server has an
441 activity-based timeout policy in place on this resource, which causes
442 the lock to automatically be removed after 1 week (604800 seconds).
444 4.1.2 Example - Multi-Resource Lock Request
446 >>Request
448 LOCK /webdav/ HTTP/1.1
449 Host: example.com
450 Timeout: Infinite, Second-4100000000
451 Depth: infinity
452 Content-Type: text/xml; charset="utf-8"
453 Content-Length: xxxx
454 Authorization: Digest username="ejw",
455 realm="ejw@example.com", nonce="...",
456 uri="/workspace/webdav/proposal.doc",
457 response="...", opaque="..."
459
460
461
462
463
464 http://example.org/~ejw/contact.html
465
466
468 >>Response
470 HTTP/1.1 207 Multi-Status
471 Content-Type: text/xml; charset="utf-8"
472 Content-Length: xxxx
474
475
476
477 /webdav/secret
478 HTTP/1.1 403 Forbidden
479
480
481 /webdav/
482 HTTP/1.1 424 Failed Dependency
483
484
486 This example shows a request for an exclusive write lock on a
487 collection and all its children. In this request, the client has
488 specified that it desires an infinite length lock, if available,
489 otherwise a timeout of 4.1 billion seconds, if available. The
490 request entity body contains the contact information for the
491 principal taking out the lock, in this case a web page URL.
493 The error is a 403 (Forbidden) response on the resource
494 http://example.com/webdav/secret. Because this resource could not be
495 locked, none of the resources were locked.
497 4.2 Refreshing Locks
499 A LOCK request with no request body is a "LOCK refresh" request.
500 It's purpose is to restart all timers associated with a lock.
502 If an error is received in response to a refresh LOCK request the
503 client SHOULD assume that the lock was not refreshed.
505 Marshalling:
507 The request MUST include an "If" header that contains the lock
508 tokens of the locks to be refreshed (note there may be multiple in
509 the case of shared locks).
511 The request MAY include a new "Timeout" header to be used as the
512 new timeout value for the lock(s) to be refreshed.
514 The response to a successful lock refresh request MUST contain the
515 value of the current DAV:lockdiscovery property in a prop XML
516 element.
518 Preconditions:
520 (DAV:lock-submission-allowed): see Section 7.1.
522 Postconditions:
524 (DAV:locks-refreshed): Timers associated with the those locks
525 submitted in the "If" request header whose lock root is the
526 resource identified by the request URI MUST be reset to their
527 original value (or alternatively to the new value given in the
528 "Timeout" request header).
530 4.2.1 Example - Refreshing a Write Lock
532 >>Request
534 LOCK /workspace/webdav/proposal.doc HTTP/1.1
535 Host: example.com
536 Timeout: Infinite, Second-4100000000
537 If: ()
538 Authorization: Digest username="ejw",
539 realm="ejw@example.com", nonce="...",
540 uri="/workspace/webdav/proposal.doc",
541 response="...", opaque="..."
543 >>Response
545 HTTP/1.1 200 OK
546 Content-Type: text/xml; charset="utf-8"
547 Content-Length: xxxx
549
550
551
552
553
554
555 Infinity
556
557 http://example.org/~ejw/contact.html
559
560 Second-604800
561
562 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
564
565
566 http://example.com/workspace/webdav/proposal.doc
568
569
570
571
573 This request would refresh the lock, resetting any time outs. Notice
574 that the client asked for an infinite time out but the server choose
575 to ignore the request.
577 5. UNLOCK Method
579 The UNLOCK method removes the lock identified by the lock token in
580 the Lock-Token request header from the resource identified by the
581 Request-URI, and all other resources included in the lock. Note that
582 the UNLOCK request may be submitted to any resource locked by that
583 lock (even those that are locked indirectly).
585 If all resources which have been locked under the submitted lock
586 token can not be unlocked then the UNLOCK request MUST fail.
588 Any DAV compliant resource which supports the LOCK method MUST
589 support the UNLOCK method.
591 A server MAY allow principals other than a lock owner to unlock a
592 resource. In this case, this capability SHOULD be under access
593 control (see [RFC3744], section 3.5). Note that there is a tradeoff
594 in allowing non-owners of a lock to unlock a resource. It can be
595 beneficial to allow non-lock owners to perform UNLOCK requests
596 because it allows the adminstrator of the server to configure the
597 server to grant longer lock timeouts because the administrator knows
598 that there is a process in place to allow users to deal with
599 forgotten locks left by other users. On the other hand, a
600 disadvantage of unlocking someone else's lock is that can create a
601 situation where two users are working on modifications to the same
602 resource at the same time which can result in a client having to
603 perform an merge that wasn't previously planned.
605 Marshalling:
607 The request MUST include a "Lock-Token" header (see Section 8.1)
608 that identifies the lock to be removed.
610 [[anchor17: Specify optional request body? --reschke]]
612 Preconditions:
614 (DAV:lock-token-matches): The lock identified by the "Lock-Token"
615 request header exists, and the resource identified by the request
616 URI indeed is directly locked by the specified lock.
618 (DAV:lock-removal-allowed): As dicussed above, the principal
619 authenticated for the UNLOCK request MUST be allowed to remove the
620 identified lock (note that servers that support the "WebDAV Access
621 Control Protocol" should use the DAV:need-privileges precondition
622 defined in section 7.1.1 of [RFC3744]).
624 Postconditions:
626 (DAV:lock-removed): The lock MUST have been removed from all
627 resources included in the lock.
629 5.1 Example - UNLOCK
631 >>Request
633 UNLOCK /workspace/webdav/info.doc HTTP/1.1
634 Host: example.com
635 Lock-Token:
636 Authorization: Digest username="ejw",
637 realm="ejw@example.com", nonce="...",
638 uri="/workspace/webdav/proposal.doc",
639 response="...", opaque="..."
641 >>Response
643 HTTP/1.1 204 No Content
645 In this example, the lock identified by the lock token
646 "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
647 successfully removed from the resource
648 http://example.com/workspace/webdav/info.doc. If this lock included
649 more than just one resource, the lock is removed from all resources
650 included in the lock. The 204 (No Content) status code is used
651 instead of 200 (OK) because there is no response entity body.
653 6. Additional status codes
655 6.1 423 Locked
657 The 423 (Locked) status code means the source or destination resource
658 of a method is locked.
660 7. Additional marshalling and method semantics for other methods
662 7.1 Additional marshalling
664 This section defines additional condition names (see Section 1.2)
665 that apply to all methods.
667 Preconditions:
669 (DAV:lock-submission-allowed): If the server restricts usage of
670 the lock token inside an "If" request header to specific
671 principals, the authenticated principal for this request MUST be
672 one of them.
674 (DAV:name-allowed): If a request such as COPY, LOCK, MOVE, PUT or
675 MKCOL is going to create a new internal member URI inside a
676 collection resource, the last path segment of that URI must
677 specify a name that is available as a resource name (for instance,
678 servers may disallow path segments that -- after being
679 URI-unescaped -- aren't valid UTF-8 octet sequences). [[anchor21:
680 Copied from draft-ietf-webdav-redirectref-protocol. --reschke]]
682 (DAV:parent-resource-must-be-non-null): If a request such as COPY,
683 LOCK, MOVE, PUT or MKCOL is going to create a new internal member
684 URI inside a collection resource, that collection resource must be
685 non-null. [[anchor22: Copied from
686 draft-ietf-webdav-redirectref-protocol. --reschke]]
688 7.2 Additional method semantics
690 8. Headers
692 8.1 Lock-Token request/response header
694 Lock-Token = "Lock-Token" ":" Coded-URL
696 Note that the "Coded-URL" production is defined in [RFC2518], section
697 9.4.
699 The Lock-Token request header is used with the UNLOCK method to
700 identify the lock to be removed. The lock token in the Lock-Token
701 request header MUST identify a lock that contains the resource
702 identified by Request-URI as a member.
704 The Lock-Token response header is used with the LOCK method to
705 indicate the lock token created as a result of a successful LOCK
706 request to create a new lock.
708 Note that the "Lock-Token" request header does not contribute to the
709 precondition checks defined for the HTTP status 412 (see [RFC2616],
710 section 10.4.13).
712 9. Capability discovery
714 9.1 OPTIONS method
716 If the server supports locking, it MUST return both the compliance
717 class names "2" and "locking" as fields in the "DAV" response header
718 (see [RFC2518], section 9.1) from an OPTIONS request on any resource
719 implemented by that server. A value of "2" or "locking" in the "DAV"
720 response header MUST indicate that the server meets all class "1"
721 requirements defined in [RFC2518] and supports all MUST level
722 requirements and REQUIRED features specified in this document,
723 including:
725 o LOCK and UNLOCK methods,
727 o DAV:lockdiscovery and DAV:supportedlock properties,
729 o "Time-Out" request header, "Lock-Token" request and response
730 header.
732 Note that for servers implementing this specification, the compliance
733 classes "2" and "locking" are synonymous. However, new clients can
734 take advantage of the new "locking" compliance class to detect server
735 support for changes introduced by this specification (see Appendix
736 A).
738 10. Security considerations
740 All security considerations mentioned in [RFC2518] also apply to this
741 document. Additionally, lock tokens introduce new privacy issues
742 discussed below.
744 10.1 Privacy Issues Connected to Locks
746 When submitting a lock request a user agent may also submit an owner
747 XML field giving contact information for the person taking out the
748 lock (for those cases where a person, rather than a robot, is taking
749 out the lock). This contact information is stored in a
750 DAV:lockdiscovery property on the resource, and can be used by other
751 collaborators to begin negotiation over access to the resource.
752 However, in many cases this contact information can be very private,
753 and should not be widely disseminated. Servers SHOULD limit read
754 access to the DAV:lockdiscovery property as appropriate.
755 Furthermore, user agents SHOULD provide control over whether contact
756 information is sent at all, and if contact information is sent,
757 control over exactly what information is sent.
759 11. Internationalization Considerations
761 All internationalization considerations mentioned in [RFC2518] also
762 apply to this document.
764 12. IANA Considerations
766 This specification updates the definition of the "opaquelocktoken"
767 URI scheme described in Appendix D, registered my means of [RFC2518],
768 section 6.4. There are no additional IANA considerations.
770 13. Acknowledgements
772 This document is the collaborative product of
774 o the authors,
776 o the maintainers of RFC2518bis - Jason Crawford and Lisa Dusseault
777 - and
779 o the original authors of RFC2518 - Steve Carter, Asad Faizi, Yaron
780 Goland, Del Jensen and Jim Whitehead.
782 This document has also benefited from thoughtful discussion by Mark
783 Anderson, Dan Brotksy, Geoff Clemm, Jim Davis, Stefan Eissing,
784 Rickard Falk, Larry Masinter, Joe Orton, Juergen Pill, Elias
785 Sinderson, Greg Stein, Kevin Wiggen, and other members of the WebDAV
786 working group.
788 14. References
790 14.1 Normative References
792 [ISO-11578]
793 International Organization for Standardization, "ISO/IEC
794 11578:1996. Information technology - Open Systems
795 Interconnection - Remote Procedure Call (RPC)", 1996.
797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
798 Requirement Levels", BCP 14, RFC 2119, March 1997.
800 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
801 Resource Identifiers (URI): Generic Syntax", RFC 2396,
802 August 1998.
804 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
805 Jensen, "HTTP Extensions for Distributed Authoring --
806 WEBDAV", RFC 2518, February 1999.
808 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
809 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
810 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
812 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
813 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
814 Edition)", W3C REC-xml-20040204, February 2004,
815 .
817 14.2 Informative References
819 [RFC3744] Clemm, G., Reschke, J., Sedlar, E. and J. Whitehead, "Web
820 Distributed Authoring and Versioning (WebDAV) Access
821 Control Protocol", RFC 3744, May 2004.
823 URIs
825 [1]
827 [2]
829 Author's Address
831 Julian F. Reschke
832 greenbytes GmbH
833 Salzmannstrasse 152
834 Muenster, NW 48159
835 Germany
837 Phone: +49 251 2807760
838 Fax: +49 251 2807761
839 EMail: julian.reschke@greenbytes.de
840 URI: http://greenbytes.de/tech/webdav/
842 Appendix A. Changes to RFC2518
844 See Section 9 for a description about how clients can discover
845 support for this version of the WebDAV Locking protocol.
847 A.1 Removed/Deprecated features
849 A.1.1 Implicit lock refresh
851 In section 9.8, [RFC2518] specifies that locks should be refreshed
852 implicitly every time "...any time an owner of the lock sends a
853 method to any member of the lock, including unsupported methods, or
854 methods which are unsuccessful." This features has been removed
855 (locks need to be refreshed explicitly using the LOCK method).
857 Compatibility considerations
859 Clients historically have never relied on this feature as it was
860 never implemented in widely deployed WebDAV servers.
862 A.1.2 Lock-null resources
864 In section 7.4, [RFC2518] specifies a special resource type called
865 "lock-null resource" that's being created when a LOCK method request
866 is applied to a null resource. In practice, no real interoperability
867 was achieved because many servers failed to implement this feature
868 properly and few clients (if any) ever relied on that particular
869 functionality.
871 Removing this feature also means that there is no atomic way to
872 create a collection in locked state, but in practice, this doesn't
873 seem to be a problem.
875 Compatibility considerations
877 There do not seem to be any widely deployed clients that actually
878 relied on "lock-null resources".
880 A.2 Additional features
882 A.2.1 DAV:lockroot element in DAV:activelock
884 Clients can take advantage of the new DAV:lockroot element to
885 discover the URL to which the LOCK request (that created the lock)
886 was applied.
888 Compatibility consideration
890 Clients will have to fail gracefully when communicating with older
891 servers that do not support the new property.
893 Appendix B. Text to be integrated from RFC2518
895 B.1 Locking
897 The ability to lock a resource provides a mechanism for serializing
898 access to that resource. Using a lock, an authoring client can
899 provide a reasonable guarantee that another principal will not modify
900 a resource while it is being edited. In this way, a client can
901 prevent the "lost update" problem.
903 This specification allows locks to vary over two client-specified
904 parameters, the number of principals involved (exclusive vs. shared)
905 and the type of access to be granted. This document defines locking
906 for only one access type, write. However, the syntax is extensible,
907 and permits the eventual specification of locking for other access
908 types.
910 B.1.1 Exclusive Vs. Shared Locks
912 The most basic form of lock is an exclusive lock. This is a lock
913 where the access right in question is only granted to a single
914 principal. The need for this arbitration results from a desire to
915 avoid having to merge results.
917 However, there are times when the goal of a lock is not to exclude
918 others from exercising an access right but rather to provide a
919 mechanism for principals to indicate that they intend to exercise
920 their access rights. Shared locks are provided for this case. A
921 shared lock allows multiple principals to receive a lock. Hence any
922 principal with appropriate access can get the lock.
924 With shared locks there are two trust sets that affect a resource.
925 The first trust set is created by access permissions. Principals who
926 are trusted, for example, may have permission to write to the
927 resource. Among those who have access permission to write to the
928 resource, the set of principals who have taken out a shared lock also
929 must trust each other, creating a (typically) smaller trust set
930 within the access permission write set.
932 Starting with every possible principal on the Internet, in most
933 situations the vast majority of these principals will not have write
934 access to a given resource. Of the small number who do have write
935 access, some principals may decide to guarantee their edits are free
936 from overwrite conflicts by using exclusive write locks. Others may
937 decide they trust their collaborators will not overwrite their work
938 (the potential set of collaborators being the set of principals who
939 have write permission) and use a shared lock, which informs their
940 collaborators that a principal may be working on the resource.
942 The WebDAV extensions to HTTP do not need to provide all of the
943 communications paths necessary for principals to coordinate their
944 activities. When using shared locks, principals may use any out of
945 band communication channel to coordinate their work (e.g.,
946 face-to-face interaction, written notes, post-it notes on the screen,
947 telephone conversation, Email, etc.) The intent of a shared lock is
948 to let collaborators know who else may be working on a resource.
950 Shared locks are included because experience from web distributed
951 authoring systems has indicated that exclusive locks are often too
952 rigid. An exclusive lock is used to enforce a particular editing
953 process: take out an exclusive lock, read the resource, perform
954 edits, write the resource, release the lock. This editing process
955 has the problem that locks are not always properly released, for
956 example when a program crashes, or when a lock owner leaves without
957 unlocking a resource. While both timeouts and administrative action
958 can be used to remove an offending lock, neither mechanism may be
959 available when needed; the timeout may be long or the administrator
960 may not be available. With a shared lock, another user can at least
961 take out another shared lock and start modifying the resource.
963 B.1.2 Required Support
965 A WebDAV compliant server is not required to support locking in any
966 form. If the server does support locking it may choose to support
967 any combination of exclusive and shared locks for any access types.
969 The reason for this flexibility is that locking policy strikes to the
970 very heart of the resource management and versioning systems employed
971 by various storage repositories. These repositories require control
972 over what sort of locking will be made available. For example, some
973 repositories only support shared write locks while others only
974 provide support for exclusive write locks while yet others use no
975 locking at all. As each system is sufficiently different to merit
976 exclusion of certain locking features, this specification leaves
977 locking as the sole axis of negotiation within WebDAV.
979 B.1.3 Lock Tokens
981 A lock token is a type of state token, represented as a URI, which
982 identifies a particular lock. A lock token is returned by every
983 successful LOCK operation in the DAV:lockdiscovery property in the
984 response body, and can also be found through lock discovery on a
985 resource.
987 Lock token URIs MUST be unique across all resources for all time.
988 This uniqueness constraint allows lock tokens to be submitted across
989 resources and servers without fear of confusion.
991 This specification provides a lock token URI scheme called
992 "opaquelocktoken" that meets the uniqueness requirements. However
993 resources are free to return any URI scheme so long as it meets the
994 uniqueness requirements.
996 Submitting a lock token provides no special access rights. Anyone
997 can find out anyone else's lock token by performing lock discovery.
998 Locks MUST be enforced based upon whatever authentication mechanism
999 is used by the server, not based on the secrecy of the token values.
1001 B.1.4 Lock Capability Discovery
1003 Since server lock support is optional, a client trying to lock a
1004 resource on a server can either try the lock and hope for the best,
1005 or perform some form of discovery to determine what lock capabilities
1006 the server supports. This is known as lock capability discovery.
1007 Lock capability discovery differs from discovery of supported access
1008 control types, since there may be access control types without
1009 corresponding lock types. A client can determine what lock types the
1010 server supports by retrieving the DAV:supportedlock property.
1012 Any DAV compliant resource that supports the LOCK method MUST support
1013 the DAV:supportedlock property.
1015 B.1.5 Active Lock Discovery
1017 If another principal locks a resource that a principal wishes to
1018 access, it is useful for the second principal to be able to find out
1019 who the first principal is. For this purpose the DAV:lockdiscovery
1020 property is provided. This property lists all outstanding locks,
1021 describes their type, and where available, provides their lock token.
1023 Any DAV compliant resource that supports the LOCK method MUST support
1024 the DAV:lockdiscovery property.
1026 B.1.6 Usage Considerations
1028 Although the locking mechanisms specified here provide some help in
1029 preventing lost updates, they cannot guarantee that updates will
1030 never be lost. Consider the following scenario:
1032 o Two clients A and B are interested in editing the resource
1033 'index.html'. Client A is an HTTP client rather than a WebDAV
1034 client, and so does not know how to perform locking.
1036 o Client A doesn't lock the document, but does a GET and begins
1037 editing.
1039 o Client B does LOCK, performs a GET and begins editing.
1041 o Client B finishes editing, performs a PUT, then an UNLOCK.
1043 o Client A performs a PUT, overwriting and losing all of B's
1044 changes.
1046 There are several reasons why the WebDAV protocol itself cannot
1047 prevent this situation. First, it cannot force all clients to use
1048 locking because it must be compatible with HTTP clients that do not
1049 comprehend locking. Second, it cannot require servers to support
1050 locking because of the variety of repository implementations, some of
1051 which rely on reservations and merging rather than on locking.
1053 Finally, being stateless, it cannot enforce a sequence of operations
1054 like LOCK / GET / PUT / UNLOCK.
1056 WebDAV servers that support locking can reduce the likelihood that
1057 clients will accidentally overwrite each other's changes by requiring
1058 clients to lock resources before modifying them. Such servers would
1059 effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying
1060 resources.
1062 WebDAV clients can be good citizens by using a lock / retrieve /
1063 write /unlock sequence of operations (at least by default) whenever
1064 they interact with a WebDAV server that supports locking.
1066 HTTP 1.1 clients can be good citizens, avoiding overwriting other
1067 clients' changes, by using entity tags in If-Match headers with any
1068 requests that would modify resources.
1070 Information managers may attempt to prevent overwrites by
1071 implementing client-side procedures requiring locking before
1072 modifying WebDAV resources.
1074 B.2 Write Lock
1076 This section describes the semantics specific to the write lock type.
1077 The write lock is a specific instance of a lock type, and is the only
1078 lock type described in this specification.
1080 B.2.1 Methods Restricted by Write Locks
1082 If a request would modify the content for a locked resource, a dead
1083 property of a locked resource, a live property that is defined to be
1084 lockable for a locked resource, or an internal member URI of a locked
1085 collection, the request MUST fail unless the lock-token for that lock
1086 is submitted in the request. An internal member URI of a collection
1087 is considered to be modified if it is added, removed, or identifies a
1088 different resource. [[anchor41: Copy of GULP, "Locked State".
1089 --reschke]]
1091 B.2.2 Write Locks and Lock Tokens
1093 A successful request for an exclusive or shared write lock MUST
1094 result in the generation of a unique lock token associated with the
1095 requesting principal. Thus if five principals have a shared write
1096 lock on the same resource there will be five lock tokens, one for
1097 each principal.
1099 B.2.3 Write Locks and Properties
1101 While those without a write lock may not alter a property on a
1102 resource it is still possible for the values of live properties to
1103 change, even while locked, due to the requirements of their schemas.
1104 Only dead properties and live properties defined to respect locks are
1105 guaranteed not to change while write locked.
1107 B.2.4 Write Locks and Collections
1109 A write lock on a collection, whether created by a "Depth: 0" or
1110 "Depth: infinity" lock request, prevents the addition or removal of
1111 member URIs of the collection by non-lock owners. As a consequence,
1112 when a principal issues a PUT or POST request to create a new
1113 resource under a URI which needs to be an internal member of a write
1114 locked collection to maintain HTTP namespace consistency, or issues a
1115 DELETE to remove an internal member URI of a write locked collection,
1116 this request MUST fail if the principal does not have a write lock on
1117 the collection.
1119 However, if a write lock request is issued to a collection containing
1120 member URIs identifying resources that are currently locked in a
1121 manner which conflicts with the write lock, the request MUST fail
1122 with a 423 (Locked) status code (Note that this can only occur for a
1123 request of a "Depth: infinity" write lock).
1125 If a lock owner causes the URI of a resource to be added as an
1126 internal member URI of a "Depth: infinity" locked collection then
1127 the new resource MUST be automatically added to the lock. This is
1128 the only mechanism that allows a resource to be added to a write
1129 lock. Thus, for example, if the collection /a/b/ is write locked and
1130 the resource /c is moved to /a/b/c then resource /a/b/c will be added
1131 to the write lock.
1133 B.2.5 Write Locks and the If Request Header
1135 If a user agent is not required to have knowledge about a lock when
1136 requesting an operation on a locked resource, the following scenario
1137 might occur. Program A, run by User A, takes out a write lock on a
1138 resource. Program B, also run by User A, has no knowledge of the
1139 lock taken out by Program A, yet performs a PUT to the locked
1140 resource. In this scenario, the PUT succeeds because locks are
1141 associated with a principal, not a program, and thus program B,
1142 because it is acting with principal A's credential, is allowed to
1143 perform the PUT. However, had program B known about the lock, it
1144 would not have overwritten the resource, preferring instead to
1145 present a dialog box describing the conflict to the user. Due to
1146 this scenario, a mechanism is needed to prevent different programs
1147 from accidentally ignoring locks taken out by other programs with the
1148 same authorization.
1150 In order to prevent these collisions a lock token MUST be submitted
1151 in the If header for all locked resources that a method may interact
1152 with or the method MUST fail. For example, if a resource is to be
1153 moved and both the source and destination are locked then two lock
1154 tokens must be submitted, one for the source and the other for the
1155 destination.
1157 Servers SHOULD restrict usage of the lock token to exactly the
1158 authenticated principal who created the lock.
1160 B.2.5.1 Example - Write Lock
1162 >>Request
1164 COPY /~fielding/index.html HTTP/1.1
1165 Host: example.com
1166 Destination: http://example.com/users/f/fielding/index.html
1167 If:
1168 ()
1170 >>Response
1172 HTTP/1.1 204 No Content
1174 In this example, even though both the source and destination are
1175 locked, only one lock token must be submitted, for the lock on the
1176 destination. This is because the source resource is not modified by
1177 a COPY, and hence unaffected by the write lock. In this example,
1178 user agent authentication has previously occurred via a mechanism
1179 outside the scope of the HTTP protocol, in the underlying transport
1180 layer.
1182 B.2.6 Write Locks and COPY/MOVE
1184 A COPY method invocation MUST NOT duplicate any write locks active on
1185 the source. However, as previously noted, if the COPY copies the
1186 resource into a collection that is locked with "Depth: infinity",
1187 then the resource will be added to the lock.
1189 A successful MOVE request on a write locked resource MUST NOT move
1190 the write lock with the resource. However, the resource is subject
1191 to being added to an existing lock at the destination, as specified
1192 in Appendix B.2.4. For example, if the MOVE makes the resource a
1193 child of a collection that is locked with "Depth: infinity", then the
1194 resource will be added to that collection's lock. Additionally, if a
1195 resource locked with "Depth: infinity" is moved to a destination that
1196 is within the scope of the same lock (e.g., within the namespace tree
1197 covered by the lock), the moved resource will again be a added to the
1198 lock. In both these examples, as specified in Appendix B.2.5, an If
1199 header must be submitted containing a lock token for both the source
1200 and destination.
1202 B.2.7 Refreshing Write Locks
1204 [[anchor47: Just state that locks can be refreshed and point to
1205 actual method description. --reschke]]
1207 B.3 HTTP Methods for Distributed Authoring
1209 B.3.1 LOCK Method
1211 B.3.1.1 Operation
1213 [[anchor51: Make sure updated method description discusses applying
1214 LOCK to null resources. --reschke]]
1216 A LOCK method invocation creates the lock specified by the lockinfo
1217 XML element on the resource identified by the Request-URI. Lock
1218 method requests SHOULD have a XML request body which contains an
1219 owner XML element for this lock request, unless this is a refresh
1220 request. The LOCK request may have a Timeout header.
1222 Clients MUST assume that locks may arbitrarily disappear at any time,
1223 regardless of the value given in the Timeout header. The Timeout
1224 header only indicates the behavior of the server if "extraordinary"
1225 circumstances do not occur. For example, an administrator may remove
1226 a lock at any time or the system may crash in such a way that it
1227 loses the record of the lock's existence. The response for a
1228 successful LOCK creation request MUST contain the value of the
1229 DAV:lockdiscovery property in a prop XML element.
1231 In order to indicate the lock token associated with a newly created
1232 lock, a Lock-Token response header MUST be included in the response
1233 for every successful LOCK request for a new lock. Note that the
1234 Lock-Token header would not be returned in the response for a
1235 successful refresh LOCK request because a new lock was not created.
1237 B.3.1.2 The Effect of Locks on Properties and Collections
1239 The scope of a lock is the entire state of the resource, including
1240 its body and associated properties. As a result, a lock on a
1241 resource MUST also lock the resource's properties.
1243 For collections, a lock also affects the ability to add or remove
1244 members. The nature of the effect depends upon the type of access
1245 control involved.
1247 B.3.1.3 Locking Replicated Resources
1249 A resource may be made available through more than one URI. However
1250 locks apply to resources, not URIs. Therefore a LOCK request on a
1251 resource MUST NOT succeed if can not be honored by all the URIs
1252 through which the resource is addressable.
1254 B.3.1.4 Depth and Locking
1256 The Depth header may be used with the LOCK method. Values other than
1257 0 or infinity MUST NOT be used with the Depth header on a LOCK
1258 method. All resources that support the LOCK method MUST support the
1259 Depth header.
1261 A Depth header of value 0 means to just lock the resource specified
1262 by the Request-URI.
1264 If the Depth header is set to infinity then the resource specified in
1265 the Request-URI along with all its internal members, all the way down
1266 the hierarchy, are to be locked. A successful result MUST return a
1267 single lock token which represents all the resources that have been
1268 locked. If an UNLOCK is successfully executed on this token, all
1269 associated resources are unlocked. If the lock cannot be granted to
1270 all resources, a 207 (Multistatus) status code MUST be returned with
1271 a response entity body containing a multistatus XML element
1272 describing which resource(s) prevented the lock from being granted.
1273 Hence, partial success is not an option. Either the entire hierarchy
1274 is locked or no resources are locked.
1276 If no Depth header is submitted on a LOCK request then the request
1277 MUST act as if a "Depth:infinity" had been submitted.
1279 B.3.1.5 Interaction with other Methods
1281 The interaction of a LOCK with various methods is dependent upon the
1282 lock type. However, independent of lock type, a successful DELETE of
1283 a resource MUST cause all of its locks to be removed.
1285 B.3.1.6 Lock Compatibility Table
1287 The table below describes the behavior that occurs when a lock
1288 request is made on a resource.
1290 +-------------------------+--------------------+--------------------+
1291 | Current lock state / | Shared Lock | Exclusive Lock |
1292 | Lock request | | |
1293 +-------------------------+--------------------+--------------------+
1294 | None | True | True |
1295 | Shared Lock | True | False |
1296 | Exclusive Lock | False | False* |
1297 +-------------------------+--------------------+--------------------+
1299 Legend: True = lock may be granted. False = lock MUST NOT be
1300 granted. *=It is illegal for a principal to request the same lock
1301 twice.
1303 The current lock state of a resource is given in the leftmost column,
1304 and lock requests are listed in the first row. The intersection of a
1305 row and column gives the result of a lock request. For example, if a
1306 shared lock is held on a resource, and an exclusive lock is
1307 requested, the table entry is "false", indicating the lock must not
1308 be granted.
1310 B.3.1.7 Status Codes
1312 200 (OK) - The lock request succeeded and the value of the
1313 DAV:lockdiscovery property is included in the body.
1315 412 (Precondition Failed) - The included lock token was not
1316 enforceable on this resource or the server could not satisfy the
1317 request in the lockinfo XML element.
1319 423 (Locked) - The resource is locked, so the method has been
1320 rejected.
1322 B.4 HTTP Headers for Distributed Authoring
1324 B.4.1 Depth Header
1326 [[anchor58: Add "Depth" header considerations: --reschke]]
1328 If a resource, source or destination, within the scope of the method
1329 with a Depth header is locked in such a way as to prevent the
1330 successful execution of the method, then the lock token for that
1331 resource MUST be submitted with the request in the If request header.
1333 B.4.2 If Header
1335 [[anchor59: Add "If" header considerations: --reschke]]
1337 B.4.3 Timeout Request Header
1339 TimeOut = "Timeout" ":" 1#TimeType
1340 TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
1341 DAVTimeOutVal = 1*digit
1342 Other = "Extend" field-value ; See section 4.2 of [RFC2616]
1344 [[anchor60: Discussion of timeout behaviour should move somewhere
1345 else. Keep only the actual syntax description here. --reschke]]
1346 Clients may include Timeout headers in their LOCK requests. However,
1347 the server is not required to honor or even consider these requests.
1348 Clients MUST NOT submit a Timeout request header with any method
1349 other than a LOCK method.
1351 A Timeout request header MUST contain at least one TimeType and may
1352 contain multiple TimeType entries. The purpose of listing multiple
1353 TimeType entries is to indicate multiple different values and value
1354 types that are acceptable to the client. The client lists the
1355 TimeType entries in order of preference.
1357 Timeout response values MUST use a Second value, Infinite, or a
1358 TimeType the client has indicated familiarity with. The server may
1359 assume a client is familiar with any TimeType submitted in a Timeout
1360 header.
1362 The "Second" TimeType specifies the number of seconds that will
1363 elapse between granting of the lock at the server, and the automatic
1364 removal of the lock. The timeout value for TimeType "Second" MUST
1365 NOT be greater than 2^32-1.
1367 If the timeout expires then the lock may be lost. Specifically, if
1368 the server wishes to harvest the lock upon time-out, the server
1369 SHOULD act as if an UNLOCK method was executed by the server on the
1370 resource using the lock token of the timed-out lock, performed with
1371 its override authority. Thus logs should be updated with the
1372 disposition of the lock, notifications should be sent, etc., just as
1373 they would be for an UNLOCK request.
1375 Servers are advised to pay close attention to the values submitted by
1376 clients, as they will be indicative of the type of activity the
1377 client intends to perform. For example, an applet running in a
1378 browser may need to lock a resource, but because of the instability
1379 of the environment within which the applet is running, the applet may
1380 be turned off without warning. As a result, the applet is likely to
1381 ask for a relatively small timeout value so that if the applet dies,
1382 the lock can be quickly harvested. However, a document management
1383 system is likely to ask for an extremely long timeout because its
1384 user may be planning on going off-line.
1386 A client MUST NOT assume that just because the time-out has expired
1387 the lock has been lost.
1389 B.5 XML Element Definitions
1391 B.5.1 lockinfo XML Element
1393 Name: lockinfo
1395 Namespace: DAV:
1397 Purpose: The lockinfo XML element is used with a LOCK method to
1398 specify the type of lock the client wishes to have created.
1400
1402 Appendix C. GULP
1404 *Copied from
1405 *
1406 .
1408 C.1 Directly vs Indirectly
1410 A lock either directly or indirectly locks a resource.
1412 C.2 Creating Locks
1414 A LOCK request with a non-empty body creates a new lock, and the
1415 resource identified by the request-URL is directly locked by that
1416 lock. The "lock-root" of the new lock is the request-URL. If at the
1417 time of the request, the request-URL is not mapped to a resource, a
1418 new resource with empty content MUST be created by the request.
1420 C.3 Lock Inheritance
1422 If a collection is directly locked by a depth:infinity lock, all
1423 members of that collection (other than the collection itself) are
1424 indirectly locked by that lock. In particular, if an internal member
1425 resource is added to a collection that is locked by a depth:infinity
1426 lock, and if the resource is not locked by that lock, then the
1427 resource becomes indirectly locked by that lock. Conversely, if a
1428 resource is indirectly locked with a depth:infinity lock, and if the
1429 result of deleting an internal member URI is that the resource is no
1430 longer a member of the collection that is directly locked by that
1431 lock, then the resource is no longer locked by that lock.
1433 C.4 Removing Locks
1435 An UNLOCK request deletes the lock with the specified lock token.
1436 The request-URL of the request MUST identify a resource that is
1437 either directly or indirectly locked by that lock. After a lock is
1438 deleted, no resource is locked by that lock.
1440 C.5 Submitting Lock Tokens
1442 A lock token is "submitted" in a request when it appears in an "If"
1443 request header.
1445 C.6 Locked State
1447 If a request would modify the content for a locked resource, a dead
1448 property of a locked resource, a live property that is defined to be
1449 lockable for a locked resource, or an internal member URI of a locked
1450 collection, the request MUST fail unless the lock-token for that lock
1451 is submitted in the request. An internal member URI of a collection
1452 is considered to be modified if it is added, removed, or identifies a
1453 different resource.
1455 C.7 URL protection
1457 If a request causes a directly locked resource to no longer be mapped
1458 to the lock-root of that lock, then the request MUST fail unless the
1459 lock-token for that lock is submitted in the request. If the request
1460 succeeds, then that lock MUST have been deleted by that request.
1462 C.8 Exclusive vs Shared
1464 If a request would cause a resource to be locked by two different
1465 exclusive locks, the request MUST fail.
1467 Appendix D. 'opaquelocktoken' URI Scheme
1469 The opaquelocktoken URI scheme is designed to be unique across all
1470 resources for all time. Due to this uniqueness quality, a client may
1471 submit an opaque lock token in an If header on a resource other than
1472 the one that returned it.
1474 All resources MUST recognize the opaquelocktoken scheme and, at
1475 minimum, recognize that the lock token does not refer to an
1476 outstanding lock on the resource.
1478 In order to guarantee uniqueness across all resources for all time
1479 the opaquelocktoken requires the use of the Universal Unique
1480 Identifier (UUID) mechanism, as described in [ISO-11578].
1482 Opaquelocktoken generators, however, have a choice of how they create
1483 these tokens. They can either generate a new UUID for every lock
1484 token they create or they can create a single UUID and then add
1485 extension characters. If the second method is selected then the
1486 program generating the extensions MUST guarantee that the same
1487 extension will never be used twice with the associated UUID.
1489 OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID
1490 production is the string representation of a UUID, as defined in
1491 [ISO-11578]. Note that white space (LWS) is not allowed between
1492 elements of this production.
1494 Extension = path ; path is defined in [RFC2396], section 3.3.
1496 D.1 Node Field Generation Without the IEEE 802 Address
1498 UUIDs, as defined in [ISO-11578], contain a "node" field that
1499 contains one of the IEEE 802 addresses for the server machine. As
1500 noted in Section 10.1, there are several security risks associated
1501 with exposing a machine's IEEE 802 address. This section provides an
1502 alternate mechanism for generating the "node" field of a UUID which
1503 does not employ an IEEE 802 address. WebDAV servers MAY use this
1504 algorithm for creating the node field when generating UUIDs. The
1505 text in this section is originally from an Internet-Draft by Paul
1506 Leach and Rich Salz, who are noted here to properly attribute their
1507 work.
1509 The ideal solution is to obtain a 47 bit cryptographic quality random
1510 number, and use it as the low 47 bits of the node ID, with the most
1511 significant bit of the first octet of the node ID set to 1. This bit
1512 is the unicast/multicast bit, which will never be set in IEEE 802
1513 addresses obtained from network cards; hence, there can never be a
1514 conflict between UUIDs generated by machines with and without network
1515 cards.
1517 If a system does not have a primitive to generate cryptographic
1518 quality random numbers, then in most systems there are usually a
1519 fairly large number of sources of randomness available from which one
1520 can be generated. Such sources are system specific, but often
1521 include:
1523 o the percent of memory in use
1525 o the size of main memory in bytes
1527 o the amount of free main memory in bytes
1529 o the size of the paging or swap file in bytes
1531 o free bytes of paging or swap file
1533 o the total size of user virtual address space in bytes
1535 o the total available user address space bytes
1537 o the size of boot disk drive in bytes
1539 o the free disk space on boot drive in bytes
1541 o the current time
1543 o the amount of time since the system booted
1545 o the individual sizes of files in various system directories
1547 o the creation, last read, and modification times of files in
1548 various system directories
1550 o the utilization factors of various system resources (heap, etc.)
1552 o current mouse cursor position
1554 o current caret position
1556 o current number of running processes, threads
1558 o handles or IDs of the desktop window and the active window
1560 o the value of stack pointer of the caller
1562 o the process and thread ID of caller
1564 o various processor architecture specific performance counters
1565 (instructions executed, cache misses, TLB misses)
1567 (Note that it is precisely the above kinds of sources of randomness
1568 that are used to seed cryptographic quality random number generators
1569 on systems without special hardware for their construction.)
1570 In addition, items such as the computer's name and the name of the
1571 operating system, while not strictly speaking random, will help
1572 differentiate the results from those obtained by other systems.
1574 The exact algorithm to generate a node ID using these data is system
1575 specific, because both the data available and the functions to obtain
1576 them are often very system specific. However, assuming that one can
1577 concatenate all the values from the randomness sources into a buffer,
1578 and that a cryptographic hash function such as MD5 is available, then
1579 any 6 bytes of the MD5 hash of the buffer, with the multicast bit
1580 (the high bit of the first byte) set will be an appropriately random
1581 node ID.
1583 Other hash functions, such as SHA-1, can also be used. The only
1584 requirement is that the result be suitably random in the sense that
1585 the outputs from a set uniformly distributed inputs are themselves
1586 uniformly distributed, and that a single bit change in the input can
1587 be expected to cause half of the output bits to change.
1589 Appendix E. Change Log (to be removed by RFC Editor before publication)
1591 E.1 Since draft-reschke-webdav-locking-00
1593 Add and resolve issue "rfc2606-compliance". Resolve issues
1594 "extract-locking", "updated-rfc2068", "022_COPY_OVERWRITE_LOCK_NULL",
1595 "025_LOCK_REFRESH_BY_METHODS", "037_DEEP_LOCK_ERROR_STATUS",
1596 "039_MISSING_LOCK_TOKEN", "040_LOCK_ISSUES_01", "040_LOCK_ISSUES_02",
1597 "040_LOCK_ISSUES_05", "043_NULL_LOCK_SLASH_URL",
1598 "065_UNLOCK_WHAT_URL", "077_LOCK_NULL_STATUS_CREATION",
1599 "080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC",
1600 "089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK",
1601 "101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS",
1602 "109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK" and
1603 "111_MULTIPLE_TOKENS_PER_LOCK". Add issue "import-gulp". Start work
1604 on moving text from RFC2518 excerpts into new sections. Define new
1605 compliance class "locking" (similar to "bis" in RFC2518bis, but only
1606 relevant to locking). Reformatted "GULP" into separate subsections
1607 for easier reference.
1609 E.2 Since draft-reschke-webdav-locking-01
1611 Update "008_URI_URL", "040_LOCK_ISSUES_06",
1612 "063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY",
1613 "067_UNLOCK_NEEDS_IF_HEADER", "068_UNLOCK_WITHOUT_GOOD_TOKEN".
1614 Re-opened "065_UNLOCK_WHAT_URL". Close
1615 "070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER". Rewrite UNLOCK and LOCK
1616 refresh method descriptions. Fix page title (TXT version). Close
1617 "052_LOCK_BODY_SHOULD_BE_MUST", "054_IF_AND_AUTH",
1618 "060_LOCK_REFRESH_BODY" and "079_UNLOCK_BY_NON_LOCK_OWNER". Add and
1619 resolve "8.10.1_lockdiscovery_on_failure". Started attempt to
1620 clarify status code.
1622 E.3 Since draft-reschke-webdav-locking-02
1624 Resolve issues "040_LOCK_ISSUES_03", "040_LOCK_ISSUES_04",
1625 "040_LOCK_ISSUES_08" "053_LOCK_INHERITANCE", "057_LOCK_SEMANTICS",
1626 "067_UNLOCK_NEEDS_IF_HEADER" and "068_UNLOCK_WITHOUT_GOOD_TOKEN".
1627 Resolve issue "065_UNLOCK_WHAT_URL"; update to new GULP version
1628 (5.7). Add and resolve new issue "7.5_DELETE_vs_URIs". Start work
1629 on "additional marshalling" and "introduction". Update issues
1630 "044_REPORT_OTHER_RESOURCE_LOCKED" and
1631 "066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL".
1633 Appendix F. Resolved issues (to be removed by RFC Editor before
1634 publication)
1636 Issues that were either rejected or resolved in this version of this
1637 document.
1639 F.1 065_UNLOCK_WHAT_URL
1641 Type: change
1643
1645 Juergen.Pill@softwareag.com (2001-03-01): What do you return if the
1646 unlock request specifies a URL on which the lock does not reside?
1647 What if it's on a URL that is locked by the lock, but it's not the
1648 resource where the lock is rooted?
1650 julian.reschke@greenbytes.de (2004-06-01): New discussion, resolution
1651 pending. See
1652 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0120.html.
1654 Resolution (2004-06-12): Resolution (as of May 31, 2004) from RFC2518
1655 issues list: Resolved that you can specify any URL locked by the lock
1656 you want to unlock.
1657 (http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0027.html)
1658 We should resolve the issue of UNLOCK'ing other URLs in a few days.
1659 See also
1660 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0170.html.
1662 F.2 067_UNLOCK_NEEDS_IF_HEADER
1664 Type: change
1666
1668 dbrotsky@Adobe.COM (): Shouldn't we be using an IF header to do an
1669 UNLOCK seeing as you need to prove you are holding a lock before you
1670 can remove it? (This might be contingent on
1671 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY)
1673 Resolution: Testing of current implementations shows that servers
1674 indeed use the "Lock-Token" request header to specify the lock to be
1675 removed; and that they do not require an additional "If" header. No
1676 change. See also
1677 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0178.html.
1679 F.3 068_UNLOCK_WITHOUT_GOOD_TOKEN
1681 Type: change
1683
1685 dbrotsky@Adobe.COM (): What should UNLOCK return if a bad token is
1686 provided or no token. (This might be contingent on
1687 UNLOCK_NEEDS_IF_HEADER.)
1689 julian.reschke@greenbytes.de (2004-06-06): According to the rewritten
1690 description, this will be a 4xx with condition code
1691 DAV:lock-token-matches. Check the status codes for existing
1692 implementations, though.
1694 julian.reschke@greenbytes.de (2004-06-07): Results: (a) Microsoft IIS
1695 5.0: (a1) no lock token: 400, (a2) bad lock token: 412, (a3) unlocked
1696 resource: 412. (b) Apache/Moddav 2.0.49: (b1) no lock token: 400,
1697 (b2): bad lock token: 400, (b3) unlocked resource: 400. (c) SAP
1698 Enterprise Portal 5SP6: (c1) no lock token: 412, (c2): bad lock
1699 token: 412, (c3) unlocked resource: 412. (d) Xythos (Sharemation):
1700 see (c).
1702 Resolution (2004-06-15): Clarify that the Lock-Token header does not
1703 contribute to the set of preconditions that are relevant for a 412
1704 status. Thus other 4xx status code are be recommended here (note
1705 that more details can be obtained by processing the optional
1706 DAV:error response body). See also
1707 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0180.html
1709 F.4 040_LOCK_ISSUES_08
1711 Type: change
1713
1715 ccjason@us.ibm.com (1999-06-07): Shared locks... read locks... Our
1716 justifcation for shared locks ("Shared locks are included
1717 because....") seems faulty. It's not a mechansim for dealing with
1718 programs that forget to release their locks. That remains a problem
1719 with shared locks. In this case they'd forget to release a shared
1720 lock and block exclusive lock users. Timeouts and administrative
1721 action are the solutions to this problem... not shared locks. BTW,
1722 I'd think that the use of exclusive locks is just fine. I do have a
1723 problem with shared locks though... or at least shared write locks.
1724 Although they were relatively easy to define, I see them as solving a
1725 red herring problem of multiple entites cooperatively writing using
1726 distinct locks. I say it's a red herring because they don't know
1727 each other well enough to use the same lock but they do know each
1728 other well enough to not step on each other. This seems unlikely.
1729 As does the managing a compatibility matrix and getting all the
1730 entities to abide by it. OTOH I see another more common problem that
1731 is being overlooked. I see a class of folks whose purpose is to not
1732 actually write to a (set of) resource(s), but to simply prevent
1733 others from writing to it while they are looking at it. Shared write
1734 locks do not necessarily do that because with a shared write lock.
1735 someone else could grab a shared lock and go ahead and write. The
1736 only way to block that is to get an exclusive write lock. But doing
1737 that prevents anyone else from doing what you're doing despite it
1738 being pretty benign. An expedient solution is to say that a shared
1739 write lock should not necessarily give one the right to modify a
1740 resource. All it should do is prevent others from writing. And then
1741 the purpose of an exclusive write lock is just to insure that others
1742 can't get a lock and block you from writing. Now is this the right
1743 solution? Probably not. There probably should be something called a
1744 read lock that actually prevents writes as a side effect.... and
1745 would tend to get used in shared mode. Anyway, as it is, I think the
1746 shared write locks are a red herring and we're missing something we
1747 are more likely to need... shared read locks.
1749 julian.reschke@greenbytes.de (2004-06-17): Reject: shared lock
1750 semantics have been stable since publication of RFC2518. However,
1751 state what the advantage of a shared lock in this case is.
1753 F.5 040_LOCK_ISSUES_03
1755 Type: change
1757
1759 ccjason@us.ibm.com (1999-06-07): Section 7.1 Write lock. I believe
1760 this definition of a write lock is not right... or not complete...
1761 judging from what I read elsewhere. I believe one can do these
1762 operations without a write lock... as long as someone else doesn't
1763 have a write lock on the resources effected. I also believe it
1764 doesn't prevent LOCK requests in the case of shared locks.
1766 julian.reschke@greenbytes.de (2004-06-16): Remove paragraph and copy
1767 relevant section from GULP.
1769 F.6 7.5_DELETE_vs_URIs
1771 Type: change
1773
1775 julian.reschke@greenbytes.de (2004-06-14): Section 7.5 Write Locks
1776 and Collections. "...or issues a DELETE to remove a resource which
1777 has a URI which is an existing internal member URI of a write locked
1778 collection, this request MUST fail if the principal does not have a
1779 write lock on the collection." This is consistent with RFC2518's
1780 definition of DELETE, however the requirement to remove *all* URIs
1781 mapped to the resource is incompatible with BIND and has been removed
1782 in RFC2518bis-05. Thus we should rewrite section 7.5 as: "..., or
1783 issues a DELETE to remove an internal member URI of a write locked
1784 collection, this request MUST fail if the principal does not have a
1785 write lock on the collection."
1787 Resolution (2004-06-15): Done.
1789 F.7 040_LOCK_ISSUES_04
1791 Type: change
1793
1795 ccjason@us.ibm.com (1999-06-07): Section 7.5 Write Locks and
1796 Collections. It says that if members are locked in a conflicting
1797 manner, then their collection can't be locked. That seems
1798 ambiguously safe to say, but I suspect that text should mention depth
1799 since if the parent lock request is depth 0, I don't think we let the
1800 members lock state effect the success of the LOCK request. The
1801 possible exception is what we said about protecting a URI that was
1802 used to perform a lock (of a member of the collection). I'm not sure
1803 what we'd like to say for that. In the advanced collection meetings
1804 we refered to these being "protected" and avoided speaking about
1805 "lock"ing the URI. This creates an odd situation though.
1807 Resolution (2004-06-14): Clarify that this only applies to the
1808 attempt to depth-infinity lock the collection.
1810 F.8 053_LOCK_INHERITANCE
1812 Type: edit
1814
1816 jrd3@alum.mit.edu (1999-11-26): Section 7.5 states, "If a lock owner
1817 causes the URI of a resource to be added as an internal member URI of
1818 a locked collection then the new resource MUST be automatically added
1819 to the lock." However, though this is the intent, the specification
1820 does not explicitly state that this behavior only applies to depth
1821 infinity locked collections. The words "Depth infinity" should be
1822 added before the word "locked" in this sentence.
1824 Resolution (2004-06-14): Agreed; make that change.
1826 F.9 057_LOCK_SEMANTICS
1828 Type: change
1830 (): At present, the WebDAV specification is not excruciatingly
1831 explicit that writing to a locked resource requires the combination
1832 of the lock token, plus an authentication principal. At one point,
1833 the spec. discusses an "authorized" principal, but "authorized" is
1834 never explicitly defined.
1836 Resolution (2004-06-17): Submitting the lock token in an If header
1837 (usages != UNLOCK) SHOULD be restricted to whatever the server thinks
1838 the "owner" of the lock is. See discussion at
1839 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/thread.html#57.
1841 Appendix G. Open issues (to be removed by RFC Editor prior to
1842 publication)
1844 G.1 import-rfc3253-stuff
1846 Type: change
1848 julian.reschke@greenbytes.de (2004-04-25): Import error marshalling
1849 and terminology from RFC3253.
1851 G.2 import-gulp
1853 Type: change
1855 julian.reschke@greenbytes.de (2004-05-25): Make specification text
1856 compatible with GULP where it isn't. Integrate GULP as normative
1857 specification of the locking behaviour.
1859 G.3 edit
1861 Type: edit
1863 julian.reschke@greenbytes.de (2004-05-25): Umbrella issue for
1864 editorial fixes/enhancements.
1866 G.4 008_URI_URL
1868 Type: change
1870
1872 masinter@parc.xerox.com (1998-11-09): Perform a thorough review of
1873 the specification to ensure that URI and URL are used correctly, and
1874 consistently throughout.
1876 julian.reschke@greenbytes.de (2004-06-04): Use "request URI" when
1877 talking particularily about HTTP messages because this is the term
1878 used by RFC2616. Use "URL" when talking about HTTP/WebDAV resources.
1879 Otherwise use URI, making sure that if a relativeURI (as defined by
1880 RFC2396) is allowed, we say so.
1882 Resolution: Seems to have been deferred:
1883 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0216.html,
1884 but there is some follow on discussion on what exactly needs to be
1885 clarified:
1886 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0068.html,
1887 but no specific action was concluded besides the fact that we don't
1888 need to wait for RFC2396 to be updated or request any changes/
1889 clarifications to that.
1891 G.5 040_LOCK_ISSUES_06
1893 Type: change
1895
1897 ccjason@us.ibm.com (1999-06-07): Upon cursory reading of the rfc 2518
1898 sec 8.10.4 through 8.11 I was confused by the plethoria of error
1899 codes. Nothing seems to unify them. 8.10.4 speaks of a return code
1900 of 409 Conflict if a lock can't be granted. - Firstly, I can't tell
1901 if it is saying that the 409 is within the multistatus body... or in
1902 the response header. - Secondly, later text seems to use a different
1903 status codes and never mentions this one again. 8.10.7 lists status
1904 codes - 200 OK, 412 Precondition Failed, and 423 Locked are listed,
1905 but 409 Conflict (mentioned above) is not. - In the case of 412
1906 Precondition Failed, the description the follows doesn't seem to
1907 describe a "precondition failed". And it sounds like it's talking
1908 about an access request that includes a "locktoken", not a LOCK
1909 request that generates one. - The 423 Locked condition also sort of
1910 sounds like it's talking about an access request rather than a LOCK
1911 request. 8.10.10 lists LOCK status codes - 207 Multistatus which was
1912 not mentioned above - 403 Forbidden which was not mentioned above.
1913 - 424 Failed dependency which was not mentioned above. 8.11 UNLOCK
1914 - we don't mention what the failure response should look like. -
1915 comment: 200 OK seems like a better response than 204 No Content.
1916 The brief explanation isn't persuasive and seems to say that the
1917 response code should serve the purpose of the Content-Length.
1918 header. - we should probably explicitly say if an UNLOCK can only be
1919 done on the original resource... and will fail even if the resource
1920 specified is locked by virtue of being a child of the original
1921 resource. Or is this too obvious? I know it's something easy to
1922 goof up in an implementation.
1924 julian.reschke@greenbytes.de (2004-06-04): (1) 8.10.4 is wrong. The
1925 return code is 207. See issue 037_DEEP_LOCK_ERROR_STATUS, resolved
1926 in draft 01. (2) General agreement that descriptions of error
1927 marshalling needs to be redone. This applies both th LOCK and
1928 UNLOCK. (3) Agreement that the argument given for 204 is lame;
1929 clients should handle all 2xx status codes with the notable exception
1930 of 207 as "success". We may want to explain that in RFC2518bis'
1931 section about 207.
1933 G.6 056_DEPTH_LOCK_AND_IF
1935 Type: change
1937
1938 joe@orton.demon.co.uk (2000-03-04): The specification is currently
1939 silent on how to use the If header for submitting a locktoken when
1940 performing a DELETE in a Depth infinity locked collection. Should
1941 the If header have both the collection URL and the Request-URI, or
1942 just the Request-URI? An example of this is needed.
1944 julian.reschke@greenbytes.de (2004-04-25): Clarify as part of
1945 integrating GULP. May need to test interop with existing
1946 implementations.
1948 G.7 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
1950 Type: change
1952 jrd3@alum.mit.edu (): Is the complexity of the IF header appropriate
1953 for the simple task o verifying that a client knowingly owns a lock?
1954 The IF header seems to serve a different purpose. One of those
1955 purposes is for the server to verify that you have the lock token
1956 (and that you know the root of it?). Another is for the client to
1957 check some preconditions before doing an action. Another seems to be
1958 to specify what lock to refresh in a lock refresh request. This
1959 seems to create ambiguity in our definition of the semantics of the
1960 IF: header.
1962 ccjason@us.ibm.com (): It is felt by the group that it's important
1963 that the client not just own and hold the lock token, but that it
1964 also know where the lock is rooted before it does tasks related to
1965 that lock. This still leaves the lock referesh issue unresolved.
1967 julian.reschke@greenbytes.de (2004-06-02): Re.: using Lock-Token to
1968 identify the lock to be refreshed
1969 (http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0127.html):
1970 problems with current rfc2518bis-05 wording; also no support in
1971 popular implementations; suggestion to roll-back changes in -bis and
1972 keep "If" header based syntax.
1974 G.8 088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED
1976 Type: change
1978 (): The DAV:owner field of a lock is controlled by the locking client
1979 and should not be manipulated by the server. This is the only place
1980 the client can store info. The roundtrip details should match what
1981 we resolve for the PROP_ROUNDTRIP issue. Examples should also be
1982 checked.
1984 Resolution: Resolved by repeated statement and no disagreement.
1986 G.9 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION
1988 Type: change
1990
1992 ccjason@us.ibm.com (): What resource should be flagged in the
1993 multistatus response to locking issues in COPY/MOVE requests?
1995 Resolution: Resolved to flag the locking errors at the source
1996 resource that was affected by the problem. The details of how to
1997 describe the error was deferred to a subsequent version of WebDAV. -
1998 6/15/02 - 2518bis does not reflect this.
2000 G.10 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION
2002 Type: change
2004
2006 (): The method of describing the details of (beyond what resolved by
2007 COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION) of the underlying cause of
2008 various locking and ACL COPY/MOVE problems is deferred. Two
2009 proposals were outlined in the discussion, but interest was not great
2010 and we clearly don't have interoperability to take these proposals
2011 forward.
2013 G.11 072_LOCK_URL_WITH_NO_PARENT_COLLECTION
2015 Type: change
2017
2019 dbrotsky@Adobe.COM (): If a LOCK request is submitted to a URL that
2020 doesn't have a parent collection, what should be the correct
2021 response? Other methods, PUT, MKCOL, COPY, MOVE all require a 409
2022 response in this case. Seems like LOCK should have this requirement
2023 as well.
2025 Resolution: Resolved that since LNRs no longer exist (see
2026 NULL_RESOURCE_CLARIFY) the server should return 409. We should
2027 insure that the new text we add to replace LNRs does not create an
2028 ambiguity:
2029 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0164.html
2031 G.12 044_REPORT_OTHER_RESOURCE_LOCKED
2033 Type: change
2035
2037 wiggs@xythos.com (1999-07-23): In some cases, such as when the parent
2038 collection of a resource is locked, a 423 (Locked) status code is
2039 returned even though the resource identified by the Request-URI is
2040 not locked. This can be confusing, since it is not possible for a
2041 client to easily discover which resource is causing the locked status
2042 code to be returned. An improved status report would indicate the
2043 resource causing the lock message.
2045 julian.reschke@greenbytes.de (2004-04-25): Proposal to define a
2046 specific precondition element plus specific child elements similar to
2047 RFC3744, section 7.1.1.
2049 julian.reschke@greenbytes.de (2004-06-18): See summary and proposal
2050 in
2051 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0192.html.
2053 G.13 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL
2055 Type: change
2057 (): Right now the server uses the IF: header to verify that a client
2058 knows what locks it has that are affected by an operation before it
2059 allows the operation. Must the client provide the root URL of a
2060 lock, any URL for a pertainent loc, or some specific URL in the IF:
2061 header.
2063 ccjason@us.ibm.com (): It is felt by the group that it's important
2064 that the client not just own and hold the lock token, but that it
2065 also know where the lock is rooted before it does tasks related to
2066 that lock. This is just a point of info. The issue itself still
2067 needs to be brought up and answered.still
2069 julian.reschke@greenbytes.de (): Summary: current implementations do
2070 not seem to care (see
2071 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0190.html).
2072 Suggestion to require clients to specify the lock root anyway,
2073 because this is what the WG agreed upon earlier.
2075 G.14 015_MOVE_SECTION_6.4.1_TO_APPX
2077 Type: change
2079
2081 mda@discerning.com (1998-11-24): The discussion of generating UUID
2082 node fields without using the IEEE 802 address in section 6.4.1 can
2083 be moved to an appendix.
2085 julian.reschke@greenbytes.de (2004-04-31): Plan: get rid of the
2086 section altogether and refer to draft-mealling-uuid-urn. In the
2087 meantime, move the whole opaquelocktoken discussion into an appendix.
2089 Index
2091 4
2092 423 Locked (status code) 16
2094 C
2095 Condition Names
2096 DAV:lock-removal-allowed (pre) 15
2097 DAV:lock-removed (post) 16
2098 DAV:lock-submission-allowed (pre) 13, 16
2099 DAV:lock-token-matches (pre) 15
2100 DAV:locks-refreshed (post) 13
2101 DAV:name-allowed (pre) 17
2102 DAV:parent-resource-must-be-non-null (pre) 17
2104 D
2105 DAV header
2106 compliance class '2' 17
2107 compliance class 'locking' 17
2108 DAV:lock-removal-allowed precondition 15
2109 DAV:lock-removed postcondition 16
2110 DAV:lock-submission-allowed precondition 13, 16
2111 DAV:lock-token-matches precondition 15
2112 DAV:lockdiscovery property 6
2113 DAV:locks-refreshed postcondition 13
2114 DAV:name-allowed precondition 17
2115 DAV:parent-resource-must-be-non-null precondition 17
2116 DAV:supportedlock property 8
2118 H
2119 Headers
2120 Lock-Token 17
2121 Timeout 31
2123 L
2124 LOCK method 9
2125 lock creation 9
2126 lock refresh 13
2127 Lock-Token header 17
2128 lockinfo
2129 XML element 32
2131 M
2132 Methods
2133 LOCK (lock creation) 9
2134 LOCK (lock refresh) 13
2135 LOCK 9
2136 UNLOCK 15
2138 O
2139 opaquelocktoken (URI scheme) 33
2141 P
2142 Properties
2143 DAV:lockdiscovery 6
2144 DAV:supportedlock 8
2146 S
2147 Status Codes
2148 423 Locked 16
2150 T
2151 Timeout header 31
2153 U
2154 UNLOCK method 15
2155 URI schemes
2156 opaquelocktoken 33
2158 Intellectual Property Statement
2160 The IETF takes no position regarding the validity or scope of any
2161 Intellectual Property Rights or other rights that might be claimed to
2162 pertain to the implementation or use of the technology described in
2163 this document or the extent to which any license under such rights
2164 might or might not be available; nor does it represent that it has
2165 made any independent effort to identify any such rights. Information
2166 on the procedures with respect to rights in RFC documents can be
2167 found in BCP 78 and BCP 79.
2169 Copies of IPR disclosures made to the IETF Secretariat and any
2170 assurances of licenses to be made available, or the result of an
2171 attempt made to obtain a general license or permission for the use of
2172 such proprietary rights by implementers or users of this
2173 specification can be obtained from the IETF on-line IPR repository at
2174 http://www.ietf.org/ipr.
2176 The IETF invites any interested party to bring to its attention any
2177 copyrights, patents or patent applications, or other proprietary
2178 rights that may cover technology that may be required to implement
2179 this standard. Please address the information to the IETF at
2180 ietf-ipr@ietf.org.
2182 Disclaimer of Validity
2184 This document and the information contained herein are provided on an
2185 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2186 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2187 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2188 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2189 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2190 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2192 Copyright Statement
2194 Copyright (C) The Internet Society (2004). This document is subject
2195 to the rights, licenses and restrictions contained in BCP 78, and
2196 except as set forth therein, the authors retain all their rights.
2198 Acknowledgment
2200 Funding for the RFC Editor function is currently provided by the
2201 Internet Society.