- From: Tyler Close <tyler.close@gmail.com>
- Date: Wed, 3 Feb 2010 13:55:09 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>, Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
On Wed, Feb 3, 2010 at 1:32 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > Tyler Close wrote: >> >> On Wed, Feb 3, 2010 at 1:00 AM, Jonas Sicking <jonas@sicking.cc> wrote: >>> >>> Another thing that might be worth noting is that if the UA contains a >>> HTTP cache (which most popular UAs do), the UA must never use a cached >>> response that was the result of a request that was made with >>> credentials, when making a request without. The same goes the other >>> way around. >> >> I gather this is because sites do not reliably use the Vary header? > > "When a shared cache (see Section 13.7) receives a request containing an > Authorization field, it MUST NOT return the corresponding response as a > reply to any other request, unless one of the following specific exceptions > holds:..." > > <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.8> AFAICT, RFC 2616 only does a special case for the Authorization header, which leaves me wondering what shared caches do for other kinds of credentials, such as cookies or the NTLM authentication that Jonas referred to. For example, if an origin server responds to a request with cookies by sending a response with no Vary header and no Cache-Control: private or other disabling of caching, would the proxy use the response to respond to a later request without cookies? Do proxies commonly implement a special case for the Cookie header, similar to the Authorization header? Do origin servers commonly have this bug? --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Wednesday, 3 February 2010 21:55:44 UTC