Re: Issue #68: UNLOCK_WITHOUT_GOOD_TOKEN

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

Julian wrote on 06/06/2004 03:28:21 PM:
> 
> "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
> 
> [attachment "068_UNLOCK_WITHOUT_GOOD_TOKEN.js.gz" deleted by 
> Geoffrey M Clemm/Lexington/IBM]