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

> On 2017-11 -03, at 20:07, Michael[tm] Smith <mike@w3.org> wrote:
> 
> Sarven, Tim,
> 
> Can you confirm whether or not anybody has actually raised in issue in the
> Chrome issue tracker for this?

Not as far as I know
Could you, Alex?

> Because it seems like a genuine bug to be,
> but I’ve not yet been able to find any issue that’s been filed for it.
> 
> In my experience, once somebody takes time to file an issue in the Chrome
> issue tracker, discussion and action start to happen quite quickly there.
> See for example https://bugs.chromium.org/p/chromium/issues/detail?id=775438
> 
>  –Mike
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