- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 22 Feb 2012 12:16:20 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Robert Collins <robertc@squid-cache.org>, Barry Leiba <barryleiba@computer.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hi Julian, On Wed, Feb 22, 2012 at 09:38:08AM +0100, Julian Reschke wrote: > On 2012-02-22 07:49, Willy Tarreau wrote: > >On Wed, Feb 22, 2012 at 11:53:27AM +1300, Robert Collins wrote: > >(...) > >>OAuth certainly *thinks* it provides *both* Authentication *and* > >>Authorization, and it uses the same header that Basic and Digest do - > >>Authorization. > > > >I think that this simply shows a semantic mistake from the past, where > >authentication and authorization were a bit conflated. Look at the HTTP > >headers, you have the server send "www-authenticate", and the client > >responds with "authorization" ! At least this is a point we should clarify > >in the next version, because I know too many people who consider that > > We can clarify it in *this* version. Do you have a specific proposal for > Part 7? Unfortunately no, because I think the confusion is too much anchored in people's mind. (...) > <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#status.403>: > > "7.4.4 403 Forbidden > > 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. > > If the request method was not HEAD and the server wishes to make public > why the request has not been fulfilled, it SHOULD describe the reason > for the refusal in the representation. If the server does not wish to > make this information available to the client, the status code 404 (Not > Found) MAY be used instead." > > What's wrong with this status code? As far as I can tell, what's missing > is UI, not protocol elements. There's nothing wrong, but I've never seen a browser suggest to logout/relog upon a 403. Also, since browsers don't offer the possibility to logout in general, it's hard to suggest that this possibility should be specifically offered upon 403. In fact it's the global authentication/authorization mechanism that should be cleaned up in 2.0 and I don't think it's too hard, we just have to clearly state that we might break *some* of the 1.1 assumptions. Best regards, Willy
Received on Wednesday, 22 February 2012 11:16:58 UTC