Subject: Inconsistency in lock-token response requirements in 2518

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 7 Sep 2001 09:36:26 -0700

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?

lisa

---

From: Daniel Brotsky <[email-masked]>
Date: Tue, 11 Sep 2001 12:54:16 -0700

>Most clients seem to pull the lock token out of the body; does that mean the

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.

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:[email-masked]>