W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 7 Jun 2004 07:21:13 -0400
To: w3c-dist-auth@w3.org
Message-ID: <OFBBF6072F.E7214F2B-ON85256EAC.003DBFAE-85256EAC.003E6554@us.ibm.com>
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 07:22:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT