Re: unclear on shared lock support

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: unclear on shared lock support

Julian Reschke

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


Reply | Threaded
Open this post in threaded view
|

Re: unclear on shared lock support

Julian Reschke

John Meissen wrote:

>> 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
>>
>
> On the other hand, while there is explicit language detailing what other
> conditions constitute failure there is nothing about shared vs exclusive.
> And it's not clear to me that any of the listed potential responses would
> fit such a failure.

That list is not exhaustive. From
<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.9.11.1>:

"In addition to the general status codes possible, the following status
codes have specific applicability to UNLOCK:"

In general, when a client sends a request, and the server can't fulfill
it, it has to return an appropriate failure code, and *not* do something
else.

The timeout value is a special case, and that's why the spec says so.

> Conceptually, the server is being asked to lock a resource and also allow
> other clients to lock it. I'm willing to grant a lock to this client, but
> I won't allow other clients to also lock it.

In which case you need to fail the request, and then the client can
retry an exclusive lock.

> If a client cared about the lock scope they would retrieve the
> lockdiscovery property first to find out whether shared locks are
> supported. I suspect that most clients will neither note nor care about

That is not true. I personally have written a client that assumes that
success means success, and this works with all the servers I've tested
against back then (those that do support shared locks, and those that
don't).

Your interpretation is creative, but it would be your job to prove that
you're not introducing an interop problem for those clients that want
shared locks. (and you do).

> this distinction, and would only be aware that they were unable to lock
> the resource (as I encountered with litmus).

Yes, that's an example that misleading test suites can cause
implementors to make the wrong choices. Shared locks are optional, so
Litmus should just state that the server doesn't support them, instead
of misleading implementers to do the wrong thing.

> I real-world situations it would seem to me preferrable to grant a lock
> of the supported type rather than fail the request. It will almost certainly
> make no difference to the requesting client, where to do otherwise has
> the potential to break existing applications.

Sorry, but that is nonsense.

If it doesn't make a difference, the client wouldn't have asked for a
shared lock in the first place. If it does make a difference, the client
would have either checked DAV:supportedlock first, and then made a
choice, or just tried and checked for the status code. This works today
with Apache/mod_dav, Slide, Jackrabbit, SAP KM, Xythos and Microsoft IIS.

BR, Julian