- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 21 Jul 2010 15:46:08 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Jul 21, 2010, at 4:46 AM, Julian Reschke wrote: > OK, so: > > 401 -> you can't do this because you haven't authenticated or the credentials are invalid. Try again only if you can change the credentials (user login or re-login). > 403 -> this is forbidden for you, but authenticating as somebody else may help yep, though forbidden can be broken down into cases: a) user agent sent no credentials if authentication might help, server should respond 401, otherwise 403 b) user agent sent credentials that are invalid or expired server should send 401 c) user agent sent valid credentials but doesn't have access server should send 403 > 405 -> this method is not allowed/supported/applicable for this resource The method you just tried is not allowed for this resource. a) user agent sent no credentials if authentication might help, server should respond 401, otherwise 405 b) user agent sent credentials that are invalid or expired server should send 401 c) user agent sent valid credentials but isn't allowed server should send 405 > The use case you mentioned is interesting and came up before: what's a good way to signal to non-authenticated users that authenticating might give access to more operations? "Vary: Authorization" comes to mind. But that still would require the "public" server to know about the "authoring" server, in which case it might be possible to properly return information about method support... Generally speaking, security folks prefer not to tell clients about the ways to get in if they are supposed to know that already. For example, in role-based access control it is typical to hide all operations that are not available to the user, even though the same user can simply change their login to see them. The assumption is that there should be other (application driven) hints that will tell them when to change their user settings. Note that this is designed for follow-your-nose (REST-based) applications. It doesn't work as well for applications that think HTTP is a filesystem protocol. ....Roy
Received on Wednesday, 21 July 2010 22:46:43 UTC