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

AltStyle によって変換されたページ (->オリジナル) /