CORS headers are not working in all cases

[naveedahmed1]

It seems that the current implementation of CORS middleware applies Access-Control-Allow-Origin headers only if the request contains Origin header. Browsers set the Origin headers in request only when making CORS requests through AJAX.

Which means the client will see Access-Control-Allow-Origin headers in response only if the request is made through ajax, and not for the resources where request is directly embedded in the page.

Which works for most of the cases. But there are cases when we need to return Access-Control-Allow-Origin header in all cases.

For example, modern progressive apps, use Service Workers to pre-cache resource such as javascript bundles, stylesheets etc. These files are usually automatically cached by browsers when first accessed. If a service worker tries to precache a resource which is already in browsers cache and that resource was fetched without Origin headers when it was first downloaded. Then the request from Service Worker to cache that resource, would see a response from browser cache i.e. a response without Access-Control-Allow-Origin headers. Therefore it will throw a CORS error.

[Eilon]

@naveedahmed1 I believe that service workers use the fetch API to do their AJAX requests (instead of XMLHttpRequest), but that does support CORS. Do you have a repro that demonstrates that this doesn't work? If so, it would be great if you could share that, plus let us know which browser(s) you reproduced this in.

[xt0rted]

I setup an Azure CDN endpoint that pulled the files from my site, and most of the time the files were being cached correctly, but every so often some of the css and js files would get cached in a region incorrectly and the site would start throwing cors errors. The error messages in dev tools didn't make sense since I had setup the middleware to allow all.

I experienced this issue with the owin middleware and the .net core middleware a week or so later. I'm wondering if those issues were caused by this missing header and requests from either app services warmup/always, app insights availability tests, or even a bot hitting the site.

I was never able to force a repro of this, but it did happen 2 or 3 times and took our site down in various regions around the US without me knowing. For now I've just turned off the CDN since I can't risk taking the site down and not knowing about it or without having a way to see it myself to troubleshoot.

[Eilon]

Is there some special setup on the CDN that you can do to always send CORS headers?

[Eilon]

I see Azure CDN has some docs on CORS:

• https://docs.microsoft.com/en-us/azure/cdn/cdn-cors

(I've never used it, so unfortunately I'm not familiar with it personally.)

[xt0rted]

I'll have to give that a try for production and keep the cors middleware for dev/test environments where I run two domains on the same site to simulate the cdn.

[naveedahmed1]

@Eilon thank you for your reply.

You are right, fetch API supports CORS. but that solution works if we are writing the complete logic for precache on our own. But if we are using the libraries like sw-toolbox /workbox /sw-precache etc these doesn't support this option.

I think it would be better to give an option to the developer how they want CORS headers to be applied to the response; whether Alwaysor when there is an Origin header present in the request headers.

@xt0rted I think you are having the same issue as mine. The requests for which you aren't seeing the CORS headers probably are the requests which were first made without Origin header and were cached on CDN and hence subsequent requests for those resources doesn't have CORS header (since these are hitting your CDN and not origin server).

Some of the CDNs offer option to setup CORS headers but some doesn't, for example Cloud Flare.

That's why I am requesting this feature to be added to CORS middleware.

[blowdart]

Adding always would violate the CORS spec and that seems like a very bad thing to do for a misbehaving client/CDN.

[mkArtakMSFT]

@blowdart, is there some recommendation we can provide to @naveedahmed1?

[blowdart]

Aside from contact Azure support and request they fix the CDN to do the right thing? No.

[pranavkm]

@naveedahmed1 I tried setting up a sample to see what the behavior is -

• https://github.com/pranavkm/repro/blob/Home/2780/Origin/wwwroot/Index.htm
• https://github.com/pranavkm/repro/blob/Home/2780/Origin/wwwroot/sw.js

I couldn't reproduce a scenario where the browser cache interfered with the service worker pre-fetch. On Chrome and Edge, the SW does a separate fetch with the CORS headers which the server responds to. More specifically, the documentation for SW recommends using cache busting if HTTP cache is involved. From https://googlechrome.github.io/samples/service-worker/basic/index.html

Cache-bust the precaching requests. The cache.addAll() call may be fulfilled with responses from the HTTP cache, depending on the HTTP caching headers you use. If you are using HTTP caching and unversioned resources, it can be safer to cache-bust your precaching requests.

Have you tried that in your app?

[mkArtakMSFT]

Hi. We're closing this issue as there's been no response and we have been unable to reproduce it. If you have more details and are encountering this issue please add a new reply and re-open the issue.