RE: Submitting lock tokens without a validity check

> >
> > If a client uses "If: urlA (tokenA) (Not tokenA)" then the client
will
> > *not* find out that their lock is invalid.   So that's not a real
> 
> Wow. You managed to completely puzzle me.
> 
> I thought that was exactly the point of this kind of request.

Weird, eh?  By using the If-Not-If hack, the client asks the request to
succeed if the locktoken is invalid, or the locktoken is valid.  So the
client never finds out if the locktoken is invalid, because the
if-not-if combination never fails.

> 
> Can you please explain again what the issue to be solved is, or point
me
> to
> "the" mailing list message (in the archive) that explains it?

The issue to be solved is that all the client developers who have spoken
up about the if header say that it's too hard to make interoperable.
Every time the client is tested against a new server, some operations on
locked resources fail.  Usually they fail because 
 1. the server expects to see a lock token that the client hasn't
provided,
 2. the server expects a lock token to apply to a specific URL and the
client didn't use the correct URL, 
 3. the client provides a locktoken for a URL that isn't even affected
in the request, and that lock token or URL is incorrect, or 
 4. the lock expired.

The reason why I suggested the approach of defining '*' as a wildcard
for the IF header is because 
 - it removes the need to figure out which URL to put the locktoken on
(fixing #2)
 - when multiple resources are under the same lock, and when the lock
token appears with '*', it's clear that  it applies to any resource
locked with that token (fixing #2 even more);
 - it makes it easier to include lock tokens that aren't actually
required (fixing #3 and making #1 less likely)
 - It's shorter than putting the full URL (although we may still need
comma support) (making #1 easier to achieve by including more lock
tokens before running up against length limitations)

Lisa

Received on Saturday, 23 November 2002 17:13:15 UTC