W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: Issue 146, was: Users with different access rights in HTTP Authentication

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 21 Jul 2010 13:46:38 +0200
Message-ID: <4C46DE1E.70104@gmx.de>
To: "William A. Rowe Jr." <wrowe@rowe-clan.net>
CC: "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, David Morris <dwm@xpasc.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Atkins <mart@degeneration.co.uk>
On 19.07.2010 22:24, William A. Rowe Jr. wrote:
> ...
> What about framing this in terms of Method Not Applicable (which might be
> unsupported, unimplemented, or simply nonsensical in the context of this
> specific resource), which covers just about everything?
 > ...

+1

On 19.07.2010 23:13, Willy Tarreau wrote:
 > ...
 > or also "not acceptable" ?
 > ...

That would create confusion with the Accept header and status code 406.

On 20.07.2010 07:31, Roy T. Fielding wrote:
 > ...
 > I know this can be confusing, but there is no distinction in terms
 > of what is going on at the server. The distinction is only in what
 > the server wants the client to do next.  The Allow header field may
 > differ based on access rights.  For example, requests can be routed
 > beyond the origin/gateway based on anything in the request, so a user
 > agent sending authenticated credentials may be talking to an entirely
 > different system (e.g., CQ5) than another user agent that has not
 > yet authenticated.  It would not be surprising that an authenticated
 > user is informed about more allowed methods than a non-authenticaed
 > user.  However, we would expect a non-authenticated user to receive
 > a 401 response instead of 405 if that is the case, since what the
 > server wants the client to do next is authenticate.
 >
 > I think there is a lot of room for improvement in the way many of
 > the status codes are described.  We should be emphasizing what the
 > server is trying to communicate, rather than what conditions might
 > lead to such a status.  Although, we might want both in some cases.
 >
 > ....Roy

OK, so:

401 -> you can't do this because you haven't authenticated

403 -> this is forbidden for you, but authenticating as somebody else 
may help

405 -> this method is not allowed/supported/applicable for this resource

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...

Best regards, Julian
Received on Wednesday, 21 July 2010 11:47:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:23 GMT