- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 12 Jul 2004 09:23:56 +0200
- To: Jason Crawford <ccjason@us.ibm.com>
- Cc: Julian Reschke <nnjulian.reschke___at___gmx.de@smallcue.com>, nnw3c-dist-auth___at___w3.org@smallcue.com
Jason Crawford wrote: > > > > Julian, I can't tell from this what you are recommending a server > return > > > if (1) a bad token is provided or (2) no token is provided. Could you > > > please resumarize your conclusions? > > > > (1) Would be a violation of the precondition DAV:lock-token-matches > > > (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc. > > 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"? Yes, I did: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0155.html>. This answer *does* work in the context of RFC2518bis; it defines a precondition that would need to be added to the spec text. Speaking of which: it would be really nice if the working group would make some progress on the question whether we want to separate locking from RFC2518bis. See...: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0049.html> > > (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"? Yes, we did test servers and their behaviour is inconsistent, thus we need to realize that clients MUST handle any 4xx and 5xx response in a robust way...: > > 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. Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 12 July 2004 03:24:38 UTC