Re: unlock question

At 2:49 PM -0800 3/1/01, Greg Stein wrote:
>  > >mod_dav returns 400 (Bad Request) whether the resource has other 
>locks on it
>>  >or not. The client should have submitted an UNLOCK with a proper 
>>lock token.
>>  >
>>  >Cheers,
>>  >-g
>>
>>  Greg,
>>
>>  Why not 412?  I thought servers were always supposed to return 412 to
>>  requests that provided invalid state preconditions?
>
>The Lock-Token: header is not a precondition. It is an input parameter to
>the UNLOCK method.

Sorry I wasn't clear enough.  I wasn't contesting that 400 is a valid 
response.  I was trying to ask you for your design rationale in 
choosing to return 400 rather than 412.

One of the problems I have with the spec is that it's very vague 
about specific error responses in some situations, and very precise 
in others, with no apparent rationale.  For example, it specifically 
says that 412 must be returned when the server can't honor the type 
of lock request a client makes, but says nothing about which error 
should be returned in the case of a missing (or incorrect) token with 
unlock.  In general, it's a lot easier to write clients if known 
modes of failure that relate to the semantics of the request get 
specific error returns.

In this particular case, the spec is very clear in section 7.6 that 
all methods which "interact with" (interpreted as "change") a 
write-locked resource must include an IF header specifying the lock 
token.  If the lock token is missing, they are to get a 412 (since 
it's an IF).  Unfortunately, the example for UNLOCK does not show any 
such IF header, so presumably the LOCK-TOKEN header is supposed to be 
doing double duty here (both specifying what to unlock and specifying 
the required precondition for every "interacting" method).  Thus a 
missing or incorrect lock token might well receive a 412.  This would 
have some advantages for clients, since it could be specifically 
interpreted as meaning "that's the wrong lock token" but 400 could 
mean anything.

Note that there's a separate issue here for servers that support 
non-exclusive locks and also support write locks.  The issue is that 
both LOCK and UNLOCK are clearly "interacting methods" in the sense 
of section 7.6, but UNLOCK is not shown to need an IF header.  If a 
server issues a write lock on a resource that has some other kind of 
non-exclusive lock on it, then it ought to reject an unlock for that 
other kind of lock if the UNLOCK call doesn't specify an IF header 
with the token of the write lock.  But then why shouldn't it reject 
an UNLOCK of the write lock itself if it doesn't have such an IF 
header?

JimW: Can you add these issues (maybe as one issue) to the issues list?

1. Does UNLOCK require IF header specifying applicable write lock token?

2. UNLOCK should return 412 if valid lock token is not supplied as 
UNLOCK-TOKEN.

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 888-461-0237
2-way pager email: <mailto:page-dbrotsky@adobe.com>

Received on Friday, 2 March 2001 14:13:10 UTC