Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN

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