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

From: Lisa Dusseault <[email-masked]>
Date: Tue, 6 Jul 2004 10:37:17 -0700

I thought a little more about exactly how the redirect would work and 
there's a number of options, none of them very good.  I think this is 
moot since we seem to prefer #1 accepting the UNLOCK request even on 
the "wrong" URL, but a little discussion anyhow...

The basic idea is that the client gave the wrong URL in the UNLOCK, and 
the server can tell which is the right URL to UNLOCK because of the 
presence of the lock token. So the server is helpful in telling the 
client which URL to UNLOCK in a 3xx response with the lockroot URL in 
the Location header, and this response helps the client understand 
which resource(s)  have been unlocked once the UNLOCK request is 
successful.

But how, exactly, would a redirect work?  According to RFC2616:
  - 301 Moved Permanently would imply that the new URL (the lock root) 
should be used for "any future references".  That's not what we want; 
the original Request-URI could still exist and be used in certain 
circumstances -- it's only this one request the server suggests should 
be redirected.

  - 302 Found would technically work the right way but RFC2616 says that 
"the user agent MUST NOT automatically redirect the request unless it 
can be confirmed by the user".  I'm not sure user agents would follow 
that requirement or wish to.

  - 303 See Other would result in the client sending a GET to the 
lookroot URL, not a UNLOCK request.

  - 307 Temporary Redirect would work for HTTP 1.1 user agents, but like 
302 "the user agent MUST NOT automatically redirect the request unless 
it can be confirmed by the user".

Lisa

On Jul 4, 2004, at 2:45 AM, Julian Reschke wrote:

> Julian Reschke wrote:
>
>>> On Monday, 06/21/2004 at 10:37 MST, Lisa Dusseault  wrote:
>>>  > 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.
>>>
>>>
>>> No strong preference so just go with what existing servers do.
>> What do you mean by "redirect"? Please be more specific.
>> ...
>
> Lisa,
>
> could you please define what you mean by "redirect"? Otherwise it 
> won't be possible to say something about that option.
>
> The other option we have is...
>
> 3. Server should reject the UNLOCK request if it doesn't address the 
> directly locked resource.
>
> As stated before, my preference is 1) for the simple reasons that
>
> - this is what RFC2518 seems to say,
> - this is what the issues list says as resolution,
> - this is what GULP says after having it synced with the issues list 
> and
> - last but not least this is what servers indeed implement.
>
> Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Julian Reschke <[email-masked]>
Date: Sat, 10 Jul 2004 11:15:57 +0200

Lisa Dusseault wrote:

> moot since we seem to prefer #1 accepting the UNLOCK request even on the 
> "wrong" URL, but a little discussion anyhow...
> ...

OK, I think we clearly have reached consensus to allow clients to 
specify an indirectly locked resource in UNLOCK requests. This is because

- this is what servers do implement,
- what the issues list already mentioned as resolution for issue 65 
(UNLOCK_WHAT_URL) (<http://www.webdav.org/wg/rfcdev/issues.htm>)
- this is what GULP states after the changes discussed here some weeks 
ago 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0177.html>)

So please

- update the issues list accordingly (issue 
LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY can be closed as well)
- revert the change in RFC2518bis-05, possibly only clarifying the 
original language

In 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>, 
I already say:

"The UNLOCK method removes the lock identified by the lock token in the 
Lock-Token request header from the resource identified by the 
Request-URI, and all other resources included in the lock. Note that the 
UNLOCK request may be submitted to any resource locked by that lock 
(even those that are locked indirectly)."

I'll also mark the issue 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html#063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY> 
closed.

Best regards, Julian