- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Wed, 30 Jun 2004 10:46:09 -0700
- To: Julian Reschke <julian.reschke@gmx.de>, Webdav WG <w3c-dist-auth@w3c.org>
I'm mostly happy with this, although as with much of the specs where preconditions are defined, it doesn't say in which cases the server MUST (or SHOULD or MAY) return this precondition. For backward compatibility, I suggest that servers SHOULD or MAY return this precondition in the body of a 423 Locked response. Other commenters? Will servers actually implement this? Lisa On Jun 19, 2004, at 6:38 AM, Julian Reschke wrote: > > Full text: > > 7.2.2 DAV:need-lock-token precondition > > If a request would modify the content for a locked resource, a dead > property of a locked resource, a live property that is defined to be > lockable for a locked resource, or an internal member URI of a > locked > collection, the request MUST fail unless the lock-token for that > lock > is submitted in the request. An internal member URI of a collection > is considered to be modified if it is added, removed, or identifies > a > different resource. [[anchor28: Copied from GULP. --reschke]] > > <!ELEMENT need-lock-token (href)* > > > Servers SHOULD insert DAV:href elements for the URLs of each root of > a lock for which a lock token was needed, unless that URL identies > the same resource to that the request was sent. > > 7.2.2.1 Example > > In the example below, a client unaware of a "Depth: infinity" lock > on > the parent collection "/workspace/webdav/" attempts to modify the > collection member "/workspace/webdav/proposal.doc". > > >>Request > > PUT /workspace/webdav/proposal.doc HTTP/1.1 > Host: example.com > > >>Response > > HTTP/1.1 423 Locked > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > > <?xml version="1.0" encoding="utf-8" ?> > <D:error xmlns:D="DAV:"> > <D:need-lock-token> > <D:href>/workspace/webdav/</D:href> > </D:need-lock-token> > </D:error> > > > -- > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >
Received on Wednesday, 30 June 2004 13:46:41 UTC