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
 (2) the precondition succeeds because one Ored condition is true (Not
Nolock)

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.

Lisa

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> Sent: Tuesday, March 11, 2003 8:46 AM
> To: Lisa Dusseault; 'Clemm, Geoff'; 'WebDAV'
> Subject: RE: GULP vs RFC2518bis
> 
> 
> Lisa,
> 
> > The following request should allow the lock tokens to match and the
> > server should accept both tokens, because they are in an OR list:
> > 
> > DELETE /tld/ HTTP/1.1
> > If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6>)
> > 	(<opaquelocktoken:e71d4fae-5dec-22d6-cc76-121d8d23f>) 
> 
> I just checked this format with 
> 
> 1) moddav
> 2) IIS
> 3) SAP EP
> 4) sharemation
> 
> and none of the servers accept it (and I think that's correct).
> 
> Julian
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
> 
>

Received on Tuesday, 11 March 2003 15:22:20 UTC