W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

Re: Inconsistency in lock-token response requirements in 2518

From: Daniel Brotsky <dbrotsky@adobe.com>
Date: Tue, 11 Sep 2001 12:54:16 -0700
Message-Id: <p0510030db7c41a56b84f@[]>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
At 9:36 AM -0700 9/7/01, Lisa Dusseault wrote:
>There's a minor inconsistency in 2518: the spec says that the successful
>response to a LOCK request creating a new lock MUST contain the "Lock-Token"
>header (Section 8.10.1).  However, the example shortly after (section
>8.10.8) does not contain that header -- instead, it shows the lock token in
>the body.
>Most clients seem to pull the lock token out of the body; does that mean the
>header isn't required?

Actually I think it's just an erratum in the example (which was 
prepared before the lock-token: header requirement went into the 
spec).  There has been ample prior discussion of this on the list 
(and I thought there was actually an issue about it): summary is 
that, in general (including non-exclusive locks), it's impossible for 
a client to determine from the body which lock token was granted.  So 
the lock-token: header *is* required.

Isn't there also an issue on the list saying that the lock-token 
should be required with UNLOCK?  There's the same problem there with 
specifying which token to UNLOCK when a client owns multiple locks on 
a resource.

I believe most clients currently look at the body to determine the 
token only because they have to :^).  Many olders servers (such as 
IIS 5.0) didn't return lock-token: headers.

Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>
Received on Tuesday, 11 September 2001 15:59:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:23 UTC