RE: GULP vs RFC2518bis

> 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