- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 26 Jul 2011 13:44:37 +1200
- To: <ietf-http-wg@w3.org>
On Tue, 26 Jul 2011 02:38:37 +0200, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >>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. > > This should refer to disclosure or something like that rather than > leak- > age (you wouldn't design a protocol that intentionally leaks > something), > and `Vary: *` strikes me as odd in this context (why, then, doesn't > the > use of Authorization imply just `Vary: Authorization`, for instance). I've been thinking along these lines recently too. It seems Authorization, ETag, and maybe others should be implicit Vary: headers. But that text seems to belong better in the definition of Vary: and seems rather out of place in areas like auth. For instance, non-caching agents do not need to bother with Vary:, but may want to do authentication. So there should be no need to make them care about Vary: by mentioning a dependence on its syntax by Authoritzation:. AYJ > > I would rather say something along the lines that use of > "Authorization" > implies that the message is confidential with respect to the > credentials > provided in that header, meaning messages should be treated as if > they > had `Cache-Control: private`, and that new schemes must take explicit > measures to ensure the confidentiality of messages, like using that > same > header, because deployed servers are otherwise unaware of the > semantics.
Received on Tuesday, 26 July 2011 01:45:14 UTC