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

Re: WWW-Authenticate, Authorization and 401's

From: Hugo Haas <hugo@yahoo-inc.com>
Date: Fri, 17 Aug 2007 09:48:58 -0700
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
Message-Id: <200708170948.58398.hugo@yahoo-inc.com>

On Friday 17 August 2007 03:34, Julian Reschke wrote:
> Stefan Eissing wrote:
> > Am 17.08.2007 um 11:30 schrieb Julian Reschke:
> >> - force servers not to return a 401 at all.
> >>
> >> I think the latter would be bad: in this case I'd prefer a 401 over a
> >> 400 or (gasp!) a 200.
> >
> > Well, sending WWW-Authenticate along with 401 is a MUST. So, how would a
> > server send a 401 *without*
> >  complying to the basic framework Mark is talking about?
> In theory it could invent an auth scheme name (and then not support it).
> For a client that would be indistinguishable from a real scheme that it
> happens not to support.
> I just want to make sure that we don't end up promoting serving HTML
> login forms with 200, because 401 isn't allowed. Maybe the language for
> 401 could be enhanced to state that if a server does require some kind
> of authentication, but does not support HTTP auth, 403 SHOULD be used?

I don't think that people will necessarily return a 200 instead, but rather a 
403, a 400, or a custom 4xx error code.

As you mention, the debate seems to gravitate around whether it's OK to return 
a 401 with "WWW-Authenticate: Foo", Foo being a scheme which does not use the 
Authorization header to pass credentials (it's not clear to me from reading 
the specs as I mentioned in my original email).

It doesn't seem harmful: if  a client understands Foo, then it'll do the right 
thing, and if it doesn't know about Foo, then it won't be able to do anything 
in response to it, so it won't do anything wrong.

Received on Friday, 17 August 2007 16:50:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC