Unable to reproduce the issue on reported chrome version 68.0.3440.84 and on latest chrome version #70.0.3515.0 using Windows 10 by following below steps.
Steps: 
---------
1.Launched the chrome.
2.Opened https://portal.loganalytics.io/demo in first tab
3.Opened https://analytics.applicationinsights.io/demo in second tab , and observed that both pages loaded.

Note: Also tried opening the two links in two diffrent windows, observed that the pages loaded.
Attached screencast for reference.

@Reporter: Could you please review the attached screen-cast and confirm if anything being missed here and request you to retry this issue with fresh profile without any extensions/apps or reset all the flags and let us know if issue still persists.

Thanks.!

Deleted: 871971.mp4 7.8 MB

	871971.mp4 7.8 MB View Download

Hi,
Thanks for checking the issue!

The portal is loaded correctly as there is a fallback layer that sends the requests to the origin service rather than to CDN (This obviously affects user experience and performance).

You may see the error if you open Developers tools in the second tab. See the attached screenshot.

Thanks!

Deleted: CDN CORS issue.jpg 745 KB

	CDN CORS issue.jpg 745 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Chrome's caching behavior looks correct to me.

Because the response changes depending on the "origin" header, it is imperative that the cached response include "vary: origin".

This is noted in the Fetch spec:
https://fetch.spec.whatwg.org/#cors-protocol-and-http-caches

If for whatever reason you aren't able to set the Vary, a workaround could be to change your access-control-allow-origin response header to include all the origins (rather than keying it off of the request Origin).

For instance in this example this would also have worked:

access-control-allow-origin: https://portal.loganalytics.io,https://analytics.applicationinsights.io

Hi,
I have to admit your multiple values suggestion was my first attemp to resolve the issue, but then I got an error from Chrome that the access-control-allow-origin value is invalid as it contains multiple values.
I'll try to reproduce it and will post the error message.
Thanks a lot!

It doesn't look like comma-separated origins is allowed by the Fetch spec (not sure why https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin says it is a thing...)

Hi,
I've managed to reproduce the error I got when multiple values are defined in the access-control-allow-origin header:

Access to Script at 'https://applicationanalytics-int.azureedge.net/plugins/auth/laPortalAuthApp.js?_b=f75bed' from origin 'https://ailoganalyticsportal-int.cloudapp.net' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header contains multiple values 'https://ailoganalyticsportal-int.cloudapp.net,https://portal-int.loganalytics.io', but only one is allowed. Origin 'https://ailoganalyticsportal-int.cloudapp.net' is therefore not allowed access.

As eroman@ said, this is an expected error.

https://fetch.spec.whatwg.org/#http-access-control-allow-origin
https://fetch.spec.whatwg.org/#http-new-header-syntax

The latest Fetch spec defines the A-C-A-O header as:
> Access-Control-Allow-Origin      = origin-or-null / wildcard
> origin-or-null                   = origin / %x6E.75.6C.6C ; "null", case-sensitive
> origin                           = scheme "://" host [ ":" port ]


I think the mozilla's document is based on the old W3C's CORS spec,
https://www.w3.org/TR/cors/#access-control-allow-origin-response-header,
it allowed origin-list-or-null of https://tools.ietf.org/html/rfc6454#section-7.1

IIRC, a little old fetch spec explicitly said the Access-Control-Allow-Origin's definition was different from RFC's origin-list-or-null, but the latest spec just provides ABNF instead.

Ok thanks a lot everyone for your help!