Subject: Re: Issue 079_UNLOCK_BY_NON_LOCK_OWNER

From: Lisa Dusseault <[email-masked]>
Date: Mon, 21 Jun 2004 10:17:28 -0700

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?

Lisa

On May 24, 2004, at 7:50 AM, Julian Reschke wrote:

>
> Hi,
>
> while I was looking for the resolution for 
> "079_UNLOCK_BY_NON_LOCK_OWNER", I came across the following text in 
> bis-05:
>
>> 8.12    UNLOCK Method        The UNLOCK method removes the lock 
>> identified by the lock token in    the Lock-Token request header from 
>> the Request-URI and all other    resources included in the lock.  The 
>> root of the lock MUST be named    by the Request-URI, not any other 
>> resource within the scope of the    lock.  Servers SHOULD redirect 
>> the UNLOCK request to the lock root.     Failing that, servers MAY 
>> fail an UNLOCK request to a resource that    is not directly locked 
>> (not the root of the lock) with error code    400 (Bad Request).
>
>
> 1) It should say "...in the Lock-Token request header from the 
> resource identified by the Request-URI and all other resources 
> included in the lock." (old text from RFC2518)
>
> 2) "The root of the lock MUST be named by the Request-URI, not any 
> other resource within the scope of the lock.": What is this supposed 
> to mean? That the Request-URI MUST identify the lock root? I think 
> this needs clarification.
>
> 3) "Servers SHOULD redirect the UNLOCK request to the lock root. 
> Failing that, servers MAY fail an UNLOCK request to a resource that is 
> not directly locked (not the root of the lock) with error code 400 
> (Bad Request).": Again, I'm not sure what this is supposed to mean. If 
> the resource identified by the Request-URI is not the lock root, it 
> seems that the previous statement REQUIRES the server to fail the 
> request, not to do a "redirect" (what kind of redirect would that 
> be?).
>
> Back to issue "079_UNLOCK_BY_NON_LOCK_OWNER":
>
> "Resolved in part by putting it under ACL control: 
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0002.html 
> and the response that follows it."
>
> The referenced mailing list entry indicates that we want text to be 
> added to the spec, yet I can't find in in bis-05 (al least not under 
> UNLOCK).
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 21 Jun 2004 19:31:01 +0200

> I agree the text needs a little more specifics about what kind of 

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

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 21 Jun 2004 10:37:55 -0700

This would overturn a consensus that had previously been determined at  
a WG meeting that happened together with an interoperability meeting,  
and the consensus was not challenged on the mailing list at that time.

However, given that we have new information -- actual research!   
(thanks) -- it does make sense to reconsider.

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:

>> 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...
> "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.
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 21 Jun 2004 19:50:48 +0200

Lisa Dusseault wrote:

 > ...

Procedural comment: we have the RFC2518 issues list to capture issues 
and their resolutions. If the issues list records a *different* 
consensus than then one you were basing your edits on RFC2518bis on, 
this is a problem. So it's really essential that if consensus indeed 
*changes* at some point of time, this is explicitly 
announced/discussed/reviewed here, and  the issues list indeed gets 
updated accordingly.

That being said, I really don't care a lot about what way we go. 
However, disallowing a behaviour that current servers currently *do* 
allow seems to a bit dangerous. We will at least need to convince 
ourselves that making that change doesn't break any existing clients.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 21 Jun 2004 15:44:34 -0400

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