aspnetcore: The SPA default page middleware could not return the default page '/index.html' in production application

So the reason we’re getting this is someone is trying to POST AND OPTIONS to /index.html not GET. Which causes this error message and causes a 500 error.

Of course of Azure/IIS sees too many errors in too short a time it tries and recycles the app. the problem is that it’s doing it over and over again which causes everything in that App Service Plan to crash. :<

How do we properly handle this without the site throwing a 500 error?

Note that this only happens in production, not development and as far as I can tell there is no way to handle this error with your own route. This is a major DOS attack vector in spa services that needs to be fixed ASAP.

Another possible workaround is:

app.UseWhen(context => HttpMethods.IsGet(context.Request.Method), builder =>
{
    builder.UseSpa(spa =>
    {
    });
});

This will only run the SpaMiddleware for Get requests, letting all other request pass to the next middleware.

I can confirm that the issue still presents in 3.1 and as @meriturva mentioned it’s very easy to reproduce: Send OPTIONS or POST request to index.html using postman

I can confirm that this is still an issue in .NET 5 I see many comments that are related to misconfiguration. Perhaps an admin can mark those as “not relevant”.

This issue is about POST,OPTIONS calls throwing in production when the configuration is correct and working. This https://github.com/dotnet/aspnetcore/issues/5223#issuecomment-433394061 explains it perfectly. Thank you for that explanation.

The workaround proposed here https://github.com/dotnet/aspnetcore/issues/5223#issuecomment-678530768 does work. However I discovered that it’s not only calls to the base path “/” that throws. Any path that isn’t mapped to a controller will throw. So these will also throw:

• OPTIONS /wubba
• POST /luppa
• PUT /dub
• PATCH /dub/dub

Why shouldn’t it? Could you please explain why post/put should work on a pure get resource?

This issue is about the backend throwing this error

System.InvalidOperationException: The SPA default page middleware could not return the default page ‘/index.html’ because it was not found, and no other middleware handled the request. Your application is running in Production mode, so make sure it has been published, or that you have built your SPA manually. Alternatively you may wish to switch to the Development environment.

When calling a bogus resource then I’d expect the backend to return 404 without incident. In other words. Not throw an exception about the SPA default page middleware.

check angular.json file use “outputPath”: “dist”,

And Startup file

services.AddSpaStaticFiles(configuration => { configuration.RootPath = “ClientApp/dist”; });

The thing is that the problem happens when there is a pending attack. Someone is trying to POST request to a path which isn’t handled by any middleware, so SPA middleware terminates it with that message. Clearly, SPA middleware needs to be amended to address that issue.

To address attack in the first place (as that is the priority), we need to amend @rezabayesteh solution and terminate the further processing and return 404, but that needs to happen before UseSpa().

Next, we need to create an builder extension.

    public static class ApplicationBuilderExtensions
    {
        public static IApplicationBuilder UseRootRewrite(this IApplicationBuilder builder)
        {
            var socks = "/sockjs-node";

            builder.Use(async (context, next) =>
            {
                if (!HttpMethods.IsGet(context.Request.Method) && !context.Request.Path.StartsWithSegments(socks))
                {
                    if (!context.Response.HasStarted)
                    {
                        context.Response.StatusCode = 404;
                        context.Response.CompleteAsync().GetAwaiter().GetResult();
                        return;
                    }
                }
                
               await next();
            });

            return builder;
        }
    }

And finally hook it before UseSpa().

public class Startup() {
    ...
    
    public void Configure(IApplicationBuilder app) {
        app.UseRootRewrite();
        app.UseSpa(config => {});
    }
}

a) if we talk http codes - then i think 405 more appropriate (the index.html is there). b) yeah well a lot of things are not exactly to my liking so what. you send a bogus request and get slightly wrong response wow, 15 pages discussion.

We’re not talking about http codes. You should read the OP. And perhaps also https://github.com/dotnet/aspnetcore/issues/5223#issuecomment-433394061

As stated

This issue is about the backend throwing this error

System.InvalidOperationException: The SPA default page middleware could not return the default page ‘/index.html’ because it was not found, and no other middleware handled the request. Your application is running in Production mode, so make sure it has been published, or that you have built your SPA manually. Alternatively you may wish to switch to the Development environment.

