- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 25 Jul 2011 23:54:07 +0200
- 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. Maybe...: 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, Julian
Received on Monday, 25 July 2011 21:54:40 UTC