Re: ticket #78 (Relationship between 401, Authorization and WWW-Authenticate)

On 16/09/2010, at 2:26 AM, Julian Reschke wrote:

> Hi,
> 
> I just checked the history of this bug, following several threads, and it appears this is really a *set* of issues...
> 
> 
> 1. Relation between status code 401 and WWW-Authenticate
> 
> 401 responses MUST include a WWW-Authenticate, but the opposite is not true.
> 
> Should we state more clearly in <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-11.html#header.www-authenticate> what this field means on a 2xx response? Any response?

We could define that WWW-Authenticate doesn't have defined semantics on other status codes. The only thing that gives me pause here is that this implies we'd need to do so for all other headers; perhaps this feeds into the discussion for common considerations when defining a header.


> 2. Relation between WWW-Authenticate and Authorization fields?
> 
> Does every authentication scheme need to specify the credentials in "Authorization"? <http://tools.ietf.org/html/draft-broyer-http-cookie-auth-00> doesn't, and this doesn't seem to be a problem in practice (as long as cacheability is properly addressed)

Agreed. At most, we should just point out that that's a useful place to consider.


> 3. Should we specify how to handle a 401/WWW-Authenticate that does not contain any known schemes?
> 
> It appears all browsers nowadays display the message payload, which clearly is the right thing to do if we ever want to deploy new schemes.
> 
> Given the fact that implementations do the right thing, do we need to say more?

I think it would be good for it to be explicit *somewhere*; I'm not sure that HTTP is the right place, unless we either publish a new spec ("HTTP for Browsers") or very carefully define a role for them in terms of conformance.

Cheers,


--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 21 October 2010 22:47:39 UTC