When it shouldn’t. Nothing more.

Anyone has got a solution for this? I’m facing the same issue, can’t get the app deployed successfully…

Here is our case for past 2 days. It is really random. We have 3 servers and one of them barely has this issue in last 48 hours but it did have a lot before that.

I’ve used the following middleware, that check if allowed method is used before passing control to the Spa:

    public static class SpaExtensions
    {
        public static void UseGuardedSpa(this IApplicationBuilder app, Action<ISpaBuilder> configuration)
        {
            // Prevent 500 error if POST invoked on '/' 
            app.Use(async (context, next) =>
            {
                if (context.GetEndpoint() == null && !HttpMethods.IsGet(context.Request.Method) && !HttpMethods.IsHead(context.Request.Method))
                {
                    context.Response.StatusCode = 404;
                    await context.Response.WriteAsync($"Forbidden {context.Request.Method}");
                }
                else
                {
                    await next();
                }
            }
            );
            app.UseSpa(configuration);
        }

    }

And then instead of app.UseSpa in Configure call app.UseGuardedSpa

In VS 2022 with .Net Core 6 the standard ASP.Net Angular project template does not return index.html at all in Production mode. And I fixed that with the following code:

// Serve files from wwwroot
app.UseStaticFiles();
// In production, serve Angular files and default page from ClientApp/dist
if (!app.Environment.IsDevelopment())
{
    app.UseFileServer(new FileServerOptions
    {
        FileProvider = new PhysicalFileProvider(Path.Combine(app.Environment.ContentRootPath, "ClientApp/dist"))
    });
}

PS. But it also requires changing the SPA deployment folder from wwwroot to ClientApp/dist (as it was in ASP.Net Core 3.1 template): <!--<RelativePath>wwwroot\%(RecursiveDir)%(FileName)%(Extension)</RelativePath>--> <RelativePath>%(DistFiles.Identity)</RelativePath>

@jraadt If you removed the SpaServices extensions, how are you doing the SPA setup in Startup.cs? Using the default template, your app should no longer build after removing that package reference.

Thank you @Redart98

This is a huge gaping DOS hole in the .net core SPA framework. Yes, it makes sense to redirect routes to the SPA so it can handle routing on the front end, but I’m getting POST requests to index.html that are being redirected to the SPA middleware. It makes no sense.

@caseysick Here is the complete solution:

public static class ApplicationBuilderExtensions
{
    public static IApplicationBuilder UseRootRewrite(this IApplicationBuilder builder)
    {
        string[] excludeUrls = new[] { "/sockjs-node" };

        builder.Use((context, next) =>
        {
            if (!HttpMethods.IsGet(context.Request.Method) && 
                !context.Request.Path.StartsWithSegments(excludeUrls))
            {
                context.Request.Method = "GET";
            }

            return next();
        });

        return builder;
    }
}

public class Startup
{
    public IWebHostEnvironment HostEnvironment { get; }
    public IConfiguration Configuration { get; }

    public Startup(IConfiguration configuration, IWebHostEnvironment env)
    {
        HostEnvironment = env;
        Configuration = configuration;
    }

    public void ConfigureServices(IServiceCollection services)
    {
        ...
    }

    public void Configure(IApplicationBuilder app)
    {
        ...
        app.UseCustomStaticFiles();
        app.UseCustomSpaStaticFiles();
        app.UseRouting();
        app.UseCors(ServerConstants.AnyOriginCorsPolicy);
        app.UseCookiePolicy();
        app.UseAuthentication();
        app.UseAuthorization();
        app.UseSession();
        app.UseCustomEndpoints();
        app.UseRootRewrite();
        app.UseCustomSpa(HostEnvironment);
    }
}

So I just ran into this issue. Turns out that the problem is that asp.net core is weird in how it builds its stuff.

There are a bunch of DLLs that look like your production build in ProjectName/bin/Release/netcoreappX.X/, however, there are also a bunch of the same DLLs plus more stuff like your build client and drivers in the folder below is called publish. So if you run the one above, it can’t find your ClientApp folder. If you run the one in the publish folder, it finds it since the publish command moves it there.

