Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN

Jason Crawford wrote:

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

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

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. Clients 
that are really interested in why the request failed can get far more 
reliable information by inspecting the DAV:error message body.

Best regards, Julian


(note that because I closed the issue in version -03 of my draft, the 
issue entry now has moved to 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-03.html#rfc.issue.068_UNLOCK_WITHOUT_GOOD_TOKEN>).


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Sunday, 11 July 2004 07:07:56 UTC