You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
runtime~main.xxxx.js is inserted as inline script in generated index.html #5309
That’s intentional. We want to inline this chunk because it’s usually small and isn’t worth a separate request. But some people use asset manifest from CRA with a custom HTML so we want to make it easy for them to read it.
For the record it is about 3Kb in my application (not sure if it is a lot or not).
It would still be a waste to send a separate HTTP request for a 3Kb file, unless you reload the page on every navigation (in which case you can add client-side routing?)
Banning inline script is the biggest security win CSP provides
As I see it, users of CRA implementing CSP will run their app, and likely see a console error similar to this
This likely directs users down the path of least resistance (i.e the wrong path) by adding script-src: "unsafe-inline" to get rid of the error, and opening up a potential XSS security hole in their application?
Reacted by Pooria Atarzadeh, Jartto, Martin Costello, Teimuraz, Ilya, Jean-Luc Sorak and Alex Louden
Yeah, this really doesn't seem to make sense. I don't want to have to add a weird build step where it tries to inject a nonce into the built index.html using some fucky sed trick, but I really don't want to add "unsafe-inline".
It would still be a waste to send a separate HTTP request for a 3Kb file, unless you reload the page on every navigation (in which case you can add client-side routing?)
Isn't that was caching/HTTP2 is for?
Reacted by James Cunningham, Salvo Canna, Andy Berry, Rick Barkhouse, Martin Costello, Ilya and Jean-Luc Sorak
HTTP2 is very far from being widely adopted. Caching doesn’t help because the runtime chunk will be different on every build. That’s the exact reason why it exists — to separate it from less often changing code.
I’m fine with adding an environment variable that disables the inlining. Wanna send a PR?
Reacted by Alexander Forbes-Reed, Geordie Powers and Aleksej Romanovskij
https://caniuse.com/#search=http2 says only IE 11, Opera Mini and "UC Browser for Android" (whatever that is) does NOT support HTTP2.
So for the majority of browsers, inline scripting small scripts makes the performance worse, ...in theory. I haven't done extensive measurements to support this but if the HTML document (the build/index.html) can be delivered slightly sooner, the browser can spawn other important tasks sooner such as downloading linked style sheets, scripts and etc.
Also, leaving it on by default does encourage the risk of people letting their CSP policy include 'unsafe-inline'.
Having said all of that, I appreciate that I have a very limited context on the run-up to this change in 2.0 and perhaps I've missed some other subtle analysis of the advantages of inlining.
What I'm suggesting is that it does not inline unless you set INLINE_SMALL_SCRIPTS=true yarn run build.
I'm guessing this was just a rough suggestion but let's at least denote that the inlining is based on some webpack rule that deems the script very small.
Lastly about the web performance; inlining is often better than a blocking resource. I.e. it's better to serve a 700KB (than a 600KB) HTML document if it means you don't have to block the parsing until all .js files have been downloaded and parsed. With HTTP2, the blocking hurts a LOT less than it used to.
Ideally, what you should do is <script async src="/static/...> the script tags. Then they don't require a new HTTP connection to a different SSL/DNS and it won't block rendering of what little HTML you get on the first GET. Most build/index.html files are just <body><div id="root"></div><script...></body> so it's not a huge deal anyway.
If you have a specific proposal for how it should work (along with how to make webpack emit and work with <script async>), you're welcome to file a separate proposal for discussion, or a PR. I agree our current solution is not ideal but the fact that a better solution is possible in theory shouldn’t stop us from making incremental improvements.
https://caniuse.com/#search=http2 says only IE 11, Opera Mini and "UC Browser for Android" (whatever that is) does NOT support HTTP2.
I was talking about what people use in production today, not about what they could possibly use based on browser support. Adoption depends on hosting, server side solutions and many other factors. Industry-wide, HTTP2 adoption is still low.
Reacted by Peter Bengtsson, Alex Guerra and Jean-Luc Sorak
Unless I'm mistaken, this doesn't appear to be resolved in 2.0.5; an inline script is still being added to build/index.html such that I'm seeing the following error when trying to use the React app I create using create-react-app in a Chrome extension:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' blob: filesystem: chrome-extension-resource:". Either the 'unsafe-inline' keyword, a hash ('sha256-GgRxrVOKNdB4LrRsVPDSbzvfdV4UqglmviH9GoBJ5jk='), or a nonce ('nonce-...') is required to enable inline execution.
Am I mistaken in assuming this should not be happening anymore under 2.0.5?
EDIT: It looks like there was some discussion in this issue and others about adding an environment variable. Is that what @gaearon was referring to with regards to it being "out in 2.0.5," or was that referring to something else? Apologies for the confusion.
EDIT 2: Sorry, just saw #5354 and INLINE_RUNTIME_CHUNK in the README here. Thanks!
Reacted by Cody Henshaw, Ian Witherow and Martin Costello
Activity
gaearon commentedon Oct 5, 2018
That’s intentional. We want to inline this chunk because it’s usually small and isn’t worth a separate request. But some people use asset manifest from CRA with a custom HTML so we want to make it easy for them to read it.
stereobooster commentedon Oct 5, 2018
For the record it is about 3Kb in my application (not sure if it is a lot or not).
Update: also it can break in case of strict CSP
gaearon commentedon Oct 5, 2018
It would still be a waste to send a separate HTTP request for a 3Kb file, unless you reload the page on every navigation (in which case you can add client-side routing?)
See #5288
whawker commentedon Oct 8, 2018
Seems crazy to me to force the inline of a single script to save 1 request, and breaking the biggest win of CSP.
Taken from Google's guide to CSP
As I see it, users of CRA implementing CSP will run their app, and likely see a console error similar to this

