W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [XHR2] AnonXMLHttpRequest()

From: Tyler Close <tyler.close@gmail.com>
Date: Wed, 3 Feb 2010 13:55:09 -0800
Message-ID: <5691356f1002031355p69fff542tcd914240bf4ef654@mail.gmail.com>
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?


"Waterken News: Capability security on the Web"
Received on Wednesday, 3 February 2010 21:55:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:04 UTC