- From: <jamsden@us.ibm.com>
- Date: Tue, 25 Jan 2000 12:25:28 -0500
- To: w3c-dist-auth@w3.org
Bill, If the lock token isn't returned in the header, there's no way for you to get the lock token of the lock you just created. That's because the active lock element of the lock discovery property does not contain the authentication id of the principal owning the lock. The lock tokens are in the lock discovery, but you can't figure out which ones you own. I continue to believe this is an open issue that requires clients to persist their lock tokens outside the WebDAV repository. Lock tokens are a pain enough for the rare case where they are actually useful. Not having the principal owning the lock in the lock discovery makes them even worse. I proposed a fix to this over a year ago, but was told at that time that it was too late and would have too much effect on the spec which was about to become an accepted draft. But now we are looking at some pretty significant changes to locking semantics. Can we please get this simple issue resolved. WebDAV clients will appreciate it. bill@carpenter.ORG (WJCarpenter)@w3.org on 01/20/2000 06:31:11 PM Sent by: w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: RFC-2518 LOCK-TOKEN: header Examples in RFC-2518, section 8.10.8 et seq, don't show a LOCK-TOKEN: response header. This contradicts other places in RFC-2518 which say that the header is required in the response. It would suit me if the requirement were changed and the examples left as is. -- bill@carpenter.ORG (WJCarpenter) PGP bill@bubblegum.net 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
Received on Tuesday, 25 January 2000 12:28:40 UTC