Subject: Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN

From: Jason Crawford <[email-masked]>
Date: Sat, 10 Jul 2004 22:37:04 -0400

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?

J.

Julian Reschke <[email-masked]>
06/15/2004 08:59 AM

        To:     [email-masked]
        cc:     Jason Crawford/Watson/IBM@IBMUS
        Subject:        Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN

OK,

to summarize (
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.068_UNLOCK_WITHOUT_GOOD_TOKEN>):

- errors linked to missing or bad tokens in the "lock-token" request 
header do *not* cause a 412 ("lock-token" isn't part of the headers for 
which 412-style preconditions are checked),

- clients need to be able to handle all 4xx status codes anyway,

- we define a specific precondition for missing/bad lock tokens inside 
the lock-token request header, so clients can more precisely identity 
this error condition

Jason, you may want to update your issues list accordingly.

Best regards, Julian

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 11 Jul 2004 13:07:21 +0200

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