Re: unclear on shared lock support

Joe Orton wrote:

> On Mon, Nov 03, 2008 at 11:50:08PM -0800, John Meissen wrote:
>> I consider shared vs exclusive to be a lock attribute. There are other
>> requested attributes, like timeout, that a server is free to ignore.
>> I interpreted the RFC as allowing me to ignore the request to make the
>> lock shared, and permitting me to create the lock in the mode I support
>> (exclusive), especially since the actual lock characteristics are 
>> detailed in the response body. Hence there shouldn't be any confusion
>> on the client's part since it can see what type of lock was created.
> 
> Hmmm, interesting.
> 
> I agree that neon/litmus should check that the lock returned by LOCK 
> matches the lock type requested, and fail/skip subsequent shared lock 
> tests appropriately.
> 
> But I don't agree that it's a valid interpretation of 4918 to downgrade 
> the lock type from exclusive to shared.  There is specific language in 
> 4918 explaining that the timeout is a "suggestion" made by the client - 
> there is no such language in the section on the lock type.

Right.

> If you can get consensus on the DAV list (w3c-dist-auth at w3.org) that 
> this behaviour is to be permitted then I'll update litmus to SKIP rather 
> than FAIL if the shared lock request is downgraded.

No, I don't think this would be correct.

If a server doesn't allow shared locks, it should reject the request. 
That's it.

And yes, making Litmus smarter with respect to shared lock functionality 
would be good.

Best regards, Julian

Received on Wednesday, 5 November 2008 15:51:34 UTC