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

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

Received on Tuesday, 6 July 2004 13:47:09 UTC