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