Tyler Close wrote:
On Wed, Feb 3, 2010 at 1:32 PM, Julian Reschke <[email protected]> wrote:
Tyler Close wrote:
On Wed, Feb 3, 2010 at 1:00 AM, Jonas Sicking <[email protected]> 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
Cookies require
Vary: Cookie
on the response. Or something more drastic.
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
If it follows the applicable specs to the letter, yes (I believe).
proxies commonly implement a special case for the Cookie header,
similar to the Authorization header? Do origin servers commonly have
this bug?
That would be interesting to find out.
We know that "Vary" doesn't work well in practice because of all the
bugs^^^^shortcomings in IE.
Best regards, Julian
