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


From: Jason Crawford <ccjason@us.ibm.com>
Date: Sun, 11 Jul 2004 22:01:52 -0400
To: Julian Reschke <nnjulian.reschke___at___gmx.de@smallcue.com>
Cc: nnw3c-dist-auth___at___w3.org@smallcue.com
Message-ID: <OF07C1D893.6DBC47A1-ON85256ECF.00093CA0-85256ECF.000B289F@us.ibm.com>
> > Julian, I can't tell from this what you are recommending a server 
> > if (1) a bad token is provided  or (2) no token is provided.  Could 
> > please resumarize your conclusions?
> (1) Would be a violation of the precondition DAV:lock-token-matches
> section.5.2.1>),
> and thus would cause a 4xx status with DAV:error/DAV:lock-token-matches.
> The most appropriate 4xx code here seems to be 403 (as there doesn't
> seem to be a way to change the state of the resource in a way that the
> same request would succeed).
I can only update the issues list with resolutions that work in the 
context of 2518.  My copy of 2518 doesn't support much of what you just 
said.   But it sounds to me that you're recommending 403 as the returned 
status which is supported.   Have we checked what existing servers 
return?... or do we just want to go with "SHOULD return 403"? 

> (2) Is a violation of the request syntax (which requires a Lock-Token
> header), thus would result in a plain 400. We *could* add a specific
> precondition name for that, but that seems to me like over-engineering.
Okay.   Have we tested servers?  Or do we just want to go with "SHOULD 
return 400"?

> Anyway, clients MUST be able to properly handle all kinds of 4xx status
> codes in a robust manner; so I think it's a bad idea to write specs in a
> way that suggest that certain other 4xx codes will never occur. 
Sounds good.
Received on Sunday, 11 July 2004 22:02:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:30 UTC