This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire in November 2004.
Copyright © The Internet Society (2004). All Rights Reserved.
This document specifies a set of methods and headers ancillary to HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV, RFC2518) for the management of resource locking (collision avoidance). It updates those sections from RFC2518 that specify WebDAV's locking features.
[rfc.comment.1: Note that this document is not a product of the WebDAV working group. It is just an experiment to study the feasability of extracing the locking feature into a separate specification. --reschke]
[rfc.comment.2: This version of this document doesn't yet contain any new or rewritten text - it only contains text copied verbatim fro RFC2518 and GULP. It's sole purpose is be a reference point for all future changes. --reschke]
Distribution of this document is unlimited. Please send comments to the WebDAV working group at email@example.com, which may be joined by sending a message with subject "subscribe" to firstname.lastname@example.org.
Discussions of the WEBDAV working group are archived at URL: http://lists.w3.org/Archives/Public/w3c-dist-auth/.
|I extract-locking (type: change, status: closed)|
|email@example.com||2004-04-14||Locking extracted from RFC2518.|
|2004-05-21||Resolution: Finished as of draft 00.|
|I updated-rfc2068 (type: change, status: closed)|
|firstname.lastname@example.org||2004-04-25||Update references of RFC2068 to either RFC2396 or RFC2616.|
|Associated changes in this document: 13, del-1, B.5.4.|
|I import-rfc3253-stuff (type: change, status: open)|
|email@example.com||2004-04-25||Import error marshalling and terminology from RFC3253.|
|Associated changes in this document: 1.|
|I import-gulp (type: change, status: open)|
|firstname.lastname@example.org||2004-05-25||Make specification text compatible with GULP where it isn't. Integrate GULP as normative specification of the locking behaviour.|
|Associated changes in this document: B.4.1.1, B.4.2.|
|I edit (type: edit, status: open)|
|email@example.com||2004-05-25||Umbrella issue for editorial fixes/enhancements.|
|Associated changes in this document: <#rfc.change.edit.1>, <#rfc.change.edit.2>, 3, 6, 8, 9, 11, B.2.3, B.2.3, B.2.3, del-2, B.2.4, B.2.4, B.2.5, B.2.5, B.2.6, B.4.1.1, B.4.1.7, B.4.1.10, B.4.1.10, B.5, B, B.6, B.6, B.6, B, B, del-25, del-25, B, B, C.|
|I 008_URI_URL (type: change, status: open)|
|firstname.lastname@example.org||1998-11-09||Perform a thorough review of the specification to ensure that URI and URL are used correctly, and consistently throughout.|
|Resolution: Seems to have been deferred: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0216.html, but there is some follow on discussion on what exactly needs to be clarified: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0068.html, but no specific action was concluded besides the fact that we don't need to wait for RFC2396 to be updated or request any changes/clarifications to that.|
|I 040_LOCK_ISSUES_06 (type: change, status: open)|
Upon cursory reading of the rfc 2518 sec 8.10.4 through 8.11 I was confused by
the plethoria of error codes. Nothing seems to unify them.
8.10.4 speaks of a return code of 409 Conflict if a lock can't be granted.
- Firstly, I can't tell if it is saying that the 409 is within the multistatus body... or in the response header.
- Secondly, later text seems to use a different status codes and never mentions this one again.
8.10.7 lists status codes
- 200 OK, 412 Precondition Failed, and 423 Locked are listed, but 409 Conflict (mentioned above) is not.
- In the case of 412 Precondition Failed, the description the follows doesn't seem to describe a "precondition failed". And it sounds like it's talking about an access request that includes a "locktoken", not a LOCK request that generates one.
- The 423 Locked condition also sort of sounds like it's talking about an access request rather than a LOCK request.
8.10.10 lists LOCK status codes
- 207 Multistatus which was not mentioned above
- 403 Forbidden which was not mentioned above.
- 424 Failed dependency which was not mentioned above.
- we don't mention what the failure response should look like.
- comment: 200 OK seems like a better response than 204 No Content. The brief explanation isn't persuasive and seems to say that the response code should serve the purpose of the Content-Length. header.
- we should probably explicitly say if an UNLOCK can only be done on the original resource... and will fail even if the resource specified is locked by virtue of being a child of the original resource. Or is this too obvious? I know it's something easy to goof up in an implementation.
|I 040_LOCK_ISSUES_07 (type: change, status: closed)|
9.4 If header
- BNF suggests that IF's content must be all tagged or all untagged.
- doesn't say if there can be two If headers in a request. Might we want a tagged one and an untagged one?
- I must be misunderstanding this, but it sounds to me like that state of a resource(s) must match one of the locktokens listed in the request. But what if some of the resources are locked and others are not. The unlocked resources definitely won't contain state that's listed. Are we precluding operations on regions that might not be entirely locked? -- Is this a valid observation or a red herring?
126.96.36.199 If header - untagged example
- See my comment about regions that are not entirely locked.
9.4.2 If header -tagged state
- So if we've applied a lock with depth.... and now we're doing a DELETE on a subtree of that tree and we've tagged the locktoken we've submitted, will this prevent that locktoken from apply'ing to ALL the resources of the subtree... and thus prevent the COPY from succeeding? Or are we supposed to tag the lock token with the root of the LOCK even if that is not part of what we are deleting? Or should the request use untagged locktokens?
9.4.3 If header - NOT operator
- Why do we want this? of course... why not? :-)
Overall, the If header seems backwards for locktokens. It's client driven rather than server semantics driven. The only feature it seems to provide is perhaps the ability for the client to request that the request be aborted if the resource no longer is locked. Other than that it seems to complicate the simple process of letting the server know what tokens you hold. I'd think we'd just want a different header to declare what lock tokens we hold and let the server (not the client) decide how they affect the success of the request.
|2004-05-24||Resolution: This issue needs to be handled in the base protocol.|
|I 044_REPORT_OTHER_RESOURCE_LOCKED (type: change, status: open)|
|email@example.com||1999-07-23||In some cases, such as when the parent collection of a resource is locked, a 423 (Locked) status code is returned even though the resource identified by the Request-URI is not locked. This can be confusing, since it is not possible for a client to easily discover which resource is causing the locked status code to be returned. An improved status report would indicate the resource causing the lock message.|
|firstname.lastname@example.org||2004-04-25||Proposal to define a specific precondition element plus specific child elements similar to RFC3744, section 7.1.1.|
|I 052_LOCK_BODY_SHOULD_BE_MUST (type: change, status: open)|
|email@example.com||1999-11-23||Section 8.10.1 states that a LOCK method request SHOULD have an XML request body. This SHOULD should instead be MUST.|
|firstname.lastname@example.org||2004-04-25||Clarify that for creating LOCKs, it MUST have a request body which SHOULD have the DAV:owner element. For LOCK refreshes, no body is required.|
|I 054_IF_AND_AUTH (type: change, status: open)|
|email@example.com||2000-01-27||The fact that use of authentication credentials with submission of lock tokens is required should be strengthened in the document.|
|firstname.lastname@example.org||2004-05-02||Submitting the lock token in an If header (usages != UNLOCK) SHOULD be restricted to whatever the server thinks the "owner" of the lock is.|
|I 056_DEPTH_LOCK_AND_IF (type: change, status: open)|
|email@example.com||2000-03-04||The specification is currently silent on how to use the If header for submitting a locktoken when performing a DELETE in a Depth infinity locked collection. Should the If header have both the collection URL and the Request-URI, or just the Request-URI? An example of this is needed.|
|firstname.lastname@example.org||2004-04-25||Clarify as part of integrating GULP. May need to test interop with existing implementations.|
|I 057_LOCK_SEMANTICS (type: change, status: open)|
|At present, the WebDAV specification is not excruciatingly explicit that writing to a locked resource requires the combination of the lock token, plus an authentication principal. At one point, the spec. discusses an "authorized" principal, but "authorized" is never explicitly defined.|
|email@example.com||2004-05-02||Submitting the lock token in an If header (usages != UNLOCK) SHOULD be restricted to whatever the server thinks the "owner" of the lock is.|
|I 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY (type: change, status: open)|
|firstname.lastname@example.org||Is the complexity of the IF header appropriate for the simple task o verifying that a client knowingly owns a lock? The IF header seems to serve a different purpose. One of those purposes is for the server to verify that you have the lock token (and that you know the root of it?). Another is for the client to check some preconditions before doing an action. Another seems to be to specify what lock to refresh in a lock refresh request. This seems to create ambiguity in our definition of the semantics of the IF: header.|
|email@example.com||It is felt by the group that it's important that the client not just own and hold the lock token, but that it also know where the lock is rooted before it does tasks related to that lock. This still leaves the lock referesh issue unresolved.|
|firstname.lastname@example.org||2004-04-25||Need Lock-Token header to indicate the lock to be refreshed.|
|I 066_MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL (type: change, status: open)|
|Right now the server uses the IF: header to verify that a client knows what locks it has that are affected by an operation before it allows the operation. Must the client provide the root URL of a lock, any URL for a pertainent loc, or some specific URL in the IF: header.|
|email@example.com||It is felt by the group that it's important that the client not just own and hold the lock token, but that it also know where the lock is rooted before it does tasks related to that lock. This is just a point of info. The issue itself still needs to be brought up and answered.still|
|I 067_UNLOCK_NEEDS_IF_HEADER (type: change, status: open)|
|dbrotsky@Adobe.COM||Shouldn't we be using an IF header to do an UNLOCK seeing as you need to prove you are holding a lock before you can remove it? (This might be contingent on 063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY)|
|I 068_UNLOCK_WITHOUT_GOOD_TOKEN (type: change, status: open)|
|dbrotsky@Adobe.COM||What should UNLOCK return if a bad token is provided or no token. (This might be contingent on UNLOCK_NEEDS_IF_HEADER.)|
|I 070_LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER (type: change, status: open)|
|dbrotsky@Adobe.COM||The LOCK renewal request should not us an IF header to specify what lock is being renewed. This limits the use of the IF header.|
|firstname.lastname@example.org||2004-04-25||Need Lock-Token header to indicate the lock to be refreshed.|
|I 072_LOCK_URL_WITH_NO_PARENT_COLLECTION (type: change, status: open)|
|dbrotsky@Adobe.COM||If a LOCK request is submitted to a URL that doesn't have a parent collection, what should be the correct response? Other methods, PUT, MKCOL, COPY, MOVE all require a 409 response in this case. Seems like LOCK should have this requirement as well.|
|Resolution: Resolved that since LNRs no longer exist (see NULL_RESOURCE_CLARIFY) the server should return 409. We should insure that the new text we add to replace LNRs does not create an ambiguity: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0164.html|
|I 079_UNLOCK_BY_NON_LOCK_OWNER (type: change, status: open)|
|email@example.com||At present, the specification is not explicit about who might be capable of grabbing a lock token via lock discovery and the submitting it in UNLOCK (and/or for a subsequent write operation). It is OK for the resource owner to grab the lock token and do UNLOCK/write? Is it OK to have a "grab lock token" privilege that can be assigned to anyone?|
|Resolution: Resolved in part by putting it under ACL control: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0002.html and the response that follows it.|
|I 088_DAVOWNER_FIELD_IS_CLIENT_CONTROLED (type: change, status: open)|
|The DAV:owner field of a lock is controlled by the locking client and should not be manipulated by the server. This is the only place the client can store info. The roundtrip details should match what we resolve for the PROP_ROUNDTRIP issue. Examples should also be checked.|
|Resolution: Resolved by repeated statement and no disagreement.|
|I 099_COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION (type: change, status: open)|
|firstname.lastname@example.org||What resource should be flagged in the multistatus response to locking issues in COPY/MOVE requests?|
|Resolution: Resolved to flag the locking errors at the source resource that was affected by the problem. The details of how to describe the error was deferred to a subsequent version of WebDAV. - 6/15/02 - 2518bis does not reflect this.|
|I 100_COPYMOVE_LOCKED_STATUS_DESCRIPTION (type: change, status: open)|
|The method of describing the details of (beyond what resolved by COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION) of the underlying cause of various locking and ACL COPY/MOVE problems is deferred. Two proposals were outlined in the discussion, but interest was not great and we clearly don't have interoperability to take these proposals forward.|
|I rfc2606-compliance (type: editor, status: closed)|
|email@example.com||2004-05-23||Ensure that examples use only sample domains as per RFC2606.|
|Associated changes in this document: B.3.5.1, B.4.1.8, B.4.1.8, B.4.1.8, B.4.1.8, B.4.1.9, B.4.1.9, B.4.1.10, B.4.1.10, B.4.1.10, B.4.2.1, B.4.2.1, del-21, del-23, del-23.|
All IANA considerations mentioned in [RFC2518] also apply to this document.
This document is the collaborative product of ¶
This document has also benefited from thoughtful discussion by Mark Anderson, Dan Brotksy, Geoff Clemm, Jim Davis, Stefan Eissing, Rickard Falk, Larry Masinter, Joe Orton, Juergen Pill, Elias Sinderson, Greg Stein, Kevin Wiggen, and other members of the WebDAV working group.
Locking: The ability to keep more than one person from working on a document at the same time. This prevents the "lost update problem," in which modifications are lost as first one author then another writes changes without merging the other author's changes.¶
The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can prevent the "lost update" problem.¶
This specification allows locks to vary over two client-specified parameters, the number of principals involved (exclusive vs. shared) and the type of access to be granted. This document defines locking for only one access type, write. However, the syntax is extensible, and permits the eventual specification of locking for other access types.¶
A WebDAV compliant server is not required to support locking in any form. If the server does support locking it may choose to support any combination of exclusive and shared locks for any access types.¶
The reason for this flexibility is that locking policy strikes to the very heart of the resource management and versioning systems employed by various storage repositories. These repositories require control over what sort of locking will be made available. For example, some repositories only support shared write locks while others only provide support for exclusive write locks while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV.¶
A lock token is a type of state token, represented as a URI, which identifies a particular lock. A lock token is returned by every successful LOCK operation in the ↑↓lockdiscovery property in the response body, and can also be found through lock discovery on a resource.¶
Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion.¶
|I 040_LOCK_ISSUES_02 (type: change, status: closed)|
Section 6.3: "... However resource are free to return any URI scheme so long
as it meets the uniqueness requirements."
This is technically correct, but it might also be useful to say that the scheme should make the URI be readily recognizable as a *LOCK* state token in the event that other types of state tokens exist. I mention this because we seem to have created the possibility of other types of state tokens. -- Your call. :-)
|firstname.lastname@example.org||2004-04-24||Disagreement: any URI scheme can be used as a lock token. Specifications that define other types of state tokens will have to take care of distinguishing them inside an "If" header.|
|2004-05-22||Resolution: No change.|
This specification provides a lock token URI scheme called ↑↓opaquelocktoken↑↓ that meets the uniqueness requirements. However resources are free to return any URI scheme so long as it meets the uniqueness requirements.¶
|I 040_LOCK_ISSUES_01 (type: change, status: closed)|
Section 6.3: ""Having a lock token provides no special access rights..."
I suggest that the phrase "owned by another party" be added in this first sentence to distinguish between owning and having. It speaks of "having" in this sentence but not subsequently. In fact "submitting" might be an even better word than having.
|2004-05-24||Resolution: Agreed, use "submitting".|
|Associated changes in this document: B.2.3.|Having a lock token provides no special access rights. Anyone can find out anyone else's lock token by performing lock discovery. Locks MUST be enforced based upon whatever authentication mechanism is used by the server, not based on the secrecy of the token values.¶
The opaquelocktoken URI scheme is designed to be unique across all resources for all time. Due to this uniqueness quality, a client may submit an opaque lock token in an If header on a resource other than the one that returned it.
All resources MUST recognize the opaquelocktoken scheme and, at minimum, recognize that the lock token does not refer to an outstanding lock on the resource.
In order to guarantee uniqueness across all resources for all time the opaquelocktoken requires the use of the Universal Unique Identifier (UUID) mechanism, as described in [ISO-11578].
Opaquelocktoken generators, however, have a choice of how they create these tokens. They can either generate a new UUID for every lock token they create or they can create a single UUID and then add extension characters. If the second method is selected then the program generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID.
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID production is the string representation of a UUID, as defined in [ISO-11578]. Note that white space (LWS) is not allowed between elements of this production.
Extension = path ; path is defined in ↑ I ↓
section 3.2.1 of RFC 2068 [RFC2068]
UUIDs, as defined in [ISO-11578], contain a "node" field that contains one of the IEEE 802 addresses for the server machine. As noted in Section 9.1, there are several security risks associated with exposing a machine's IEEE 802 address. This section provides an alternate mechanism for generating the "node" field of a UUID which does not employ an IEEE 802 address. WebDAV servers MAY use this algorithm for creating the node field when generating UUIDs. The text in this section is originally from an Internet-Draft by Paul Leach and Rich Salz, who are noted here to properly attribute their work.
The ideal solution is to obtain a 47 bit cryptographic quality random number, and use it as the low 47 bits of the node ID, with the most significant bit of the first octet of the node ID set to 1. This bit is the unicast/multicast bit, which will never be set in IEEE 802 addresses obtained from network cards; hence, there can never be a conflict between UUIDs generated by machines with and without network cards.
If a system does not have a primitive to generate cryptographic quality random numbers, then in most systems there are usually a fairly large number of sources of randomness available from which one can be generated. Such sources are system specific, but often include:
(Note that it is precisely the above kinds of sources of randomness that are used to seed cryptographic quality random number generators on systems without special hardware for their construction.)
In addition, items such as the computer's name and the name of the operating system, while not strictly speaking random, will help differentiate the results from those obtained by other systems.
The exact algorithm to generate a node ID using these data is system specific, because both the data available and the functions to obtain them are often very system specific. However, assuming that one can concatenate all the values from the randomness sources into a buffer, and that a cryptographic hash function such as MD5 is available, then any 6 bytes of the MD5 hash of the buffer, with the multicast bit (the high bit of the first byte) set will be an appropriately random node ID.
Other hash functions, such as SHA-1, can also be used. The only requirement is that the result be suitably random↑ I ↓
_ in the sense that the outputs from a set uniformly distributed inputs are themselves uniformly distributed, and that a single bit change in the input can be expected to cause half of the output bits to change.
Since server lock support is optional, a client trying to lock a resource on a server can either try the lock and hope for the best, or perform some form of discovery to determine what lock capabilities the server supports. This is known as lock capability discovery. Lock capability discovery differs from discovery of supported access control types, since there may be access control types without corresponding lock types. A client can determine what lock types the server supports by retrieving the ↑↓supportedlock property.¶
If another principal locks a resource that a principal wishes to access, it is useful for the second principal to be able to find out who the first principal is. For this purpose the ↑↓lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and where available, provides their lock token.¶
Although the locking mechanisms specified here provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario:¶
Two clients A and B are interested in editing the resource 'index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking.
Client A doesn't lock the document, but does a GET and begins editing.
Client B does LOCK, performs a GET and begins editing.
Client B finishes editing, performs a PUT, then an UNLOCK.
Client A performs a PUT, overwriting and losing all of B's changes.
There are several reasons why the WebDAV protocol itself cannot prevent this situation. First, it cannot force all clients to use locking because it must be compatible with HTTP clients that do not comprehend locking. Second, it cannot require servers to support locking because of the variety of repository implementations, some of which rely on reservations and merging rather than on locking. Finally, being stateless, it cannot enforce a sequence of operations like LOCK / GET / PUT / UNLOCK.¶
WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requiring clients to lock resources before modifying them. Such servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources.¶
WebDAV clients can be good citizens by using a lock / retrieve / write /unlock sequence of operations (at least by default) whenever they interact with a WebDAV server that supports locking.¶
HTTP 1.1 clients can be good citizens, avoiding overwriting other clients' changes, by using entity tags in If-Match headers with any requests that would modify resources.¶
Information managers may attempt to prevent overwrites by implementing client-side procedures requiring locking before modifying WebDAV resources.¶
This section describes the semantics specific to the write lock type. The write lock is a specific instance of a lock type, and is the only lock type described in this specification.¶
|I 040_LOCK_ISSUES_03 (type: change, status: open)|
Section 7.1 Write lock.
I believe this definition of a write lock is not right... or not complete... judging from what I read elsewhere. I believe one can do these operations without a write lock... as long as someone else doesn't have a write lock on the resources effected. I also believe it doesn't prevent LOCK requests in the case of shared locks.
|email@example.com||2004-04-24||Clarify as part of rewriting the general semantics. The point about shared locks is correct, though.|
A write lock MUST prevent a principal without the lock from successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, DELETE, or MKCOL on the locked resource. All other current methods, GET in particular, function independently of the lock.¶
Note, however, that as new methods are created it will be necessary to specify how they interact with a write lock.¶
A successful request for an exclusive or shared write lock MUST result in the generation of a unique lock token associated with the requesting principal. Thus if five principals have a shared write lock on the same resource there will be five lock tokens, one for each principal.¶
While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked.¶
|I 022_COPY_OVERWRITE_LOCK_NULL (type: change, status: closed)|
|firstname.lastname@example.org||1998-11-29||If URL Ub is locked, creating a lock-null resource, then if a COPY is performed listing Ub as the destination, COPY will remove the lock-null resource, removing the lock, then perform the copy. A note needs to be added stating that the delete performed by the Overwrite header is atomic with the rest of the operation.|
|2004-05-22||Resolution: See 080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC|
|I 043_NULL_LOCK_SLASH_URL (type: change, status: closed)|
|email@example.com||1999-07-23||If a URL ending in a slash is null locked, is it legal to do a PUT to it? That is, does the URL ending in slash set the resource type to a collection, or does the first PUT/MKCOL set the resource to a ordinary, or collection resource.|
|2004-05-22||Resolution: See 080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC|
|I 077_LOCK_NULL_STATUS_CREATION (type: change, status: closed)|
|firstname.lastname@example.org||What status code should be returned when a lock null resource is created - 200 OK or 201 Created? A related issue is what status code should be returned by a PUT or MKCOL on a lock-null resource? MKCOL is defined to be 201, PUT could be 200 or 201 (201 seems like a slightly better choice).|
|2004-05-22||Resolution: Resolved via the proposal to remove LNR and replace them with ordinary resources and by the following wording: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0129.html. See 080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC|
|I 080_DEFER_LOCK_NULL_RESOURCES_IN_SPEC (type: change, status: closed)|
|Proposal to remove lock null resources from the spec until we are motivated to have them or something equivalent. In the meantime, keep the spec silent on the topic in order to avoid precluding LNR or the equivalent in a future version of WebDAV.|
|2004-05-25||Resolution: LNRs removed. See discussions preceding conclusion: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html and http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0107.html. Closes 022_COPY_OVERWRITE_LOCK_NULL, 043_NULL_LOCK_SLASH_URL, 077_LOCK_NULL_STATUS_CREATION.|
|Associated changes in this document: A.1, B.3, B.4.1.1.|
It is possible to assert a write lock on a null resource in order to lock the name.
A write locked null resource, referred to as a lock-null resource, MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and UNLOCK. A lock-null resource MUST appear as a member of its parent collection. Additionally the lock-null resource MUST have defined on it all mandatory DAV properties. Most of these properties, such as all the get* properties, will have no value as a lock-null resource does not support the GET method. Lock-Null resources MUST have defined values for lockdiscovery and supportedlock properties.
Until a method such as PUT or MKCOL is successfully executed on the lock-null resource the resource MUST stay in the lock-null state. However, once a PUT or MKCOL is successfully executed on a lock-null resource the resource ceases to be in the lock-null state.
If the resource is unlocked, for any reason, without a PUT, MKCOL, or similar method having been successfully executed upon it then the resource MUST return to the null state.
A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. As a consequence, when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a DELETE to remove a resource which has a URI which is an existing internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection.¶
|I 040_LOCK_ISSUES_04 (type: change, status: open)|
Section 7.5 Write Locks and Collections.
It says that if members are locked in a conflicting manner, then their collection can't be locked. That seems ambiguously safe to say, but I suspect that text should mention depth since if the parent lock request is depth 0, I don't think we let the members lock state effect the success of the LOCK request. The possible exception is what we said about protecting a URI that was used to perform a lock (of a member of the collection). I'm not sure what we'd like to say for that. In the advanced collection meetings we refered to these being "protected" and avoided speaking about "lock"ing the URI. This creates an odd situation though.
|email@example.com||2004-05-24||Clarify that this only applies to the attempt to depth-infinity lock the collection.|
However, if a write lock request is issued to a collection containing member URIs identifying resources that are currently locked in a manner which conflicts with the write lock, the request MUST fail with a 423 (Locked) status code.¶
|I 053_LOCK_INHERITANCE (type: change, status: open)|
|firstname.lastname@example.org||1999-11-26||Section 7.5 states, "If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock." However, though this is the intent, the specification does not explicitly state that this behavior only applies to depth infinity locked collections. The words "Depth infinity" should be added before the word "locked" in this sentence.|
|email@example.com||2004-04-25||Clarify as part of integrating GULP.|
If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that allows a resource to be added to a write lock. Thus, for example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c then resource /a/b/c will be added to the write lock.¶
If a user agent is not required to have knowledge about a lock when requesting an operation on a locked resource, the following scenario might occur. Program A, run by User A, takes out a write lock on a resource. Program B, also run by User A, has no knowledge of the lock taken out by Program A, yet performs a PUT to the locked resource. In this scenario, the PUT succeeds because locks are associated with a principal, not a program, and thus program B, because it is acting with principal A's credential, is allowed to perform the PUT. However, had program B known about the lock, it would not have overwritten the resource, preferring instead to present a dialog box describing the conflict to the user. Due to this scenario, a mechanism is needed to prevent different programs from accidentally ignoring locks taken out by other programs with the same authorization.¶
In order to prevent these collisions a lock token MUST be submitted by an authorized principal in the If header for all locked resources that a method may interact with or the method MUST fail. For example, if a resource is to be moved and both the source and destination are locked then two lock tokens must be submitted, one for the source and the other for the destination.¶
COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html If: <http://www.ics.uci.edu/users/f/fielding/index.html> (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
HTTP/1.1 204 No Content
In this example, even though both the source and destination are locked, only one lock token must be submitted, for the lock on the destination. This is because the source resource is not modified by a COPY, and hence unaffected by the write lock. In this example, user agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in the underlying transport layer.¶
|I 040_LOCK_ISSUES_05 (type: change, status: closed)|
7.7 Write Locks and COPY/MOVE
It says that a lock doesn't move with a moved resource. Of course if the lock is on the resource, not the URI, it should move with the resource. But then we have the caveat that we are also protecting the LOCK'd URI. I think the rule should be that if we submit the locktoken with the MOVE request, we are allowed to have the LOCK move with the resource and the lock will now protect a different URI. Also, ALL locks in the subtree must be submitted or the MOVE must fail because otherwise it would break our URI protection rule.
|2004-05-30||Resolution: No change: LOCKs are lost then the locked resource is moved. Will also be clearer once GULP is incorporated.|
A COPY method invocation MUST NOT duplicate any write locks active on the source. However, as previously noted, if the COPY copies the resource into a collection that is locked with "Depth: infinity", then the resource will be added to the lock.¶
A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, the resource is subject to being added to an existing lock at the destination, as specified in Appendix B.3.4. For example, if the MOVE makes the resource a child of a collection that is locked with "Depth: infinity", then the resource will be added to that collection's lock. Additionally, if a resource locked with "Depth: infinity" is moved to a destination that is within the scope of the same lock (e.g., within the namespace tree covered by the lock), the moved resource will again be a added to the lock. In both these examples, as specified in Appendix B.3.5, an If header must be submitted containing a lock token for both the source and destination.¶
A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked.¶
|I 060_LOCK_REFRESH_BODY (type: change, status: open)|
|firstname.lastname@example.org||2000-07-11||Section 7.8 of RFC 2518 indicates that clients may submit a lock refresh without a body. However, it implies that clients could submit a lock refresh with a body. Server implementations have been disallowing a lock refresh with a body. It might make sense to codify this practice, and disallow submission of a body on a lock refresh.|
|email@example.com||2004-04-25||Clarify that LOCK refresh MUST NOT have a request body. Also clarify Lock-Token header vs If header.|
However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock MUST be re-set.¶
A server may return a Timeout header with a lock refresh that is different than the Timeout header returned when the lock was originally requested. Additionally clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client.¶
If an error is received in response to a refresh LOCK request the client SHOULD assume that the lock was not refreshed.¶
The 423 (Locked) status code means the source or destination resource of a method is locked.
|I 089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK (type: change, status: closed)|
|firstname.lastname@example.org||It would be good if a client could look at a locked resource that it was planning to unlock and also find out if it's depth locked and where the depth lock is rooted.|
|Resolution: Proposed solution: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0049.html approved. See also 109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK|
|Associated changes in this document: A.2, B.4.1.8, B.4.1.9, del-7, del-9, del-21.|
|I 109_HOW_TO_FIND_THE_ROOT_OF_A_LOCK (type: change, status: closed)|
|email@example.com||If one finds a locked resource, it might be one of several resource locked by a depth lock. How does one determine the root of the lock?|
|Resolution: Resolved to support a dav:lockroot element in the lock discovery property: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0053.html See 089_FINDING_THE_ROOT_OF_A_DEPTH_LOCK|
<!ELEMENT depth (#PCDATA) >
|I 111_MULTIPLE_TOKENS_PER_LOCK (type: change, status: closed)|
|firstname.lastname@example.org||12.1.2 states that a dav:locktoken tag can have multiple <dav:href> tags in it. Is this right? And is it trying to suggest that a single (shared) lock might have multiple locktokens?|
|2004-05-21||Resolution: It is resolved that section 12.1.2 was incorrect and that only a single lock token URI should be allowed there. Also it is resolved that a lock only has a single lock token.|
|Associated changes in this document: del-9, del-9.|
<!ELEMENT locktoken (href+) >
<!ELEMENT timeout (#PCDATA) >
<!ELEMENT lockentry (lockscope, locktype) >
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<!ELEMENT lockscope (exclusive | shared) >
<!ELEMENT exclusive EMPTY >
<!ELEMENT locktype (write) >
<!ELEMENT write EMPTY >
<!ELEMENT owner ANY>
|I 101_LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS (type: edit, status: closed)|
|email@example.com||There is some confusion on how a PROPFIND response should express the fact that a resource has multiple shared locks on it. It was suggested that the spec become clearer.|
|2004-05-22||Resolution: Resolved trivially that it's probably worthwhile to demonstrate a correct response for this situation in one of the examples.|
|Associated changes in this document: del-21, del-21.|
<!ELEMENT lockdiscovery (activelock)* >
PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml; charset="utf-8" <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D='DAV:'> <D:prop><D:lockdiscovery/></D:prop> </D:propfind>
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D='DAV:'> <D:response> <D:href>http://www.foo.bar/container/</D:href> <D:propstat> <D:prop> <D:lockdiscovery> <D:activelock> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:depth>0</D:depth> <D:owner>Jane Smith</D:owner> <D:timeout>Infinite</D:timeout> <D:locktoken> <D:href> opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 </D:href> </D:locktoken> </D:activelock> </D:lockdiscovery> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
This resource has ↑ I
a single exclusive write lock on it, with an infinite timeout.
<!ELEMENT supportedlock (lockentry)* >
PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml; charset="utf-8" <?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop><D:supportedlock/></D:prop> </D:propfind>
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.foo.bar/container/</D:href> <D:propstat> <D:prop> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the ↑ I ↓supportedlock property, the ↑ I ↓lockdiscovery property, the Time-Out response header and the Lock-Token request header. A class "2" compliant resource SHOULD also support the Time-Out request header and the owner XML element.
Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.
Furthermore, the introduction of locking functionality requires support for authentication.
When submitting a lock request a user agent may also submit an owner XML field giving contact information for the person taking out the lock (for those cases where a person, rather than a robot, is taking out the lock). This contact information is stored in a lockdiscovery property on the resource, and can be used by other collaborators to begin negotiation over access to the resource. However, in many cases this contact information can be very private, and should not be widely disseminated. Servers SHOULD limit read access to the lockdiscovery property as appropriate. Furthermore, user agents SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
This specification also defines a URI scheme for the encoding of lock tokens, the opaquelocktoken URI scheme described in Appendix D.
Copyright © The Internet Society (2004).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org.