aspnetcore: Passing options to UseStaticFiles breaks Blazor Server's static file service

Yeah, blazor should be adding their own static file handler like UseBlazorStaticResources rather than messing with the default.

I just tried adding another call to app.UseStaticFiles() and it now works! That is blazor.server.js is served, as is my site.webmanifest file. To be clear this is what I now have in Startup.Configure(...):

app.UseStaticFiles();

FileExtensionContentTypeProvider provider = new FileExtensionContentTypeProvider();
provider.Mappings[".webmanifest"] = "application/manifest+json";

app.UseStaticFiles(new StaticFileOptions()
{
    ContentTypeProvider = provider
});

Not keen on this, but at least it works!

What a phenomenal time-sink this bug turned out to be for me. Glad there is a suggested workaround, but definitely wish this had been more obvious from the beginning.

Note that this issue can be resolved by using the options pattern in ConfigureServices:

services.Configure<StaticFileOptions>(options =>
{
    options.OnPrepareResponse = ctx =>
    {
        const int durationInSeconds = 60 * 60 * 24;
        ctx.Context.Response.Headers[HeaderNames.CacheControl] =
            "public, max-age=" + durationInSeconds;
    }  
});

and then call UseStaticFiles() in the standard way (without any parameters) in Configure.

You guys should fix this, because it’s a ridiculous bug and Blazor should never have broken the defaults like it did. As @Tratcher observed two and a half years ago.

In terms of trying to encourage people to adopt MS tech, I think fixing these sort of festering sores of massive wasted-time for professional developers would give you far more bang-for-buck than all the “write a web app in one line of code” stuff which seems to get so much effort.

I agree with Will. More effort has gone into punting this over and over than there would have been exhausted in just fixing it. You make a mess, you clean it up. Why is this so hard to understand?

On Tue, Sep 20, 2022 at 2:22 AM Will Dean @.***> wrote:

You guys should fix this, because it’s a ridiculous bug and Blazor should never have broken the defaults like it did. As @Tratcher https://github.com/Tratcher observed two and a half years ago.

In terms of trying to encourage people to adopt MS tech, I think fixing these sort of festering sores of massive wasted-time for professional developers would give you far more bang-for-buck than all the “write a web app in one line of code” stuff which seems to get so much effort.

— Reply to this email directly, view it on GitHub https://github.com/dotnet/aspnetcore/issues/19578#issuecomment-1251944834, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADBFFKF7ZAAS2H3ZY2FN643V7FQ4BANCNFSM4LBRGV2Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>

Thanks for contacting us.

We’re moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it’s very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

I’ve ran into this issue today when I was trying to set the response HTTP headers for static files (.css, .js) that I’m serving as part of my Blazor website.

I’ve followed the documentation https://docs.microsoft.com/en-us/aspnet/core/fundamentals/static-files?view=aspnetcore-6.0#set-http-response-headers but it took me a couple of hours before I realized what the issue was and stumbled upon this bug report.

Adding multiple calls to UseStaticFiles() fixed the issue, but interestingly it seems that the order in which they occur matters. I had to place my overrides before the empty call, or the error would still pop up.

app.UseStaticFiles(new StaticFileOptions
{
    OnPrepareResponse = context =>
    {
        // custom response cache logic
    }
});

 app.UseStaticFiles();

I just wanted to add static asset caching and stumbled upon this problem.

I’ve encountered the same problem.

The solution also comes in this other message which proposes two alternatives:

https://github.com/dotnet/aspnetcore/issues/9588#issuecomment-505465169

The first is the ideal solution. The second is a hack that I would not recommend.

Example:

// ConfigureServices method
services.Configure<StaticFileOptions>(options => {
    FileExtensionContentTypeProvider contentTypeProvider = new FileExtensionContentTypeProvider();
    contentTypeProvider.Mappings[".gpx"] = "application/gpx+xml";

    options.ContentTypeProvider = contentTypeProvider;
});

// Configure method
app.UseStaticFiles();

@Tratcher Thanks - that does make sense, though I didn’t expect it at all, and it feels like a bit of a gotcha.

Would it perhaps be possible for Blazor to detect that it has never been given the chance to run its static file config code and explode somehow early in the run? That would also catch the case where you didn’t have a UseStaticFiles at all - I have seen other people on-line struggling with that.

Or, rather than co-opting (hijacking) the UseStaticFiles to serve-up the manifest resources, could there just be a separate bit of middleware: UseBlazorStaticResources or something, which just served the specific Blazor bits and didn’t touch the normal StaticFile middleware?

@Tratcher It does!

I am not sure where I currently am on the amazed <-> appalled spectrum…