- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 26 Jul 2011 11:14:06 +1200
- To: <ietf-http-wg@w3.org>
On Mon, 25 Jul 2011 23:54:07 +0200, Julian Reschke wrote: > 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 Was about to suggest exactly that. Sound great. AYJ
Received on Monday, 25 July 2011 23:14:45 UTC