Re: Chrome Bug: screws up CORS by using different-origin disk cache version

On 2017-08-12 22:08, Tim Berners-Lee wrote:
> Alex
> 
> Notwithstanding issues with the design of CORS, Chrome doesn’t in fact
> do it properly.
> 
> If you request the same resource first from one origin and then from
> another, it serves the cached version, which then fails cord because the
> Origin and access-control-allow-origin
> headers don’t match.  This even when the returned headers have “Vary:
> Origin”, which should prevent that same cached version being reused for
> a different origin.
> 
> This has been a problem for a long time.  It is frustrating.  Do you
> have a timescale for fixing it in Chrome? 
> 
> Chrome Version 59.0.3071.115 (Official Build) (64-bit)
> 
> Tim
> 
> 
> 
> Console log:
> 
> 
> Fetch API cannot load https://dokie.li/new. The
> 'Access-Control-Allow-Origin' header has a value 'https://foobar.com'
> that is not equal to the supplied origin. Origin 'http://localhost:3080'
> is therefore not allowed access. Have the server send the header with a
> valid value, or, if an opaque response serves your needs, set the
> request's mode to 'no-cors' to fetch the resource with CORS disabled.
> 
> 
> Network tab:
> 
>  1.
>     Request URL:
>     https://dokie.li/new
>  2.
>     Request Method:
>     GET
>  3.
>     Status Code:
>     200 (from disk cache)
>  4.
>     Remote Address:
>     128.199.36.58:443
>  5.
>     Referrer Policy:
>     no-referrer-when-downgrade
> 
> Response headers:
> 
>  1.
>     accept-ranges:
>     bytes
>  2.
>     access-control-allow-credentials:
>     true
>  3.
>     access-control-allow-headers:
>     Link, Location, Accept-Post, Content-Type
>  4.
>     access-control-allow-methods:
>     POST, GET, HEAD, OPTIONS
>  5.
>     access-control-allow-origin:
>     https://foobar.com
>  6.
>     access-control-expose-headers:
>     User, Location, Link, Vary, Last-Modified, ETag, Accept-Patch,
>     Accept-Post, Updates-Via, Allow, Content-Length
>  7.
>     content-length:
>     2303
>  8.
>     content-type:
>     text/html; charset=UTF-8
>  9.
>     date:
>     Sat, 12 Aug 2017 15:00:31 GMT
> 10.
>     etag:
>     "8ff-554fac4f3cdf1"
> 11.
>     last-modified:
>     Sun, 23 Jul 2017 11:55:06 GMT
> 12.
>     server:
>     Apache/2.4.25 (Ubuntu)
> 13.
>     status:
>     304
> 14.
>     vary:
>     Origin,Accept-Encoding
> 15.
>     x-content-type-options:
>     nosniff
> 
> 
> Request headers
> 
>      1.
> 
> 
>         Provisional headers are shown
>      2.
>         accept:
>         image/*;q=0.9, */*;q=0.1, application/rdf+xml;q=0.9,
>         application/xhtml+xml, text/xml;q=0.5, application/xml;q=0.5,
>         text/html;q=0.9, text/plain;q=0.5, text/n3;q=1.0, text/turtle;q=1
>      3.
>         Origin:
>         http://localhost:3080
>      4.
>         Referer:
>         http://localhost:3080/foobar/Public/Test/
>      5.
>         User-Agent:
>         Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6)
>         AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115
>         Safari/537.36
> 
> 
> 
> 
> $ curl -I https://dokie.li/new
> HTTP/1.1 200 OK
> Date: Sat, 12 Aug 2017 19:52:41 GMT
> Server: Apache/2.4.25 (Ubuntu)
> Upgrade: h2,h2c
> Connection: Upgrade
> Last-Modified: Sun, 23 Jul 2017 11:55:06 GMT
> ETag: "8ff-554fac4f3cdf1"
> Accept-Ranges: bytes
> Content-Length: 2303
> Access-Control-Allow-Credentials: true
> Access-Control-Allow-Methods: POST, GET, HEAD, OPTIONS
> Access-Control-Allow-Headers: Link, Location, Accept-Post, Content-Type
> Access-Control-Expose-Headers: User, Location, Link, Vary,
> Last-Modified, ETag, Accept-Patch, Accept-Post, Updates-Via, Allow,
> Content-Length
> Vary: Origin,Accept-Encoding
> X-Content-Type-Options: nosniff
> Content-Type: text/html; charset=UTF-8
> 
> $ 
> 

I'm experiencing this issue in:

* Chromium 60.0.3112.78 Built on Ubuntu , running on Ubuntu 17.04
* Mozilla Firefox 57.0a1, Ubuntu 17.04

In window tab1 with URL1, there are no issues, but tab1 has issue with
URL2 (same domain). Issue with URL2 is b/c tab2 originally making that
request. Similarly, tab2 doesn't have issues with URL2, but it has an
issue with URL1.

-Sarven
http://csarven.ca/#i

Received on Sunday, 20 August 2017 19:33:51 UTC