- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 21 Nov 2002 09:52:33 +0100
- To: "Clemm, Geoff" <gclemm@rational.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
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