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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 25 Jul 2011 23:54:07 +0200
Message-ID: <4E2DE5FF.7060801@gmx.de>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2011-07-25 05:19, Manger, James H wrote:
> ...
>> 2) Clarify that an Authentication scheme that uses WWW-Authenticate and/or 401 MUST use the Authorization header in the request, because of its implications for caching. Schemes MAY specify additional headers to be used alongside it.
> Not so great.
> If an authentication mechanism uses the Authorization header then it benefits from some default caching rules. Good.
> Plenty of other authentication mechanisms don't use that header, primarily because they operate at higher or lower layers of the protocol stack (eg forms, cookies, TLS...). Even in these cases a WWW-Authenticate response header can be a useful signal about the authentication options available. They may need to handle caching explicitly, but they can do that.
> If anything needs to be said, perhaps something like the following could be appended to section 4.1 "Authorization":
>    A server may need to explicitly indicate the cachability of responses
>    if a request uses an authentication mechanism that does not involve
>    the Authorization header.
> ...

Good catch. I knew we were missing something.


Use of the Authorization header to transfer credentials implies 
"Cache-Control: private" [ref] and thus affects cacheability of 
responses. Thus, definitions of new authentication schemes that do not 
use "Authorization" will need to ensure that response messages do not 
leak in an unintended way, for instance by specifying "Cache-Control" or 
"Vary: *" [ref] explicitly.

Feedback appreciated,

Received on Monday, 25 July 2011 21:54:40 UTC

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