This likely directs users down the path of least resistance (i.e the wrong path) by adding
script-src: "unsafe-inline"to get rid of the error, and opening up a potential XSS security hole in their application?0xdeafcafe commentedon Oct 8, 2018
Yeah, this really doesn't seem to make sense. I don't want to have to add a weird build step where it tries to inject a nonce into the built
index.htmlusing some fuckysedtrick, but I really don't want to add"unsafe-inline".Isn't that was caching/HTTP2 is for?
stereobooster commentedon Oct 8, 2018
I hope it won't turn into battle as it was with ServiceWorkers. (This wasn't my intention when I opened issue)
Also we can lock this ticket and continue conversation after #5288, which should address
"unsafe-inline"issue.gaearon commentedon Oct 8, 2018
HTTP2 is very far from being widely adopted. Caching doesn’t help because the runtime chunk will be different on every build. That’s the exact reason why it exists — to separate it from less often changing code.
I’m fine with adding an environment variable that disables the inlining. Wanna send a PR?
0xdeafcafe commentedon Oct 8, 2018
That's great. I've never contributed to this project before, so I'll have a try at adding that now. Thanks!
Timer commentedon Oct 8, 2018
Probably look for
INLINE_SCRIPT=false?PerfectPixel commentedon Oct 8, 2018
Something like this? https://github.com/PerfectPixel/create-react-app/commit/14584aac78e7275693c4b9893e21f3ec8b21922c 😄
peterbe commentedon Oct 8, 2018
@gaearon
https://caniuse.com/#search=http2 says only IE 11, Opera Mini and "UC Browser for Android" (whatever that is) does NOT support HTTP2.
So for the majority of browsers, inline scripting small scripts makes the performance worse, ...in theory. I haven't done extensive measurements to support this but if the HTML document (the
build/index.html) can be delivered slightly sooner, the browser can spawn other important tasks sooner such as downloading linked style sheets, scripts and etc.Also, leaving it on by default does encourage the risk of people letting their CSP policy include
'unsafe-inline'.Having said all of that, I appreciate that I have a very limited context on the run-up to this change in 2.0 and perhaps I've missed some other subtle analysis of the advantages of inlining.
What I'm suggesting is that it does not inline unless you set
INLINE_SMALL_SCRIPTS=true yarn run build.peterbe commentedon Oct 8, 2018
I'm guessing this was just a rough suggestion but let's at least denote that the inlining is based on some webpack rule that deems the script very small.
peterbe commentedon Oct 8, 2018
Lastly about the web performance; inlining is often better than a blocking resource. I.e. it's better to serve a 700KB (than a 600KB) HTML document if it means you don't have to block the parsing until all
.jsfiles have been downloaded and parsed. With HTTP2, the blocking hurts a LOT less than it used to.Ideally, what you should do is
<script async src="/static/...>the script tags. Then they don't require a new HTTP connection to a different SSL/DNS and it won't block rendering of what little HTML you get on the first GET. Mostbuild/index.htmlfiles are just<body><div id="root"></div><script...></body>so it's not a huge deal anyway.gaearon commentedon Oct 8, 2018
If you have a specific proposal for how it should work (along with how to make webpack emit and work with
<script async>), you're welcome to file a separate proposal for discussion, or a PR. I agree our current solution is not ideal but the fact that a better solution is possible in theory shouldn’t stop us from making incremental improvements.I was talking about what people use in production today, not about what they could possibly use based on browser support. Adoption depends on hosting, server side solutions and many other factors. Industry-wide, HTTP2 adoption is still low.
gaearon commentedon Oct 14, 2018
Out in 2.0.5
jamespizzurro commentedon Oct 18, 2018
Unless I'm mistaken, this doesn't appear to be resolved in 2.0.5; an inline script is still being added to
build/index.htmlsuch that I'm seeing the following error when trying to use the React app I create using create-react-app in a Chrome extension:Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' blob: filesystem: chrome-extension-resource:". Either the 'unsafe-inline' keyword, a hash ('sha256-GgRxrVOKNdB4LrRsVPDSbzvfdV4UqglmviH9GoBJ5jk='), or a nonce ('nonce-...') is required to enable inline execution.Am I mistaken in assuming this should not be happening anymore under 2.0.5?
EDIT: It looks like there was some discussion in this issue and others about adding an environment variable. Is that what @gaearon was referring to with regards to it being "out in 2.0.5," or was that referring to something else? Apologies for the confusion.
EDIT 2: Sorry, just saw #5354 and
INLINE_RUNTIME_CHUNKin the README here. Thanks!