Subject: RE: Submitting lock tokens without a validity check

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 21 Nov 2002 13:23:29 -0500

From: Julian Reschke [mailto:[email-masked]]

   > From: Clemm, Geoff
   >
   > One of the topics discussed at this weeks WebDAV working group
   > meeting was how to provide a mechanism that would allow a client
   > to submit a set of lock tokens without a validity check (i.e. the
   > request could succeed even if some or all of those lock tokens
   > have expired).  Note that a client needs to submit an If header
   > with etags with such a request, to avoid lock protection.  There
   > are currently two alternative proposals for this (the semantics
   > of these two proposals are identical, so this is a marshalling
   > question):

   Checking: the desired semantics are that the request succeeds
   independently of the lock still being present or not?

Yes.

   > Proposal One: Extend the If header so that it can take a comma
   > separated list of arguments (and therefore can be split into
   > multiple If statements).  To submit a set of lock tokens without
   > a validity check, the following pattern would be used:
   >
   >   If: urlA (tokenA [etagA]) (Not tokenA [etagA])
   >   If: urlB (tokenB [etagA]) (Not tokenB [etagB])
   > ...

   I think this can be minimized to:

     If: urlA (tokenA [etagA]) (Not (<DAV:no-lock>) [etagA])

   (<DAV:no-lock> is the URI of a known not-to-be-present lock, so the
   second List always evaluates to true).

Good point!  That makes the benefit of the second approach only 
a 25% decrease in non-constant strings per resource, rather than
a 40% decrease.

   > Proposal Two: Add a new header for a comma separated list of lock
   > tokens that indicate possession of the lock token but do not
   > cause the request to fail if they are invalid (I neglected to
   > write down the proposed name, so I'll just call it New-Header).
   > Since the etag list can be long when the client holds a large
   > number of locks, the extension defined in alternative one is also
   > required, to handle the possibly large number of etags.  The
   > pattern of usage for this proposal would be:
   >
   >   New-Header: tokenA
   >   If: urlA ([etagA])
   >   New-Header: tokenB
   >   If: urlB ([etagB])
   >   ...

   Is ordering relevant here? So would

     New-Header: tokenB
     If: urlA ([etagA])
     New-Header: tokenA
     If: urlB ([etagB])

   mean the same thing?

Yes, that would mean the same thing, and ordering is not relevant.

   > I am particularly disinclined to optimize this kind of request,
   > because I believe that it is significantly simpler for a client
   > to use a standard If header, and if locks have expired, the
   > request fails, the client deletes from its state those expired
   > locks, and then resubmits the request, replacing the expired
   > locks with etags.  This allows the client to just issue very
   > simple If header requests, i.e. if the lock token for urlA is
   > still valid but the lock token for urlB has expired:
   >
   > If: urlA (tokenA)
   > If: urlB ([etagB])

   Maybe we should discuss enhancements for error reporting for
   precondition failures on if headers? That would probably make it
   easier for a client to recover.

Excellent point!  Currently, I believe the spec is rather vague
on how a client reports a violation of a clause in an If header,
and it would be of great value to clarify this.

Cheers,
Geoff

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 23 Nov 2002 14:15:46 -0800

Julian said: "Checking: the desired semantics are that the request
succeeds
   independently of the lock still being present or not?"

Geoff said: "Yes."

My response: I don't agree with that narrow definition of what's
desired.  I think the problem statement is that the if header is
constantly causing interoperability problems. The desired semantics are
"some semantics that make locks easier to use".

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 24 Nov 2002 13:47:06 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Saturday, November 23, 2002 11:16 PM
> To: 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: Submitting lock tokens without a validity check
>
>
>

Sorry, but that isn't a definition. I doubt it makes sense to try to solve a
set of problems that constantly is being redefined while we are trying to
solve it.

Unless the mostly silent client implementors are willing to write down *why*
locks are hard to use, there's no point in debating it.

So far I've seen the following things mentioned, each of which should have
it's separate entry in the RFC2518 issues list (Jason?):

1) Syntax of If header relies on "long" HTTP headers, for which support
cannot be relied upon (because of proxies). Solution: allow comma separated
format and distribution across several header lines. Note: need to find out
how a client can discover support for this (support for "long" headers *can*
be discovered using TRACE).

2) Clients have both lock tokens and entity tags and want a request to
succeed no matter whether the lock is there or not. Solution: possible with
current If header syntax. Note: very questionable feature.

3) Clients are in doubt which URL to pass for a given lock token. Solution:
clarify that it's the lock root (the URI against which the lock was
created).

4) Clients are in doubt which locks need to be provided for a certain
operation to succeed. Solution 1: try to clarify. Solution 2: submit all
locks using existing If header syntax.

5) Clients want to be notified about expiring/disappearing locks. I wasn't
aware of this before and would like to see the use case. If a client is in
doubt about the state of the lock tokens it holds, it can discover them
using PROPFIND.

Anything else?

Julian

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