After upgrading to [email protected]
, the initial load of our page throws when requesting CSS from our CDN.
assetPrefix
in next.config.js
. Deploy your app and run in production mode. Preloading css should work cross domain or it should fail gracefully.
Developer Tools:
Elements View:
I believe it's related to this PR:
https://github.com/vercel/next.js/pull/16581#issuecomment-691362392
I have the same issue.
Compiled file have a “registerPage” function,it use fetch to acquire external CSS.
ps: downgrading to v9.5.2 can fix the issue
tagging @saponifi3d in case we get some response next week while I'm out.
have same issue, interesting why one chunk is preloaded using fetch, while we have preload link in html?
BTW if smbd like me needs quick fix - downgrading to v9.5.2 fixes issue.
as issue author states basically.
Hi :wave:
Same issue here too. Downgrading to v9.5.2.
Ive got this issue too, upgraded to webpack 5 and suspected it was something to do with crossOrigin loading, but it's the same cssRule issue mentioned here.
This is impacting PR environments that proxy through a stage URL with a query string or cookie value being placed to route assets from deploy locations (CDN) back to the PR env.
Downgrading to 9.5.2 is blocked for us by this CVE: https://nvd.nist.gov/vuln/detail/CVE-2020-15242
v9.5.2, v9.5.3 have a CVE out: https://nvd.nist.gov/vuln/detail/CVE-2020-15242
v9.5.4, 9.5.5 failed due this CORS error
We were forced to downgrade to v9.4.4 until this gets fixed...
We've had some success by discovering an undocumented prop that can be passed into <Head>
in a custom document - make sure that it is the Head
from next/document
.
You can pass in the crossOrigin
prop with a value of either anonymous
or use-credentials
(see relevant MDN). The fetch was successful 👍
edit: just found out that is deprecated - apparently you can add it in next.config.js
instead - see relevant error
We've had some success by discovering an undocumented prop that can be passed into
<Head>
in a custom document - make sure that it is theHead
fromnext/document
.You can pass in the
crossOrigin
prop with a value of eitheranonymous
oruse-credentials
(see relevant MDN). The fetch was successful 👍edit: just found out that is deprecated - apparently you can add it in
next.config.js
instead - see relevant error
thanks for the explanation @sophiekoonin . are you saying that by adding that config to my next.config.js
all assets are loaded with CORS anonymous?
that's an interesting workaround!
@dkempner It seems that way - it's all the link
and script
tags that are added by Next (not any that you include manually). We're exporting our CSS + JS and hosting it on S3, so it works for us.
Thanks again for sharing @sophiekoonin. We confirmed that it works for us too.
Flipping this option on is potentially gonna block a few dozen services get to next
10.
Thrilled there's a workaround. Not all hero's wear capes 😂 thank youu
Started having issues with our Cloudfront deployment as well after upgrading. Some of the chunks get loaded dynamically and were failing due to missing CORS headers. Ended up doing the following:
Access-Control-Allow-Origin
headers setconst express = require('express')
server.use(cors({
origin: process.env.HOST,
optionsSuccessStatus: 200 // some legacy browsers (IE11, various SmartTVs) choke on 204
}));
Access-Control-Request-Headers
Access-Control-Request-Method
Origin
Refer
This issue should be fixed in v10.0.1 https://github.com/vercel/next.js/releases/tag/v10.0.1 via https://github.com/vercel/next.js/issues/17930 / https://github.com/vercel/next.js/pull/18723
This issue should be fixed in v10.0.1 https://github.com/vercel/next.js/releases/tag/v10.0.1 via #17930 / #18723
Thanks @bmathews I'll check it out!
Please let me know if https://github.com/vercel/next.js/pull/18723 fixed this bug for you! Otherwise, I'd love to fix this ASAP.
@Timer I've tried 10.0.1 and am still seeing the CORS error.
I've tried 10.0.1 and am still seeing the CORS error.
Me too.
An error occurs on this line.
It seems to be solved by specifying Access-Control-Allow-Origin
header as * in CDN.
@dkempner can you confirm if this is fixed for you on 10.0.2-canary.10
or newer?
hey @Timer i can do that but it's gonna be a few days. i'll check back in within a week.
No problem! I setup a S3 bucket and confirmed Next.js worked correctly with an assetPrefix
configured to be S3. Seems this is fully fixed in the latest Next.js canaries!
No problem! I setup a S3 bucket and confirmed Next.js worked correctly with an
assetPrefix
configured to be S3. Seems this is fully fixed in the latest Next.js canaries!
you're a king. thanks for that!
Just to clarify: CORS headers still need to be configured on the S3 bucket, but if you don't, Next.js will still allow pages to hydrate, but client side navigations will automatically fall back to a server transition until the CORS error is fixed.
Just to clarify: CORS headers still need to be configured on the S3 bucket, but if you don't, Next.js will still allow pages to hydrate, but client side navigations will automatically fall back to a server transition until the CORS error is fixed.
We've always had *
as our CORS header for S3. Is that sufficient?
Should be!
Most helpful comment
I have the same issue.
Compiled file have a “registerPage” function,it use fetch to acquire external CSS.
ps: downgrading to v9.5.2 can fix the issue