- 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
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. Hugo
Received on Friday, 17 August 2007 16:50:06 UTC