- From: Yutaka OIWA <y.oiwa@aist.go.jp>
- Date: Wed, 20 Jun 2012 19:48:18 +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
Thank you, 2012/6/20 Julian Reschke <julian.reschke@gmx.de>: >> I see. I noticed now that this was changed incompatibly from RFC 2616. >> Thank you for telling me. > Context: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/294> Thanks. I've been late for entering this discussion as I did not noticed that the title was related to authentication issues. # I still *personally* prefer the RFC 2616 design :-) >> 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. > > > How so? Example? The above URL have a link to the page saying IIS use 401 status for that case, and so is Apache. We may say the 403 text alone is not breaking existing implementations (in the way that they say nothing about 401), but the amendment text currently proposed is conflicting with existing implementations. My current feeling after this thread of discussions is to honor both 401 and 403 as desired responses with authz-failure, possibly with preference for 403 for future implementations (if we want). # I would be updating my drafts if such preference is clearly defined. -- 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:49:03 UTC