[Templating] Investigate error messages in the chrome/firefox dev console for SPAs

[javiercn]

On firefox and chrome, the React and Angular SPA produce a series of error during development.
We need to figure out what's happening in there.

[javiercn]

[ryanbrandenburg]

@mkArtakMSFT we've discussed this issue before. The problem is in JavaScript services, where I don't have any context. @SteveSandersonMS was on vacation the last time it was brought up, perhaps we can discuss it with him now.

[SteveSandersonMS]

I thought the problem was that the dev servers (Angular CLI / create-react-app) emit code that tells the client to make a WebSocket connection back to the dev server. Since we're proxying to the dev server, the WebSocket connection actually goes to the ASP.NET Core host application (which is good and correct), but then somehow we're failing to proxy that WebSocket connection properly.

So my guess is someone needs to debug the proxying code to see why we're not letting the browser and the Angular/React dev server talk to each other in the way they expect.

[SteveSandersonMS]

The error message does contain the clue "Invalid host/origin header", so maybe it's something like: the proxy code needs to rewrite the origin header so that the Angular/React dev server believes the request is coming directly to it, and not from some other origin.

[mkArtakMSFT]

@ryanbrandenburg please reevaluate this as this seems to be really bad. We should try to fix this as early as possible but the current M costing is a bit heavy.

[ryanbrandenburg]

This seems to only happen when the app isn't published (because when we publish and are thus in Production it doesn't use webpack-dev-server).

[javiercn]

That's fine, We don't want to see these exceptions during Development because they are unwanted noise. That's what we want to fix here.

[ryanbrandenburg]

The Invalid Host/Origin thing is a separate, Firefox-only problem that can be solved by doing this. That said disabling the host check is dangerous, so it's unclear if we want that fix. The websocket connection problem doesn't seem solvable by re-writing the host/origin headers because even when we set --disableHostCheck=true we still get the get the warnings.

[ryanbrandenburg]

This comment says that this warning doesn't indicate a problem and can be ignored, but that's in the context of it only happening 5% of the time (as opposed to 100%). If we still care about resolving this given that and the fact that HotLoading still works (as long as you fix the Firefox Origin thing) then what I need to proceed is a call with @SteveSandersonMS so we can figure out how to diagnose and proceed. I talked with some people in the server room and they didn't have ideas.

[mkArtakMSFT]

Filed #9400 to handle the one dependency update to avoid many errors

[DaniJG]

The SPA approach seems to be having ASP.NET Core in charge, with HTTP traffic always coming to ASP.NET Core who will proxy to the SPA's dev server.

Have you people considered the opposite approach? On startup, ASP.NET Core could still launch the start/serve scripts of the SPA but it can then tell the browser to direct traffic to the SPA dev server, and its the dev server the one that will proxy API requests to the ASP.NET Core process.

All the major web frameworks support the proxy option (they all end up using the webpack dev server) and it seems to me proxying API requests is simpler/faster than proxying the hot reload web sockets...

• https://facebook.github.io/create-react-app/docs/proxying-api-requests-in-development
• https://cli.vuejs.org/config/#devserver-proxy
• https://angular.io/guide/build#proxying-to-a-backend-server

The main challenge I see is to make sure the port configured for ASP.NET Core in development is correctly passed into the devProxy setting, which in the case of angular/react seem to be static json files. It could be set when the template is first created, but the ports for IISExpress and Kestrel are different... Not sure if react/angular allow those settings to be in a regular .js file (Vue does), because then you can setup an env variable from .NET which is then read on that file as part of the npm start/serve command. Otherwise you could modify those json config files before running the npm script (which isnt great tbh)

Maybe this was already considered by the team and discarded in favour of the current approach, but if not it might be worth exploring.

[javiercn]

@SteveSandersonMS Do you have any thoughts? We could do the proxying in the templates, but I feel thats a big departure from the way things work today.

[SteveSandersonMS]

The websocket connection problem doesn't seem solvable by re-writing the host/origin headers because even when we set --disableHostCheck=true we still get the get the warnings.

I don't follow how it's possible to still get the warnings if the proxying is being done correctly. How can the browser even distinguish between having a direct connection to the SPA's dev server versus a reverse-proxy to it? If the reverse proxying is being done well enough then the browser shouldn't be able to know there's a difference.

I'd recommend trying to rewrite the origin header and seeing whether that does help. If there are still problems, look at network traces to determine what's different between having the reverse proxy versus loading the site directly in the Angular/React dev server.

[SteveSandersonMS]

It's possible also that moving to newer versions of the libraries may fix it (if the problem is nothing to do with our code and instead is just purely a bug in sockjs.js or Webpack). There was a workaround applied in Webpack in https://github.com/webpack/webpack-dev-server/pull/1608/files.

[mkArtakMSFT]

Yeah, sounds like this is exactly what @ryanbrandenburg was referring to. It seems that have been merged a while ago already. @ryanbrandenburg can you please check what dependencies we should pick up to get this fix and see whether this issue is resolved?

[mkArtakMSFT]

Given that this has no functionality impact, and this will be resolved when impacted SPA frameworks will pick up the Webpack workaround and we'll update our dependencies, we'll just wait.

[javiercn]

This doesn't apply in 6.0