RE: Submitting lock tokens without a validity check

Thanks for the summary, Geoff.

Some thoughts/questions:

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Clemm, Geoff
> Sent: Thursday, November 21, 2002 4:52 AM
> To: 'Webdav WG'
> Subject: Submitting lock tokens without a validity check
>
>
> 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?

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

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

> Advantage of proposal 1:
> - It does not require defining an extra header.
> Advantage of proposal 2:
> - It requires 40% fewer strings per resource (3 non-constant strings
> instead of 5 non-constant strings).  Lisa: You calculated that
> proposal one requires four times as many non-constant strings ... how
> did you get that number?

With my minimization above, I'm getting only one additional non-constant
string.

> I believe that it is not appropriate to add a new header to the protocol
> just to decrease the header length for this particular use case by 40%.

Agreed.

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

Julian

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

Received on Thursday, 21 November 2002 03:53:13 UTC