TLDR: Run dotnet ProjectName/bin/Release/netcoreappX.X/publish/ProjectName.dll since it has the built ClientApp files right next to it.

Hope this helps somebody.

Guys, I found this discussion because my asp.net core app + ng7 (with /api hosted) returned always index.html on /api calls.

Solution was to call UseMvc and UseSpa (inside Configure method) in correct order. Correct order:

1. UseMvc
2. UseSpa Please check your order call. I hope, this help somebody…

ON THE END OF Startup.cs::Configure()

        app.UseStaticFiles();
        app.UseSpaStaticFiles();

        app.UseMvcWithDefaultRoute();
        app.UseSpa(spa =>
        {
            spa.Options.SourcePath = "wwwroot"; // see https://go.microsoft.com/fwlink/?linkid=864501
        });

I can’t even get a dotnet new react to start in production (building with dotnet publish -c Release) without it throwing this exception: System.InvalidOperationException: The SPA default page middleware could not return the default page '/index.html' because it was not found, and no other middleware handled the request...

Seems like there is definitely a bug in the building process of the spa somewhere?

@SteveSandersonMS @Eilon

Sorry - not sure if you saw my edit, but I was in fact setting the RootPath correctly, I was just looking in the wrong place. 😃 I will try removing the SourcePath setting, however, I’m fairly certain this configuration came with the dotnet new angular template. What is the SourcePath setting used for and why shouldn’t it be set?

SSR isn’t the problem. You should set path in ConfigureServices() method via services.AddSpaStaticFiles(configuration => configuration.RootPath = $"ClientApp/dist");. Then in Configure you shouldn’t specify source path:

app.UseSpaStaticFiles();
app.UseSpa(configuration => { /*spa.Options.SourcePath = "ClientApp";*/ });

spa.Options.SourcePath is only used in development build judging from its’ description.

Do angular output directory and specified path in services.AddSpaStaticFiles(configuration => configuration.RootPath = $"your/output/path"); match? Files in the specified folder must be computed to publish in your .csproj file like this:

  <Target Name="PublishRunWebpack" AfterTargets="ComputeFilesToPublish">
    <!-- Include the newly-built files in the publish output -->
    <ItemGroup>
      <DistFiles Include="your\output\path\**" />
      <ResolvedFileToPublish Include="@(DistFiles->'%(FullPath)')" Exclude="@(ResolvedFileToPublish)">
        <RelativePath>%(DistFiles.Identity)</RelativePath>
        <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
      </ResolvedFileToPublish>
    </ItemGroup>
  </Target>

