Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN

Lisa Dusseault wrote:

> 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 

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

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

Best regards, Julian

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

Received on Monday, 7 June 2004 18:07:29 UTC