- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 11 Mar 2003 21:34:19 +0100
- To: "Lisa Dusseault" <lisa@xythos.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Clemm, Geoff'" <gclemm@rational.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, March 11, 2003 9:22 PM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV' > Subject: RE: GULP vs RFC2518bis > > > > > Sorry, I omitted one important detail for this to work. You need one > clause in the OR statement that will succeed, otherwise you'll get a 412 > Precondition Failed response. So take 2, this should work: > > DELETE /tld/ HTTP/1.1 > If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6>) > (<opaquelocktoken:e71d4fae-5dec-22d6-cc76-121d8d23f>) > (Not <nolock>) > > (No line returns, of course) > > The request should work because: > (1) The required lock tokens for the two locked descendants are there But they haven't been submitted for the right URL. Is this really sufficient? > (2) the precondition succeeds because one Ored condition is true (Not > Nolock) "<nolock>" isn't a valid Coded-URL. Using "<DAV:nolock>" instead fails both on moddav and Sharemation (can't try with IIS right now). > With the proposed changes in GULP, part (1) would fail because the > server would have to make sure the tokens were tagged correctly or > matched the Request-URI exactly. I suppose the intention would be to > respond with 423 Locked because although the lock tokens are there, > they're not tagged correctly, even though the precondition is > successful? I think that's a bad idea. The lock tokens are provided; > take them. My understanding is that a client needs to supply the lock tokens tagged for the right URLs. Where's the problem with that approach? It's interoperable and works right now. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 11 March 2003 15:34:29 UTC