Jump to content
thirty bees forum
  • 0

Cross-Origin Read Blocking warnings out of the blue as of yesterday evening in Chrome




Something strange happened yesterday. I updated my store to the latest edge channel and went in to do some products. When I went to see how they look in FO the website was lacking css and js files so only bunch of text.

Quickly went back and checked if this is related to some recent change I made but I failed to find something.

The error is Cross-Origin Read Blocking notice and it only appears in Chrome (both desktop, mobile, 4 separate devices). It is shown because I use media servers feature. When I remove them everything is working correctly.

Not only js and css are blocked but also webp, everything that's loaded by the media servers.


Could any of you reproduce this error? I think it's not related to recent changes as of yesterday because none of those are related to this.

If so what could you offer in order to fix this issue other than not using media servers?


Is this option viable solution in my use case? I have 2 subdomains (s1 and s2) that point to root of my site. That way when TB adds new files (images, css, js) there is no need to sync those per hosts. This worked few years back when every speed test online showed recommendations to less files per host to speed the loading times. Is this the same today? Do we need the media servers and is there any viable speed improvements in your test? Is my setup correct (2 subdomains pointing to the same host)?

And if they still give a boost in loading speeds how should we handle this issue? I believe it's a recent addition to chromium but everywhere it's said that this should not break any website, despite that mine is pretty much broken. Edge displays the page correctly but still shows these warnings.



EDIT: and here is a recent addition to chrome 105 (despite that I'm using 114 and it worked yesterday): https://chromestatus.com/feature/4933785622675456 that says everything will be blocked if there is no proper configuration in place (ORBv0.1 blocks all range request responses, unless they come from a URL that ORBv0.1 has earlier recognized (via sniffing, or via mime type) as audio or video.)

Link to comment
Share on other sites

6 answers to this question

Recommended Posts

  • 0

I guess thirty bees will have to emit some additional responses headers to mark media servers as trusted sources. I will have to read up on that. @the.rampage.rado can you create github issues, and enter any information you have found so far regarding this are?

Media servers do not really help you that much if you point it to the same server as your primary domain. The only benefit is that requests to static assets on media servers will not contain cookies, so each request will save ~2k of data each way. Another benefits is that you can apply more easily caching rules (for example in cloudflare)

If you had another server, and set up data sync between your primary server and your media server, then the benefits would be much bigger. On the other hand, you would have to solve issues with out-of-sync data

Link to comment
Share on other sites

  • 0

Thank you!

So you could reproduce this?


Regarding my use case of media servers - as you said I only use them for cookie-less delivery of static files and this setup saves from sync issues. Literally all static files are loaded by the media server that way.


Could we manipulate those headers on app level or they should be configured on server level?

I'll make a github issue later, just want to google little bit more in order to try and find possible fixes.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...