RE: Submitting lock tokens without a validity check

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Saturday, November 23, 2002 11:13 PM
> To: julian.reschke@gmx.de
> Subject: 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.

Yes. Really weird. Why would it want to know then? It will certainly find
out when it finally does the UNLOCK. Where's the problem with that?

> >
> > 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,

So we need to clarify which are required.

>  2. the server expects a lock token to apply to a specific URL and the
> client didn't use the correct URL,

Fix the client or the server.

>  3. the client provides a locktoken for a URL that isn't even affected

If the URL isn't affected, use If header syntax that makes the matching of
the lock optional (we have that),

> in the request, and that lock token or URL is incorrect, or

Fix the client.

>  4. the lock expired.

Yes. That's the point of locking. If it expired before it should, the server
may be broken. Fix it. On the other hand, somebody may have removed the lock
*on purpose*. We *want* the request to fail in this case.

> 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)

But that's trivial to figure it. It's the URI that was used to create the
LOCK.

>  - 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);

See answer above.

>  - it makes it easier to include lock tokens that aren't actually
> required (fixing #3 and making #1 less likely)

We already have a syntax for that.

>  - 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)

I'm stricty against changing the *existing* protocol just to minimize header
sizes.

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

Received on Sunday, 24 November 2002 08:21:00 UTC