On my development machine, my REACT as part of a bigger VS 2019 solution (REACT and a C# API) runs fine in IISExpress. Publishing “to PROD” causes host to look in ClientApp/build for index.html. IISExpress is looking in ClientApp/public and finding Index.html there. I have to change the Startup.cs (ConfigureServices and app.UseSpa)file depending upon where the solution is being published.

---

` using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Hosting; using Microsoft.AspNetCore.HttpsPolicy; using Microsoft.AspNetCore.SpaServices.ReactDevelopmentServer; using Microsoft.Extensions.Configuration; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Hosting;

namespace [redacted] { public class Startup { public Startup(IConfiguration configuration) { Configuration = configuration; }

    public IConfiguration Configuration { get; }

    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {

        services.AddControllersWithViews();

        // In production, the React files will be served from this directory
        services.AddSpaStaticFiles(configuration =>
        {
            // for IIS Express
            // configuration.RootPath = "ClientApp";

            // for DiscountASP
            configuration.RootPath = "ClientApp/build";
        });
    }

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        else
        {
            app.UseExceptionHandler("/Error");
            // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
            app.UseHsts();
        }

        app.UseHttpsRedirection();
        app.UseStaticFiles();
        app.UseSpaStaticFiles();

        app.UseRouting();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapControllerRoute(
                name: "default",
                pattern: "{controller}/{action=Index}/{id?}");
        });

        app.UseSpa(spa =>
        {
            // for IISExpress
            // spa.Options.SourcePath = System.IO.Path.Join(**env.ContentRootPath, "ClientApp"**); // "ClientApp/build"; //
            
            // for DiscountASP
            spa.Options.SourcePath = System.IO.Path.Join(env.ContentRootPath, "ClientApp/build"); //"ClientApp"); 

            //https://github.com/dotnet/aspnetcore/issues/6342#issue-395713046
            spa.Options.StartupTimeout = System.TimeSpan.FromSeconds(300);
            if (env.IsDevelopment())
            {
                spa.UseReactDevelopmentServer(npmScript: "start");
            }
        });
    }
}

} `

Here is my workaround:

public static IApplicationBuilder UseRootRewrite(this IApplicationBuilder builder)
{
    builder.Use((context, next) =>
    {
        if (context.Request.Path == "/" && !HttpMethods.IsGet(context.Request.Method))
        {
            context.Request.Method = "GET";
        }

        return next();
    });

    return builder;
}

Asp.net Core team can easily fix this issue by modifying line 50 in rc\Middleware\SpaServices.Extensions\src\SpaDefaultPageMiddleware.cs:

 // If we have an Endpoint, then this is a deferred match - just noop.
 if (context.GetEndpoint() != null || !HttpMethods.IsGet(context.Request.Method))
 {
     return next();
 }

I can confirm that errors is related to POST and OPTIONS call to index.html. I really don’t know if with new 3.1 version issue still present.

Sentry is really happy about it 😃

I was beating my head against the wall on this and dropping a few cuss words when it finally hit me. I had my configuration defined as configuration.RootPath = "ClientApp/dist";. However, in my build process (within docker running on linux), I noticed that the final build output in the container was under the folder clientapp. Note the case sensitivity changes, which matters for Linux of course. Changing my config in Startup.cs to configuration.RootPath = "clientapp/dist"; fixed it for me. Note that I couldn’t run my app at all, which seems slightly different from what others in this thread are experiencing.

@cole21771 This helped me figure it out. I was the calling executable on the command line using its absolute path in the publish directory (let’s say /home/me/project/bin/publish/myapp). This would give me the The SPA default page middleware could not return the default page '/index.html' exception. I got it to work by first changing the working directory to the publish folder and running it from there, so cd /home/me/project/bin/publish and ./myapp.

I have the same issue, but what I can see is that the index.html that the server returns is from wwwroot/ not from ClientApp/build (my distribution directory) therefore problem lies with wrong index.html being served. Can anybody tell me how can this be fixed?

I stand corrected.

The middleware didn’t work.

I added an exception handler that looks like this:

public class ExceptionHandlerMiddleware
    {
		private readonly ILogger Logger;
        public ExceptionHandlerMiddleware(ILogger logger) {
			Logger = logger ?? throw new ArgumentNullException(nameof(logger));
		}

		public async Task Invoke(HttpContext context) {
			context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;

			var ex = context.Features.Get<IExceptionHandlerFeature>()?.Error;
			if (ex == null)
				return;

			Logger.LogError(new EventId(500, "InternalServerError"), ex, ex.Message);

			context.Response.ContentType = "text/html";
			context.Response.StatusCode = (int) HttpStatusCode.BadRequest;
			using (var writter = new StreamWriter(context.Response.Body)) {
				await writter.WriteLineAsync("<html>");
				await writter.WriteLineAsync("<body>");
				await writter.WriteLineAsync("<p>Invalid request.</p>");
				#if(DEBUG)
				await writter.WriteLineAsync($"<p>{ex.InnerException?.Message ?? ex.Message}</p>");
				#endif
				await writter.WriteLineAsync("</body>");
				await writter.WriteLineAsync("</html>");
				await writter.FlushAsync();
			}
		}
    }

and added it to the Configure function in the Startup.cs but only if not in development mode like this:

				app.UseExceptionHandler (new ExceptionHandlerOptions {
					ExceptionHandler = new ExceptionHandlerMiddleware (loggerFactory.CreateLogger ("SystemErrors")).Invoke
				});

This effectively catches them and returns an HTML page with a 400 error in those cases. Hope that helps someone!

Removing the node_modules folder and republishing did not solve the issue - still seeing quite a few of these errors logged on the production server. Any idea why that would be?