- From: Yutaka OIWA <y.oiwa@aist.go.jp>
- Date: Wed, 20 Jun 2012 19:08:26 +0900
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Dear Julian, 2012/6/20 Julian Reschke <julian.reschke@gmx.de>: >> I think this (use 401 instead of 403) should be kept for two reasons: >> >> * Without 401 status, client will not know that changing >> the user name and the password will solve the >> inaccessibility issue. > > > Sorry? > > "The server understood the request, but refuses to authorize it. Providing > different user authentication credentials might be successful, but any > credentials that were provided in the request are insufficient. The request > SHOULD NOT be repeated with the same credentials." - > <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.7.4.3> I see. I noticed now that this was changed incompatibly from RFC 2616. Thank you for telling me. 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 new definition is intentionally breaking existing server implementations. But it these are under clear consensus and intention, it's OK for me (but sure?). Mark, can I ask how do you think? # With the older semantics to use 401 for authz-failure, # failed authorization was recoverable # (although in somewhat uncomfortable way). Accepting the above consequences, the Mark's text is making sense. However, we will not able to define 403 to be "one of the authentication-related states" as an original proposal, because 403 already has several other use cases which is directly conflicting. # More specifically, clients could not assume that 403 has # any meaning for authentication-related status. Don't we need (do we have a clear way, or do we need to define how) to distinguish failed authz from other generic access privilege failures? # For example, is "403 response with WWW-Authenticate: header, # as a response for request with Authorization: header" # restrictive enough for defining such a status? -- 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:09:18 UTC