RE: Interop issue: Proposal for fixing lock token provision

Dan,

you have raised a lot of issues here -- for now I'd prefer just to
concentrate on:

> In the real world this happens constantly.  Servers can make locks go
> away whenever they want, and clients have no way of learning why or
> what the implications are for edit state.  Workflow administrators
> remove them, thinking they're inactive.  They expire because the client
> is idle for reasons beyond its control (sleeping a machine).  Server
> administrators do lock cleanups because their database seems corrupt.
> The fact of the matter is that, the way the spec is written, real-world
> clients constantly have to be doing rediscovery of what's happening on
> the server so they can "convince" the server they know exactly what's
> going on, and in fact they often have to figure out from a particular
> series of rejected requests how that *particular* server models things.

Basically you're saying "in the real world, locking doesn't work". The
reasons being

a) servers with reduced functionality (locking not supported)
b) broken servers (locking is supported, but locks do not work as expected
or go away for no apparent reason)
c) locks are "stolen"
d) administrators remove locks to "cleanup" the system

For a) and b), there's obviously little we can do, except for clarifying the
spec where it's not clear enough. As far as I understand, all current issues
about creating, refreshing, discovering and destroying locks are resolved
(minus error marshalling for deep locks). Furthermore, I'm not aware of any
a)- or b)-type issues with IIS and/or Apache/moddav. So if you experienced
problems and didn't get the expected feedback from the server implementors,
you *should* describe the problem here in detail.

As for c) -- that's by design. If it happens frequently, there may be a
problem with the lock timeouts that are set.

Regarding d) -- obviously that's a problem with how the server is run.
"Cleaning up" locks for no good reason obviously is wrong, and there's
little an RFC can do to prevent that (maybe except telling operators not to
do that).

However if a lock that a client created goes away this is a *severe* problem
within a sequence of method invocations. It shouldn't normally happen, so
there's absolutely no reason to define protocol workarounds for that
situation. If it happens frequently, the server needs to be fixed, or the
administrator needs to be educated.

Finally, I understand your frustration with trying to deal with server bugs.
As our product contains both client and server components, I'm aware of many
issues, and the most frustrating part is that bug reports are just ignored,
accepted (but no bug fix is made available) or rejected (although the WG
agrees that it is a bug).

Some of my favorite bugs are:

- incapability to handle UTF-8-URL encoded characters in resource names
- buggy parsing of response bodies when extension elements are present (for
instance, in DAV:lockdiscovery)
- incapability to handle chunked encoding
- usage of non-registered URI or URN schemes for lock tokens
- advertising support for deltaV, but not supporting even the most basic
live properties
- advertising support for DASL, but not supporting the DAV:basicsearch
grammar
- advertising support for ACLs, but not implementing the latest draft
- sending malformed XML entities upon a simple PROPFIND/allprop
-
- ...

Julian


--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 21 October 2002 04:41:29 UTC