Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN

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

On Jun 7, 2004, at 4:21 AM, Geoffrey M Clemm wrote:

> 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
>
> Julian wrote on 06/07/2004 03:35:49 AM:
>>
>> Geoffrey M Clemm wrote:
>>
>>> 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.
>>
>> '%"$%$§! I mistyped the results. The actual results are:
>>
>> (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:
>
>> 400.
>>
>> (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)
>>
>> 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...).

Received on Monday, 7 June 2004 17:21:10 UTC