Hello, from today I found that when accessing cdnjs
, the server will respond 404 or the response header will lack access-control-allow-origin: *
header.
For example, my web app just made a request to https://cdnjs.cloudflare.com/ajax/libs/spin.js/2.3.2/spin.min.js
, then get the response header under:
cache-control public, max-age=14400
cf-cache-status HIT
cf-ray 48d1a6325e2245ae-TPE
content-encoding br
content-type text/html
date Sat, 22 Dec 2018 09:44:19 GMT
expect-ct max-age=604800, report-uri="ht….com/cdn-cgi/beacon/expect-ct"
expires Sat, 22 Dec 2018 13:44:19 GMT
served-in-seconds 0.000
server cloudflare
strict-transport-security max-age=15780000; includeSubDomains
vary Accept-Encoding
X-Firefox-Spdy h2
Since it lacks access-control-allow-origin: *
header, the script is not loaded and my web app is broken.
Problematic files are quite random, when I access the same file in a different time it's sometimes good and sometimes bad. Also, it seems like depending on client's network, the frequency also differs.
On my mobile network this issue never happens, but in my company, it happens frequently, and in a VM it's 100%. (Always some URLs are broken)
Is there some maintenance or server issue affecting particular routes or? Thank you very much!
I have the same issue. My web application is broken.
I got the same issue during development for sometime, it seems random
Access to script at 'https://cdnjs.cloudflare.com/ajax/libs/photoswipe/4.1.2/photoswipe.min.js' from origin 'http://localhost' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I've also started to see the same thing and am getting no ACAO header on assets served by cndjs.
It seems to only be affecting my local dev environment but everything is busted right now.
I'm also having this issue, and it's triggering random JS errors coming back via Sentry. Furthermore, I personally just encountered it in the browser myself on my personal site.
Confirmed. There's no consistency in the files there are blocked, e.g. sometimes codemirror other times jQuery.
Edit
2 minutes ago everything worked as expected, but problem has returned.
Access to CSS stylesheet at 'https://cdnjs.cloudflare.com/ajax/libs/codemirror/5.39.2/theme/monokai.min.css' from origin 'https://mydomain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
# Other times
Access to script at 'https://cdnjs.cloudflare.com/ajax/libs/codemirror/5.37.0/codemirror.min.js' from origin 'https://mydomain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I can confirm that we experience the same issue!
_[Error] Origin xxx is not allowed by Access-Control-Allow-Origin.
[Error] Failed to load resource: Origin xxx is not allowed by Access-Control-Allow-Origin. (leaflet.css, line 0)_
cc @PeterDaveHello
@MattIPv4 I can do nothing about this, maybe ping @ryankirkman
I'm experiencing the issue intermittently with several libraries that my project is dependent on:
https://cdnjs.cloudflare.com/ajax/libs/moment-timezone/0.5.21/moment-timezone-with-data.min.js
Access to script at 'https://cdnjs.cloudflare.com/ajax/libs/moment-timezone/0.5.21/moment-timezone-with-data.min.js' from origin 'http://docker.local' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
https://cdnjs.cloudflare.com/ajax/libs/mouse0270-bootstrap-notify/3.1.7/bootstrap-notify.min.js
Access to script at 'https://cdnjs.cloudflare.com/ajax/libs/mouse0270-bootstrap-notify/3.1.7/bootstrap-notify.min.js' from origin 'http://docker.local' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
https://cdnjs.cloudflare.com/ajax/libs/proj4js/2.4.4/proj4.js
Access to script at 'https://cdnjs.cloudflare.com/ajax/libs/proj4js/2.4.4/proj4.js' from origin 'http://docker.local' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Because the errors with these scripts tend to halt script execution on the pages, these errors have rendered large sections of my web app nonfunctional for several thousand installed instances of my FOSS application. The only way I could resolve the issue would be to distribute an update that refers to a different location, and this depends heavily on everyone affected updating in a timely fashion.
I know this service is a free one and I am immensely grateful to those who provide it, but the timing and duration of this issue has been really unfortunate and has done a lot of damage. :(
This issue is affecting our production, internal application (fortunately, our team is on vacation).
This appears to affect my requests 100% of the time (ie. it's very reproducible in our set up). I'd be happy to coordinate directly with anyone so they could do an end-to-end test. [email protected]
The solution for me was to fallback to local JS if the CDN fails. Just
check for the script having loaded and write a script to the document.
iPhoneから送信
UPDATE: I have a public URL for which this problem seems to occur 100% of the time. Who could I send this info to? (although it's public, I'd rather not post this URL on a Github issue). But I'm happy to share!
The issue is happening to me specifically on webfont loader. Adding it here in hopes to be able to track down the sporadic nature of the issue.
https://cdnjs.cloudflare.com/ajax/libs/webfont/1.6.28/webfontloader.js
Any chance CDNJS can fix this immediately? The OP started this thread yesterday, and it's blocking everyone's sites, thus losing our trust in CDNJS. Just sayin'.
@rickmacgillis I wish I could say something useful to you here but currently we're all just waiting on @ryankirkman to reply to try and resolve this.
I have also contacted CF direct just in case it is an issue with them but no reply from them yet as it is a Sunday.
I am seeing this to on my dev box and I would not be surprised if sites in production are broken as well
This seems fixed now as I have got the header every time now, fingers crossed it is permanently, everyone give it a try now and see if it works for you
Still occurs on my VM machine.
Might have to wait a bit as it probably is taking a bit to get propagated everywhere but for me in the UK its fixed
Still busted in the US.
FWIW, using curl to fetch the failing URLs results in a 404 if the Origin header is set. Works fine without the origin header.
curl -s -I -X GET 'https://cdnjs.cloudflare.com/ajax/libs/webfont/1.6.28/webfontloader.js' -H 'Origin: http://localhost:11000'
HTTP/2 404
date: Mon, 24 Dec 2018 02:44:11 GMT
content-type: text/html
served-in-seconds: 0.000
cf-cache-status: HIT
expires: Mon, 24 Dec 2018 06:44:11 GMT
cache-control: public, max-age=14400
strict-transport-security: max-age=15780000; includeSubDomains
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 48dfb98569b3c38d-SIN
EDIT (2018-12-27): It could be that adding/removing/changing the Origin header is simply taking me to a different Cloudflare server that doesn't have the issue. I've seen 404s for files without the Origin header too, so it may not be related. Seems to be a cdnjs-Cloudflare config issue for a certain category.
Hi all,
Just a bump on this post to report that it still occurs occasionally...
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cdnjs.cloudflare.com/ajax/libs/showdown/1.9.0/showdown.min.js. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.1.3/css/bootstrap.min.css. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cdnjs.cloudflare.com/ajax/libs/datatables/1.10.19/js/jquery.dataTables.min.js. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cdnjs.cloudflare.com/ajax/libs/x-editable/1.5.1/bootstrap3-editable/js/bootstrap-editable.min.js. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.1.3/js/bootstrap.bundle.min.js. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]
It's occurring across a couple of production deployments, which is somewhat frustrating. As others have noted, I'm keenly aware that this is a service that costs end-users no money, which is why this is a "heads up" and definitely not a complaint or anything :)
@terinjokes would you please help take a look? Thanks.
The issue seems to be limited to chrome browsers if that helps anyone
I was having it in Firefox yesterday then not to long after I posted it then fixed it self
Get Outlook for Androidhttps://aka.ms/ghei36
From: Smaxor5 notifications@github.com
Sent: Monday, December 24, 2018 5:38:22 PM
To: cdnjs/cdnjs
Cc: J.Townsend; Comment
Subject: Re: [cdnjs/cdnjs] CORS mega-issue: Responses lack access-control-allow-origin occasionally (#13165)
The issue seems to be limited to chrome browsers if that helps anyone
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/cdnjs/cdnjs/issues/13165#issuecomment-449758186, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADddQqwe9OuYHSqGAtWLHgIPG4-Y5m5cks5u8REOgaJpZM4ZfaRw.
I'm pretty sure this isn't limited to specific browsers, I still experience this issue with Firefox.
I'm facing this issue with Edge 44, Chrome 72 and Firefox 65. I can confirm, that it's not a browser-specific problem.
I have a reply from the lead for support operations engineering at Cloudflare at last:
I can see that Cloudflare staff are already involved in that thread - I've pinged the relevant engineers internally to look at them.
It may take some time for their attention to get to it, as they live in our Engineering organisation and most the company is on holiday season.
I would assume they are referring to @terinjokes for the engineer already here?
Interpret this response from CF as you wish...
Same issue loading font-awesome in Chrome 70 and FF 65
Just chiming in that I can repro 100% of the time _if_ an Origin header is set.
Is everyone here using SRI on their assets that are failing? I was/am.
Is everyone here using SRI on their assets that are failing? I was/am.
Did you remove SRI and can you confirm it works without it? I'm using SRI too, but I don't see how it should be a problem.
I was just responding to the previous comment about an Origin header and that if using SRI could be related somehow due to all requests having to be CORS enabled.
It's a shot in the dark but it might help, I'm not in a position to test right now, sorry!
Hello all future responders:
If you are reporting an experience of the issue this thread is for, please comment with the following to help us out in diagnosing the issue:
Resource URL: cdnjs.cloudflare.com/whatever
Were you using SRI?: yes/no
What were the full request headers?:
full REQUEST headers
What were the full response headers?:
full RESPONSE headers
Thank you :D
I did some testing:
I made a small site I host on Netllify with Cloudflare as a CDN (and DNS).
First I had the following script tag:
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>
As you can see with SRI to cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js
It gave me a CORS error.
request headers:
:authority: test.nalsai.de
:method: GET
:path: /
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
cookie: __cfduid=de6884bbb5d8a12dde2ead75cf663ccad1543347985
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 OPR/57.0.3098.106
response headers:
age: 0
cache-control: public, max-age=0, must-revalidate
cf-ray: 48f68b09bd8ac2e2-FRA
content-encoding: br
content-type: text/html; charset=UTF-8
date: Wed, 26 Dec 2018 21:12:00 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
status: 200
vary: Accept-Encoding
x-nf-request-id: da94121d-a35c-4022-946f-27a1c1b46b61-12496744
x-nf-srv-version: 45aaffea081549dd03a2dfff644cc25cf522edbd
The request to cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js had the following headers:
Origin: https://test.nalsai.de
Referer: https://test.nalsai.de/
The I tried it again without SRI
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
The headers were the same (except for date and age obviously).
Everything worked.
It's too late for me to test right now, but some other things I have noticed are:
I am see this issue intermittently on multiple websites that I maintain. As OP said, sometimes the response is missing header access-control-allow-origin: *. This prevents the page from successfully loading.
I have been seeing this issue for a week. Really surprised this hasn't gotten any traction yet. Should be acknowledged as a p1 issue on cloudflare status page.
My dev box is broken again, so it does seem that it is happening intermittently
As I was typing this I just refreshed the browser and it fixed itself
As people have been saying this started about a week ago, what changed infrastructure wise that could of caused this issue? Might be worth force purging the cache and see if that helps on your side?
As a result of this issue and widespread reports of total outage of my web application stemming from core dependencies failing to load, I had to spend Christmas Eve and Christmas Day working to completely retool my static asset dependency management and distribute an updated version of my software that re-localized the necessary assets and removed CDNJS from the chain.
While I understand and appreciate that the holidays means it will necessarily be harder to reach the necessary folks who run things on CloudFlare's side, the fact that such a disruption can persist for this long without even being registered by CloudFlare as a reported issue of any sort on their status page gives rise to significant doubts about the long-term reliability and viability of the service for any production use-case.
Today we started to experience this CORS error across all of the sites that we maintain for our clients and were also utilising SRI.
The quick fix to get them back online was to insert an additional line into the headers of the main files : header("Access-Control-Allow-Origin: *");
I've not been able to test yet if removing that and removing the SRI elements will also work, but aim to test later, as restoring functionality quickly was the main aim. Extremely concerning though the scale of this issue.
We're starting to get customers opening tickets because parts of our site are not working. Is there any update on this?
@ScottHelme Disappointingly not, Cloudflare have assigned @terinjokes to this but I have heard nothing more yet. Still nothing from @ryankirkman either :(
We are affected by this and we are moving to https://www.jsdelivr.com as a workaround. It really does raise doubts about reliability considering that it's been a few days with no solution.
Simon from Cloudflare here - we've found an issue with one of the origins behind a load balancer serving cdnjs. This origin has now been removed and the 404s should no longer be occurring.
Can you let me know if you're still seeing errors? Full HTTP request & response headers (or a HAR from the browser) would be useful.
@simon-says Hi Simon, awesome. Should this fix also fix this issue (CORS)?
@MattIPv4 the 404s are the cause of the CORS issue I suspect... you won't see access-control-allow-origin: *
on HTTP 404 responses from the origin for CDNJS. So the 404s are the cause of the CORS issues :) . Both should be fixed now.
@simon-says Absolutely awesome then, I'll leave these issues open for a while longer so if any new reports come in they can make their way here. Thank you for the help and I do hope that this is resolved.
@simon-says For the future, if something like this happens again, is there a better way to alert Cloudflare to the issues, or was the delay on email just due to the holiday period?
@MattIPv4 drop me a line at simon at cloudflare and I'll follow up this for you. I'd definitely expect us to be able to react much sooner to your reports so if anything went wrong internally here I'll get that fixed.
@simon-says thanks for fixing the issue!
It would then seem browsers are respecting access control headers off requests that 404'd...which is interesting. I guess that's an OPTIONS request that happens behind the scenes since it doesn't show in devtools.
We are affected by this and we are moving to https://www.jsdelivr.com as a workaround. It really does raise doubts about reliability considering that it's been a few days with no solution.
Yes, we did move to jsdelivr.com too because of this issue because many of our customers were working over Christmas and we had to make sure our application was available. For the future we will either server all assets directly or add those resources from multiple CDNs so we can easily switch if there is an issue with one of them.
Seems to be fixed :+1:
Yeah looks to be fixed
Yes this is fixed for me also now. Thanks for the work on this over the festive period.
However, the Cloudflare status page still makes no mention of the issue during the time this was broken saying no incidents reported, raising the question as to the point of a status page, if it does not accurately report the status of the services.
@simon-says is cdnjs regarded as part of the Cloudflare system?
I do agree with @robinwilson16 that maybe we should be on the status page for incidents such as this?
I'm going to close this issue now, if anyone has any further issues relating to this, please do reply and mention me so that I can get straight on it again. I hope however, that these issues are now fixed.
This seems like it just started happening again for us. This is on a localhost instance in development.
12:40:34.174 jobs:1 Access to font at 'https://cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.2.12/themes/default/assets/fonts/icons.woff2' from origin 'http://localhost' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
12:40:34.174 jobs:1 GET https://cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.2.12/themes/default/assets/fonts/icons.woff2 net::ERR_FAILED
12:40:34.223 jobs:1 Access to font at 'https://cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.2.12/themes/default/assets/fonts/icons.woff' from origin 'http://localhost' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
12:40:34.223 jobs:1 GET https://cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.2.12/themes/default/assets/fonts/icons.woff net::ERR_FAILED
12:40:34.522 jobs:1 Access to font at 'https://cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.2.12/themes/default/assets/fonts/icons.ttf' from origin 'http://localhost' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
12:40:34.522 jobs:1 GET https://cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.2.12/themes/default/assets/fonts/icons.ttf net::ERR_FAILED
And now it's fixed. Nevermind.
And it's back.
Access to script at 'https://cdnjs.cloudflare.com/ajax/libs/codemirror/5.40.2/mode/meta.min.js' from origin 'https://****' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Please ensure a persistent fix!
@Luzifer Please post full request/response headers so that the Cloudflare team can diagnose the issue.
curl 'https://cdnjs.cloudflare.com/ajax/libs/react/16.6.1/umd/react.production.min.js' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36' -H 'Referer: https://www.hellofresh.co.nz/checkout-form/user?locale=en-NZ' -H 'Origin: https://www.hellofresh.co.nz' --compressed
Here's a CORS that failed.
@tiagojsalmeida Please post full request/response headers so that Cloudflare can diagnose the issue.
@MattIPv4 here's the HAR from that request:
https://pastebin.com/CS8FiGSx
(https://cdnjs.cloudflare.com/ajax/libs/react/16.6.1/umd/react.production.min.js) was the one failing
@tiagojsalmeida @Luzifer Thank you, I have notified Cloudflare and asked them to take a look at this once again :)
@MattIPv4 - Should this issue be marked as open?
We are also experiencing this again.
@nathankurtyka I was waiting for a few more reports before I decided to reinstate the issue, that appears to have happened now so yeah, open it is.
_3 users reporting here + 1 on twitter._
@gurukara7 Full request/response headers and the resource URL please so that the CF team can diagnose :)
HAR showing the issue:
https://gist.github.com/Sidewinder53/a60990cb8455ecbea91a89d125e8fdb8#file-mirrorsedgearchive-de-har-L1932
https://cdnjs.cloudflare.com/ajax/libs/js-cookie/2.2.0/js.cookie.min.js
is missing the Access-Control-Allow-Origin
header.
cc @simon-says / @terinjokes once again :(
This the exact issue. Occurs for various different URLs randomly
Request URL: https://cdnjs.cloudflare.com/ajax/libs/selectize.js/0.8.5/css/selectize.default.css
Error Message:
Access to CSS stylesheet at 'https://cdnjs.cloudflare.com/ajax/libs/select2/3.4.5/select2.css' from origin 'http://localhost' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Request URL: https://cdnjs.cloudflare.com/ajax/libs/angular-material/1.1.6/angular-material.min.css
Error Message:
Access to CSS stylesheet at 'https://cdnjs.cloudflare.com/ajax/libs/angular-material/1.1.6/angular-material.min.css' from origin 'http://localhost' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
https://cdnjs.cloudflare.com/ajax/libs/ol3/4.6.3/ol-debug.js:
_Response Headers_
cache-control: public, max-age=14400
cf-cache-status: EXPIRED
cf-ray: 4a2533f7bc034ab4-GRU
content-encoding: br
content-type: text/html
date: Fri, 01 Feb 2019 14:45:39 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Fri, 01 Feb 2019 18:45:39 GMT
served-in-seconds: 0.000
server: cloudflare
status: 404
strict-transport-security: max-age=15780000; includeSubDomains
vary: Accept-Encoding
_Request Headers_
:authority: cdnjs.cloudflare.com
:method: GET
:path: /ajax/libs/ol3/4.6.3/ol-debug.js
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
accept-encoding: gzip, deflate, br
accept-language: pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7
cache-control: no-cache
pragma: no-cache
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Seems it is back already :arrow_up:
Issue is back, can this be fixed asap? We use this cdn in production!
@olafcm Cloudflare have been notified about this, I will post any updates here.
Here's a failed request captured from Firefox for twitter-bootstrap:
{
"log": {
"version": "1.2",
"creator": {
"name": "WebInspector",
"version": "537.36"
},
"pages": [
{
"startedDateTime": "2019-02-01T16:26:17.207Z",
"id": "page_1",
"title": "https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.7/css/bootstrap.css.map",
"pageTimings": {
"onContentLoad": 353.3110000007582,
"onLoad": 587.601000000177
}
}
],
"entries": [
{
"startedDateTime": "2019-02-01T16:26:17.207Z",
"time": 103.66900000008172,
"request": {
"method": "GET",
"url": "https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.7/css/bootstrap.css.map",
"httpVersion": "http/2.0",
"headers": [
{
"name": ":method",
"value": "GET"
},
{
"name": ":authority",
"value": "cdnjs.cloudflare.com"
},
{
"name": ":scheme",
"value": "https"
},
{
"name": ":path",
"value": "/ajax/libs/twitter-bootstrap/3.3.7/css/bootstrap.css.map"
},
{
"name": "pragma",
"value": "no-cache"
},
{
"name": "cache-control",
"value": "no-cache"
},
{
"name": "upgrade-insecure-requests",
"value": "1"
},
{
"name": "user-agent",
"value": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36"
},
{
"name": "accept",
"value": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8"
},
{
"name": "accept-encoding",
"value": "gzip, deflate, br"
},
{
"name": "accept-language",
"value": "fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7"
}
],
"queryString": [],
"cookies": [],
"headersSize": -1,
"bodySize": 0
},
"response": {
"status": 404,
"statusText": "",
"httpVersion": "http/2.0",
"headers": [
{
"name": "status",
"value": "404"
},
{
"name": "date",
"value": "Fri, 01 Feb 2019 16:26:17 GMT"
},
{
"name": "content-type",
"value": "text/html"
},
{
"name": "served-in-seconds",
"value": "0.001"
},
{
"name": "strict-transport-security",
"value": "max-age=15780000; includeSubDomains"
},
{
"name": "expect-ct",
"value": "max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\""
},
{
"name": "server",
"value": "cloudflare"
},
{
"name": "cf-ray",
"value": "4a25c761ad2e91ee-EWR"
},
{
"name": "content-encoding",
"value": "br"
}
],
"cookies": [],
"content": {
"size": 564,
"mimeType": "text/html"
},
"redirectURL": "",
"headersSize": -1,
"bodySize": -1,
"_transferSize": 223
},
"cache": {},
"timings": {
"blocked": 5.593999999597203,
"dns": -1,
"ssl": -1,
"connect": -1,
"send": 0.12899999999999956,
"wait": 94.16699999990745,
"receive": 3.7790000005770708,
"_blocked_queueing": 0.879999999597203
},
"serverIPAddress": "104.19.198.151",
"_initiator": {
"type": "other"
},
"_priority": "VeryHigh",
"connection": "39087",
"pageref": "page_1"
}
]
}
}
Failures are brittle on request Origin
, presumably because the server does not include Vary: Origin
on response.
Example:
% curl -I -H'Origin: http://localhost:80' https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.7.5/angular-aria.min.js
HTTP/2 200
access-control-allow-origin: *
(no Vary)
…
% curl -I -H'Origin: http://localhost:9999' https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.7.5/angular-aria.min.js
HTTP/2 404
(no Vary)
(no Access-Control-Allow-Origin)
…
This was a re-occurrence of the issue from December - it is fixed now and I'm in touch with @MattIPv4 to get a better process for escalation as well as fixing the underlying cause.
@simon-says Can you share the root cause?
If it helps, I encountered this problem against another URL:
➜ ~ curl -I https://cdnjs.cloudflare.com/ajax/libs/monaco-editor/0.10.1/min/vs/loader.js
HTTP/2 404
date: Fri, 01 Feb 2019 19:55:14 GMT
content-type: text/html
served-in-seconds: 0.000
cf-cache-status: HIT
expires: Fri, 01 Feb 2019 23:55:14 GMT
cache-control: public, max-age=14400
strict-transport-security: max-age=15780000; includeSubDomains
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 4a26f975add56b37-WAW
I am having this issue as well on nearly all the scrips I am using locally. Here is one.
curl -I https://cdnjs.cloudflare.com/ajax/libs/react-grid-layout/0.16.6/react-g
rid-layout.min.js
HTTP/1.1 404 Not Found
Date: Fri, 01 Feb 2019 20:00:45 GMT
Content-Type: text/html
Connection: keep-alive
Served-In-Seconds: 0.001
CF-Cache-Status: HIT
Expires: Sat, 02 Feb 2019 00:00:45 GMT
Cache-Control: public, max-age=14400
Strict-Transport-Security: max-age=15780000; includeSubDomains
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
CF-RAY: 4a27018dfeb8c53e-ORD
I'm having issues on https://mtr.sh/ with Chrome (Version 71.0.3578.98 (Official Build) (64-bit) on Windows):
Access to CSS stylesheet at 'https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.7/css/bootstrap-theme.min.css' from origin 'https://mtr.sh' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
GET https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.7/css/bootstrap-theme.min.css net::ERR_FAILED
md5-0a1e32fe361d22da35cabd36480bdcec
Access to script at 'https://cdnjs.cloudflare.com/ajax/libs/socket.io/1.7.3/socket.io.min.js' from origin 'https://mtr.sh' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
md5-0a1e32fe361d22da35cabd36480bdcec
GET https://cdnjs.cloudflare.com/ajax/libs/socket.io/1.7.3/socket.io.min.js net::ERR_FAILED
@Fusl Full request/response headers would be great if you could add them :)
The issue has been fixed for me.
I have asked Simon (Cloudflare) to double check this due to the continued reports of intermittent issues. Hopefully it is just the earlier issue being cached but will keep this thread updated :)
It's also working for me again so I can't provide with request/response headers or HAR.
It's definitely still a problem -- I'm able to reproduce it on mtr.sh. I've attached a HAR generated a few minutes ago.
@MattIPv4 I'm happy to coordinate directly with @simon-says anyone at CF
This is still happening for me with lightGallery.js (just the font files somehow, not CSS or JS files):
Access to font at 'https://cdnjs.cloudflare.com/ajax/libs/lightgallery/1.6.11/fonts/lg.woff?n1z373' from origin 'https://libraries.cca.edu' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
jquery-3.2.1.min.js:4 GET https://cdnjs.cloudflare.com/ajax/libs/lightgallery/1.6.11/fonts/lg.woff?n1z373 net::ERR_FAILED
Access to font at 'https://cdnjs.cloudflare.com/ajax/libs/lightgallery/1.6.11/fonts/lg.ttf?n1z373' from origin 'https://libraries.cca.edu' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
cdnjs.cloudflare.com/ajax/libs/lightgallery/1.6.11/fonts/lg.ttf?n1z373:1 GET https://cdnjs.cloudflare.com/ajax/libs/lightgallery/1.6.11/fonts/lg.ttf?n1z373 net::ERR_FAILED
headers:
> curl -i 'https://cdnjs.cloudflare.com/ajax/libs/lightgallery/1.6.11/fonts/lg.woff?n1z373' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36' -H 'Referer: https://cdnjs.cloudflare.com/ajax/libs/lightgallery/1.6.11/css/lightgallery.min.css' -H 'Origin: https://libraries.cca.edu' --compressed
HTTP/2 404
date: Fri, 01 Feb 2019 21:20:59 GMT
content-type: text/html
content-encoding: gzip
served-in-seconds: 0.001
cf-cache-status: HIT
expires: Sat, 02 Feb 2019 01:20:59 GMT
cache-control: public, max-age=14400
strict-transport-security: max-age=15780000; includeSubDomains
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
vary: Accept-Encoding
server: cloudflare
cf-ray: 4a277711de65282e-SJC
It 404s with that curl but loading the URL in the browser downloads the file.
It's happening also with the unpkg cdn, so for sure it's a CloudFlare issue...
@nathankurtyka / @phette23 Thank you for the continued reports, I have passed them onto @simon-says for further investigation. Once again, apologies for this drop in service :/
@MattIPv4 can you also loop me in? Thanks.
@PeterDaveHello how best should I do that, I plan to keep all updates posted here. Do you want me to forward the email chain to you?
@MattIPv4 it'll be great to loop me in that mails, thanks!
@PeterDaveHello I don’t actually have an email address for you, what would be best?
You can email [email protected] if you’d rather it wasn’t public.
Hey all, good news from Cloudflare!
The issue had resurfaced due to an automatic process on their end reinstating a broken node into the load balancer.
This has now been stopped and so service should be fully restored to cdnjs! Apologies from all of us here at cdnjs for the delay in getting this resolved and for the drop in service.
Have a great weekend making use of cdnjs in all your projects!
Hi, here's two typical problems of my case:
SRI matched but not the resource I need.
Copied from https://cdnjs.com/libraries/stats.js/r17
<script src="https://cdnjs.cloudflare.com/ajax/libs/stats.js/r17/Stats.min.js" integrity="sha256-q9TcRq5RF4QMB+4qpg3wa9mXrOpqAG2RYWxfgA8+Ehc=" crossorigin="anonymous"></script>
Validate SRI:
$ curl 'https://cdnjs.cloudflare.com/ajax/libs/stats.js/r17/Stats.min.js' | openssl dgst -sha256 -binary | openssl base64 -A
q9TcRq5RF4QMB+4qpg3wa9mXrOpqAG2RYWxfgA8+Ehc=
Actual request and response
$ curl -v 'https://cdnjs.cloudflare.com/ajax/libs/stats.js/r17/Stats.min.js'
* Trying 2606:4700::6813:c697...
* TCP_NODELAY set
* Connected to cdnjs.cloudflare.com (2606:4700::6813:c697) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; CN=ssl412106.cloudflaressl.com
* start date: Sep 22 00:00:00 2018 GMT
* expire date: Mar 31 23:59:59 2019 GMT
* subjectAltName: host "cdnjs.cloudflare.com" matched cert's "*.cloudflare.com"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA 2
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x563875f5ee40)
> GET /ajax/libs/stats.js/r17/Stats.min.js HTTP/1.1
> Host: cdnjs.cloudflare.com
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Sat, 02 Feb 2019 04:13:05 GMT
< content-type: application/javascript
< content-length: 36
< last-modified: Thu, 17 May 2018 09:25:40 GMT
< etag: "5afd4a94-24"
< expires: Thu, 23 Jan 2020 04:13:05 GMT
< cache-control: public, max-age=30672000
< access-control-allow-origin: *
< served-in-seconds: 0.001
< cf-cache-status: MISS
< accept-ranges: bytes
< strict-transport-security: max-age=15780000; includeSubDomains
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 4a29d2bbbab091c4-EWR
<
* Curl_http_done: called premature == 0
* Connection #0 to host cdnjs.cloudflare.com left intact
// Error: Unexpected token: punc ({)
The response is an error which can match SRI.
SRI mismatch
Copied from https://cdnjs.com/libraries/stats.js/r16
<script src="https://cdnjs.cloudflare.com/ajax/libs/stats.js/r16/Stats.min.js" integrity="sha256-eQxIuR9Z5Afu5SFVtoND4dHdHygFRhueTk7mwkINjro=" crossorigin="anonymous"></script>
Validate SRI:
$ curl 'https://cdnjs.cloudflare.com/ajax/libs/stats.js/r16/Stats.min.js' | openssl dgst -sha256 -binary | openssl base64 -A
jjcMJmdStYZdcYCmY6gC1qkG7+Ff+mr9KaC/dq7qjp8=
Actual request and response
$ curl -v 'https://cdnjs.cloudflare.com/ajax/libs/stats.js/r16/Stats.min.js'
* Trying 2606:4700::6813:c397...
* TCP_NODELAY set
* Connected to cdnjs.cloudflare.com (2606:4700::6813:c397) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; CN=ssl412106.cloudflaressl.com
* start date: Sep 22 00:00:00 2018 GMT
* expire date: Mar 31 23:59:59 2019 GMT
* subjectAltName: host "cdnjs.cloudflare.com" matched cert's "*.cloudflare.com"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA 2
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x562bb47bde40)
> GET /ajax/libs/stats.js/r16/Stats.min.js HTTP/1.1
> Host: cdnjs.cloudflare.com
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Sat, 02 Feb 2019 04:16:45 GMT
< content-type: application/javascript
< last-modified: Thu, 17 May 2018 09:25:40 GMT
< etag: W/"5afd4a94-6d7"
< expires: Thu, 23 Jan 2020 04:16:45 GMT
< cache-control: public, max-age=30672000
< access-control-allow-origin: *
< served-in-seconds: 0.000
< cf-cache-status: HIT
< strict-transport-security: max-age=15780000; includeSubDomains
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 4a29d81c4fb3c5f6-EWR
<
var Stats=function(){function e(e){return n.appendChild(e.dom),e}function t(e){for(var t=0;t<n.children.length;t++)n.children[t].style.display=t===e?"block":"none";l=e}var l=0,n=document.createElement("div");n.style.cssText="cursor:pointer;opacity:0.9",n.addEventListener("click",function(e){e.preventDefault(),t(++l%n.children.length)},!1);var a=(performance||Date).now(),i=a,o=0,r=e(new Stats.Panel("FPS","#0ff","#002")),f=e(new Stats.Panel("MS","#0f0","#020"));if(self.performance&&self.performance.memory)var c=e(new Stats.Panel("MB","#f08","#201"));return t(0),{REVISION:16,domElement:n,addPanel:e,showPanel:t,setMode:t,begin:function(){a=(performance||Date).now()},end:function(){o++;var e=(performance||Date).now();if(f.update(e-a,200),e>i+1e3&&(r.update(1e3*o/(e-i),100),i=e,o=0,c)){var t=performance.memory;c.update(t.usedJSHeapSize/1048576,t.jsHeapSizeLimit/1048576)}return e},update:function(){a=this.end()}}};Stats.Panel=function(e,t,l){var n=1/0,a=0,i=Math.round,o=i(window.devicePixelRatio||1),r=80*o,f=48*o,c=* Curl_http_done: called premature == 0
* Connection #0 to host cdnjs.cloudflare.com left intact
3*o,d=2*o,s=3*o,p=15*o,u=74*o,m=30*o,h=document.createElement("canvas");h.width=r,h.height=f,h.style.cssText="width:80px;height:48px";var S=h.getContext("2d");return S.font="bold "+9*o+"px Helvetica,Arial,sans-serif",S.textBaseline="top",S.fillStyle=l,S.fillRect(0,0,r,f),S.fillStyle=t,S.fillText(e,c,d),S.fillRect(s,p,u,m),S.fillStyle=l,S.globalAlpha=.9,S.fillRect(s,p,u,m),{dom:h,update:function(f,v){n=Math.min(n,f),a=Math.max(a,f),S.fillStyle=l,S.globalAlpha=1,S.fillRect(0,0,r,p),S.fillStyle=t,S.fillText(i(f)+" "+e+" ("+i(n)+"-"+i(a)+")",c,d),S.drawImage(h,s+o,p,u-o,m,s,p,u-o,m),S.fillRect(s+u-o,p,o,m),S.fillStyle=l,S.globalAlpha=.9,S.fillRect(s+u-o,p,o,i((1-f/v)*m))}}},"object"==typeof module&&(module.exports=Stats);
@MattIPv4 not sure if you cloned the new-website repo yet(as you sent some PRs), my email is in the commit log author info :)
It appears this issue has been fully resolved so I will close this issue for now. 🎉
@simonmysun Examples of your issue would be greatly appreciated. I have never seen an SRI mismatch occur here, nor do I understand what you mean by the wrong file?
@MattIPv4 My post includes two examples. In order not to engage too much space I wrapped them with detail summary tags. You might have to click the black triangles to view them.
I also found out from the image that I didn't copied the complete result (I have corrected it in the post) but it is not important.
In the first example the server responded an error. and the error message matches its SRI. In the second example the correct resource is returned, but cannot match the SRI. Both examples can be reproduced on my laptop in China and my VPS in Digital Ocean in New York.
It's weird.
@simonmysun Sorry for missing those, my theme didn't display the arrows.
Having tried both the files you referenced with the SRI values provided from the CDNJS website, both validate fine when loaded in a browser..?
Then it's more weird.
Mine here cannot load both resources correctly.
As you can see. The computed hash sum of stats.min.js at r16 by my browser(Chromium | 71.0.3578.98 (Official Build) Arch Linux (64-bit)) is as before. It doesn't match.
About the other one, you can see that the response is only an error message. I see that the response sizes in your screenshot are totally differently from mine(r16: 1.1KB, r17: 117B, there is no "Content-Length" in r16 response, btw).
Whatever they are, neither of them should be 97B.
@simonmysun have you tried loading them without SRI and with cache disabled to check their contents?
@MattIPv4 Yes of course. Without SRI they can be loaded. But the stats.min.js at version r17 is still this only line of code:
// Error: Unexpected token: punc ({)
@simonmysun It would appear that is the contents of the file we have for stats.min.js r17: https://github.com/cdnjs/cdnjs/blob/master/ajax/libs/stats.js/r17/Stats.min.js
@PeterDaveHello Is this an issue with the automatic minification done by the bot?
@MattIPv4 Right. Thanks. I think we have one more stop to the fixing of the problem.
What about the SRI mismatch of r16?
The request status would be 200 but blocked by the browser. Is it also blocked in yours?
@simonmysun Yeah I'll wait for peter to respond about the bad file. It appears that yes, the SRI also fails on r16 so I wonder if this library in general is unhappy for some reason.
It might be best to move back to your original separate issue as it appears this is indeed unrelated to this CORS/404 issue.
Thanks. No hurry please. It seems that nobody found out this in previous two years. I would always be happy to help improving.
Having an issue with the resource:
https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.9/umd/popper.min.js
In Chrome gives a "No 'Access-Control-Allow-Origin' header" error.
In browser get a "Error 1023 - Could not find host"
@amuqeet Cloudflare have a global outage affecting us. See https://status.cdnjs.com/incidents/g35ph9jwm0s7 & https://www.cloudflarestatus.com/incidents/tx4pgxs6zxdr
Not certain but I think I have a situation where I'm getting this with Brave but not with other browsers.
@malcolmocean Could you provide network request logs so we could look into this?
@MattIPv4 not sure exactly what you're looking for, but I tried hitting export-as-fetch and got this:
fetch("data:text/plain,", {"credentials":"omit","referrerPolicy":"no-referrer-when-downgrade","body":null,"method":"GET","mode":"cors"});
What I get in the console is:
Access to script at 'data:text/plain,' (redirected from 'https://cdnjs.cloudflare.com/ajax/libs/rollbar.js/2.13.0/rollbar.min.js') from origin 'null' has been blocked by CORS policy: The response is invalid.
@malcolmocean Access to script at 'data:text/plain,'
this seems to be unrelated to requesting a cdnjs resource at all?
Most helpful comment
Simon from Cloudflare here - we've found an issue with one of the origins behind a load balancer serving cdnjs. This origin has now been removed and the 404s should no longer be occurring.
Can you let me know if you're still seeing errors? Full HTTP request & response headers (or a HAR from the browser) would be useful.