Subject: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Jun 2004 21:28:21 +0200

Hi,

"What should UNLOCK return if a bad token is provided or no token. (This 
might be contingent on UNLOCK_NEEDS_IF_HEADER.)"

I just tested this, here are the results (test script attached):

(a) Microsoft IIS 5.0: (a1) no lock token: 400, (a2) bad lock token: 412.

(b) Apache/Moddav 2.0.49: (b1) no lock token: 400, (b2): bad lock token: 
412.

(c) SAP Enterprise Portal 5SP6: (c1) no lock token: 412, (c2): bad lock 
token: 412.

(d) Xythos (Sharemation): see (c). (I also note that Xythos is returning 
invalid lock tokens)

Summarizing:

- we can't guarantee a specific status code,

- we should define a specific precondition (see proposal at 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.5>)

- we should talk about what is the right thing to do here -- basically 
we need to answer whether "lock-token" is a request header that 
contributes to precondition checking as defined by RFC2616 
(<http://greenbytes.de/tech/webdav/rfc2616.html#status.412>) -- if we 
can agree on this, Apache/moddav's behaviour would be correct.

Feedback appreciated,

Julian

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 6 Jun 2004 20:20:21 -0400

I would vote for treating the lock-token as a request header
that contributes to precondition checking, so I agree with
the ModDav/Microsoft behavior.

Cheers,
Geoff

> [attachment "068_UNLOCK_WITHOUT_GOOD_TOKEN.js.gz" deleted by 
> Geoffrey M Clemm/Lexington/IBM]

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Jun 2004 09:35:49 +0200

> the ModDav/Microsoft behavior.

'%"$%$§! I mistyped the results. The actual results are:

410.

RFC2616 treats exactly all "If-*" headers as defining preconditions. 
RFC2518 adds "If" (which is obvious) and also explicitly "Overwrite" 
(but at least it's clear about it). As RFC2518 nowhere states that the 
"Lock-Token" header expresses a "precondition", I'm leaning to 
favorizing Apache's behaviour (which is *not* what IIS does...).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Jun 2004 10:11:50 +0200

> (b) Apache/Moddav 2.0.49: (b1) no lock token: 400, (b2): bad lock token: 

s/410/400/g

Sigh.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 7 Jun 2004 07:21:13 -0400

Since none of the current implementations agree, I'd go with the
one that seemed to be trying the hardest to implement what the
specification says, and I agree with Julian that this is the Apache
behavior.

Cheers,
Geoff

> 400.

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 7 Jun 2004 14:20:13 -0700

Is there some advantage to having a different error code for these two 
cases, or distinguishing between this error and the dozens of problems 
that can cause a 400 response?  Apache's model does not distinguish 
what the error is.    So the Microsoft approach has the advantage of 
distinguishing the two different cases. The Xythos/SAP approach has the 
advantage of using a more specific code (400 is the most generic form 
of bad request code, therefore less specific than 412) although it's 
the same for both these cases under discussion.  However, 412 is a 
little too specific for the case where the client omitted the lock 
token header entirely -- clients shouldn't have to expect a 412 error 
when the client sends a request without any "conditional" headers at 
all.

I don't have a strong opinion here so I'm not disagreeing with Geoff; I 
just don't know what's a good reason on which to base our choice, and 
wanted to list a few potential justifications.  Yet another 
justification could be "we have two servers doing it the same way, 
let's do it that way".

Any other commenters before we declare a (very rough) consensus?  .Mac 
server implementors could tell us what they do...

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Jun 2004 00:06:52 +0200

Lisa Dusseault wrote:

> that can cause a 400 response?  Apache's model does not distinguish what 
> the error is.    So the Microsoft approach has the advantage of 

I was asking because we have an open issue on that. It seems that we 
can't guarantee a particular server behaviour, but I was still wondering 
what would be the most correct status for each of these cases. The spec 
*should* state something about that.

That being said, a spec revision should define specific precondition 
names, in which case what kind of 4xx is returned becomes less 
important. A new client will just detect the general failure code, and 
then take a look at the response body.

> advantage of using a more specific code (400 is the most generic form of 
> bad request code, therefore less specific than 412) although it's the 
> same for both these cases under discussion.  However, 412 is a little 
> too specific for the case where the client omitted the lock token header 
> entirely -- clients shouldn't have to expect a 412 error when the client 
> sends a request without any "conditional" headers at all.

Correct. So it would be nice if we could decide whether "lock-tokem" is 
an header that contributes to "precondition" checks as defined per 
RFC2616 (I think it shouldn't).

> justification could be "we have two servers doing it the same way, let's 
> do it that way".
> 

Best regards, Julian

---

From: John Baumgarten <[email-masked]>
Date: Mon, 7 Jun 2004 16:30:17 -0700

In the pending maintenance release running in our lab (not necessarily 
what's up on .mac today), we return, respectively:

HTTP/1.1 412 Precondition Failed: Lock-Token header missing
HTTP/1.1 409 Conflict: Lock-Token is invalid

>
> .Mac server implementors could tell us what they do...
>

JS "Jake" Baumgarten
Apple .Mac Backend Server Engineering

+1-408-974-0043
[email-masked]
Loc: VG5-1045   MS: 82-EC
20605 Valley Green Dr, Cupertino CA 95014 USA
www.apple.com

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Jun 2004 08:49:15 +0200

>> .Mac server implementors could tell us what they do...

Jake,

thanks for the feedback. This contributes to the picture -- clients will 
have to expect almost everything between 400 and 499.

At the end of the day, a revised spec should

- define specific RFC3253-like precondition identifiers, so that new 
software can precisely find out what went wrong,

- give server implementors guidelines which 4xx code to choose (in 
particular, we should answer that question whether "lock-token" 
contributes to the set of request headers that can cause a 412 
Precondition Failed),

- give client implementors guidelines how to interpret server responses 
(such as first check for DAV:error response body, then possibly fall 
back to generic HTTP status usage).

I'll try to capture this in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#method.preconditions.and.postconditions> 
today.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Jun 2004 14:59:24 +0200

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