- From: Yutaka OIWA <y.oiwa@aist.go.jp>
- Date: Wed, 20 Jun 2012 19:37:43 +0900
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Thank you Mark, 2012/6/20 Mark Nottingham <mnot@mnot.net>: >> Now I have a concern with the text for 403 status for two reasons, >> * any recovery from failed authorization (with successful authentication) >> is completely out of the protocol's provision, and > > The client is still able to submit a new request with different credentials (or no credentials, if it needs a new challenge). My point was "the client will not have a way to know about that possibility on the protocol level, as compared with 401-based solution". I agree that if the client knows it in some way, they can do as you mentioned. >> * the new definition is intentionally breaking existing server implementations. >> But it these are under clear consensus and intention, > > It doesn't make them non-conformant; they can still choose to use those status codes in the manner they are. The current implementations including Apache Basic/Digest auth are not compatible with the proposed text > A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the 403 (Forbidden) status code. as they currently use 401 status for that meaning. Although it is not "MUST" nor "SHOULD", they are still somewhat "against" the new specifications. If we say they are compliant, is there any good way to describe both possibilities and the preference for future implementations? -- Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5]
Received on Wednesday, 20 June 2012 10:38:34 UTC