Re: Call for consensus on UNLOCK Request-URI being lock root

No preference.  If we had no existing clients counting on this,
I'd go with the requirement that UNLOCK MUST be applied to the
lock root, but if there existing clients would fail in some non-trivial
way because of this, then I'd allow the UNLOCK to apply to any URL
that was protected by that LOCK.

Cheers,
Geoff

Lisa wrote on 06/21/2004 01:37:55 PM:

> WG members please indicate your old, new, and/ or current preference, 
> with reasons if they've not already been stated here:
> 1. Should servers accept an UNLOCK request where the Request-URI names 
> any resource covered by the lock named in the lock token?
> 2. Or, should servers redirect that UNLOCK request to the root of the 
> lock?
> 3. If something else, please explain.
> 
> Part of the rationale for #2 in the original consensus was to make sure 
> that clients understood the scope of the lock they were attempting to 
> remove -- so that the entire collection, if previously marked as 
> locked, would now be shown as unlocked, rather than just the resources 
> covered by the Request-URI.
> 
> Please indicate your preference by July 6.
> 
> Lisa
> 
> On Jun 21, 2004, at 10:31 AM, Julian Reschke wrote:
> 
> >
> > Lisa Dusseault wrote:
> >
> >> I'm fine with 1 and 2, but I don't understand problem #3.
> >> What this text attempts to say is that the server SHOULD redirect an 
> >> UNLOCK request to the correct URI if the UNLOCK request has the wrong 
 
> >> URI for the lock token -- that's the ideal response.  If the server 
> >> can't do that, then as Plan B, the server MAY [or SHOULD?] return a 
> >> simple error.
> >> What's wrong with a specification having a Plan B if the software 
> >> can't do Plan A for some reason?  Returning errors is the typical 
> >> Plan B anyway...
> >> I agree the text needs a little more specifics about what kind of 
> >> redirect -- suggestions?
> >
> > Well, if in the context of an HTTP related spec you talk about 
> > "redirecting" something, many will read that as having to do with a 
> > 3xx status code. I'm still not sure whether this is what you intend to 
 
> > say or not.
> >
> > If, on the other hand, you're saying that the server SHOULD accept the 
 
> > UNLOCK even if the request URI is only indirectly locked (and just do 
> > the unlock then), then it doesn't make sense to add any more text. As 
> > Geoff pointed out recently about text *I* did write, saying "server 
> > SHOULD do 'x' and MAY do not('x')" is bad specification text; it only 
> > confuses the audience.
> >
> > Anyway, quoting myself in
> >
> > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ 
> > 0170.html>:
> >
> > "OK,
> >
> > here are some actual test results:
> >
> > a) Apache/moddav: allows UNLOCK on indirectly locked resources,
> > b) Xythos: same,
> > c) SAP Enterprise Portal: same,
> > d) Microsoft IIS: no support for depth infinity locks.
> >
> > Thus the current text in the issues resolution "Resolved that you can
> > specify any URL locked by the lock you want to unlock" does indeed
> > reflect current implementation experience, and this is what spec
> > revisions should be saying.
> >
> > Thus:
> >
> > 1) RFC2518bis should undo that change, and
> > 2) GULP should be updated accordingly (I'll do that for my in-document
> > copy of GULP at
> > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking- 
> > latest.html#rfc.section.C>."
> >
> >
> > ...and that's what I did with (a) my draft and (b) GULP (they both are 
 
> > now consistent with what the issues list states as working group 
> > consensus, see issue 65).
> >
> > Best regards, Julian
> > -- 
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
>