Aspnetcore: 404 when publicPath is set to "/"

[crhairr]

The bug appears to be related to this this line:

https://github.com/aspnet/JavaScriptServices/blob/5f6f288056b3263a61a55631257db14314a02795/src/Microsoft.AspNetCore.SpaServices/Webpack/WebpackDevMiddleware.cs#L114

My webpack config has the following output:

```#js
"output": {
"filename": "js/[name].js",
"path": OutputPath,
"publicPath": "/"
},

If I set the and the WebpackDevMiddleware like such:

```C#
                    .UseWebpackDevMiddleware(new WebpackDevMiddlewareOptions
                    {
                        HotModuleReplacement = true
                    });

Then the hmrEndpoint defaults to "/__webpack_hmr" and the SpaProxy url ends up as "//__webpack_url". Every request to [xxx].hot-update.json (e.g.: http://localhost:5000/7d73bb05e2e2c47519ea.hot-update.json) fails with a 404.

However, if I set up my webpack config like this:

```#js
"output": {
"filename": "js/[name].js",
"path": OutputPath,
"publicPath": "/dist/"
},

Then the SpaProxy url is set to "/dist//__webpack_url" and any request to find the hot-update config (e.g.: `http://localhost:5000/dist/7d73bb05e2e2c47519ea.hot-update.json`) works.

FWIW: overriding the HmrEndpoint to "__webpack_hmr" does not seem to get around the problem:

```C#
                    .UseWebpackDevMiddleware(new WebpackDevMiddlewareOptions
                    {
                        HotModuleReplacement = true,
                        HotModuleReplacementEndpoint = "__webpack_hmr"
                    });

Also, leaving the publicPath blank ("") results in an error.

EDIT: if this is the expected behavior (that publicPath is required to be set to "/dist/") then the documentation should reflect this. Otherwise, this is a bug likely due to oversimplification of the logic that builds the proxy server URLs.

[SteveSandersonMS]

Thanks for posting. Could you please supply repro steps, starting from creating a new project with the template? I'm not clear on what's going on that would lead to this.

[crhairr]

From what I've seen in the code, it appears to do with the way the SpaProxy attempts to intercept requests, and how this relates to the URL used by the [xxx].hot-update.json requests. If publicPath is set to "/", then the hot-update request is issued on the application base URL, e.g.: http://localhost:5000/7d73bb05e2e2c47519ea.hot-update.json. This always results in a 404.

But if publicPath is set to a subdirectory like "/dist/" then the hot-update request goes to a subdirectory of the primary app, e.g.: http://localhost:5000/dist/7d73bb05e2e2c47519ea.hot-update.json.

I'm guessing that this has to do with how the SpaProxy intercepts GET requests at the primary url in order to redirect to the SPA fallback route. Since it's a get request on "~/", it just bombs. At least, that's what seems to be going on.

I think that the SpaProxy just needs a little tweaking so that it can interpret and intercept the hot-update.json requests when its URL is essentially "~/".

It might be a few days before I get the time to create a repro project.

[SteveSandersonMS]

Thanks for the extra info.

It might be a few days before I get the time to create a repro project.

Please don't create a repro project. Please describe the steps needed to repro the issue based on a clean new app :)

[crhairr]

I've verified the following steps in two different _existing_ projects using the latest ASP.NET Core WebpackDevMiddleware:

1. Set output.publicPath in webpack.config.js to "/":

        "output": {
            "filename": "js/[name].js",
            "path": OutputPath,
            "publicPath": "/"
        },

1. Rebuild and launch the app.
2. Modify and save any file served by webpack.
3. Check the JavaScript/developer console in the browser.

You'll get a 404 for each file affected by the modification.

If you want me to make sure this repros in a clean new app, I'll have to create one (i.e. a new project) and verify that, even if I don't send it to you. ;)

[MJLHThomassen-Eurocom]

I can confirm this problem. Also seeing this in my setup. If my publicPath is "/" the hot-update.json's aren't found, even if i modify the webpack config so that the files are not served directly from root like so:

module.exports = {
(...)
  output: {
    (...)
    hotUpdateChunkFilename: 'hot/[id].[hash].hot-update.js',
    hotUpdateMainFilename: 'hot/[hash].hot-update.json'
}
}

I still get 404's on the hot-module.js and json's. Changing publicPath to something (in my case "/debug/") fixes the issue.

[crhairr]

I've verified the repro steps with the last 2 webpack-based ASP.NET Core templates. Just open webpack.config.js and change publicPath from "/dist/" to "/" (or "") and the webpack middleware suddenly can't handle any HMR requests.

The event stream still connects, so the client side can see that something was updated. But whenever the HMR client attempts to grab an updated file, it will only get a 404.

FWIW: the workaround is to set publicPath to "/dist/" (I presume any subdirectory of the output folder will work, but I haven't verified that yet). This is annoying only because I don't like unnecessary folders, and this is just a really silly gotcha to have to remember whenever using ASP.NET Core and Webpack.

[SkeletonSkelettron]

crhairr

I'm guessing that this has to do with how the SpaProxy intercepts GET requests at the primary url in order to redirect to the SPA fallback route. Since it's a get request on "~/", it just bombs. At least, that's what seems to be going on.

that's not the case. I placed sample .hot-update.json file in the root ditectory and was able to retrieve the file with get http://localhost:5000/.hot-update.json .

[SkeletonSkelettron]

will 2.1 release address this issue?

[crhairr]

You could retrieve that file thanks to the StaticFiles middleware, which I assume you have active if you used the template. The hot-update.json "files" do not actually go into the file system. They're generated by the HMR service on-demand to describe updated resources. The SpaProxy has trouble mapping requests for the *hot-update.json files when they're served from "/" instead of a different subfolder.

The bug appears to be that SpaProxy just doesn't look for HMR requests of the form "*.hot-update.json", but instead attempts to map __any__ request to a resource under the Webpack publicPath, and thus can't handle anything under "/" due to route conflicts.

[MJLHThomassen-Eurocom]

FWIW: the workaround is to set publicPath to "/dist/" (I presume any subdirectory of the output folder will work, but I haven't verified that yet). This is annoying only because I don't like unnecessary folders, and this is just a really silly gotcha to have to remember whenever using ASP.NET Core and Webpack.

Yes, like i already said:

I still get 404's on the hot-module.js and json's. Changing publicPath to something (in my case "/debug/") fixes the issue.

This actually works for ANY value of the publicPath EXCEPT "/". You can even put-non-existing (aka paths not on your drive) in there, it does not matter since the "path" is really just something that only exists in the webpack server's memory.

However, i agree with @crhairr , I also do not like the fact this bug causes the website to be REQUIRED to be served from something else then "/". In production, my SPA resides at "/" and I want as little difference between production and development modes as possible. This should be fixed.

[SkeletonSkelettron]

MJLHThomassen-Eurocom

FWIW: the workaround is to set publicPath to "/dist/" (I presume any subdirectory of the output folder will work, but I haven't verified that yet). This is annoying only because I don't like unnecessary folders, and this is just a really silly gotcha to have to remember whenever using ASP.NET Core and Webpack.

when I set publicPath to anything different from '/', then project stops working properly in visual studio 2017. project runs, browser opens but it does not wait for webpack to complete build, it fails load page and then I have to reload page manually, when webpack build is completed.
I prefer to start it normally and refresh manualy for updates.

[MJLHThomassen-Eurocom]

@SkeletonSkelettron Ah ok, well thats another problem I think. In my project setup, I actually have a windows service running as a console app which self-hosts a WebApi and my app (with webpack in dev mode) so i have to manually go to localhost:5000 (in my case) in a browser window anyway. I dont really mind this for the initial load as long as HMR picks up from there.

[Tagliatti]

I have this same problem, and as soon as I read the above solutions, it worked. I changed the publicPath: "/" to publicPath: "/temp/" and created a temp folder in wwwroot, and the problem was resolved, or at least resolved while this bug is not fixed.

[Nordes]

@crhairr Thank's, adding the '~' before the / fixed everything in my case.

[mkArtakMSFT]

@ryanbrandenburg, can you please look into this? Thanks!

[ryanbrandenburg]

I wasn't able to replicate this locally using our WebPack sample. Could someone still experiencing this produce a repro project that I could use to investigate?

[ryanbrandenburg]

Closing this as we have no repro. If someone is still having trouble here create a new issue with a reproduction app and reference this issue.