Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN

> > Julian, I can't tell from this what you are recommending a server 
return
> > if (1) a bad token is provided  or (2) no token is provided.  Could 
you
> > please resumarize your conclusions?
> 
> (1) Would be a violation of the precondition DAV:lock-token-matches
> 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.
> section.5.2.1>),
> and thus would cause a 4xx status with DAV:error/DAV:lock-token-matches.
> The most appropriate 4xx code here seems to be 403 (as there doesn't
> seem to be a way to change the state of the resource in a way that the
> same request would succeed).
I can only update the issues list with resolutions that work in the 
context of 2518.  My copy of 2518 doesn't support much of what you just 
said.   But it sounds to me that you're recommending 403 as the returned 
status which is supported.   Have we checked what existing servers 
return?... or do we just want to go with "SHOULD return 403"? 



> 
> (2) Is a violation of the request syntax (which requires a Lock-Token
> header), thus would result in a plain 400. We *could* add a specific
> precondition name for that, but that seems to me like over-engineering.
Okay.   Have we tested servers?  Or do we just want to go with "SHOULD 
return 400"?


> Anyway, clients MUST be able to properly handle all kinds of 4xx status
> codes in a robust manner; so I think it's a bad idea to write specs in a
> way that suggest that certain other 4xx codes will never occur. 
Sounds good.