RE: Submitting lock tokens without a validity check

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > 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