*.yml files not served and end up with a 404

[Carl-Hugo]

Is your feature request related to a problem? Please describe.

I'm trying to query a YAML file over HTTP (whatever.yml), but the server always returns 404. It works when I change the file extension to json or txt. The file is in the wwwroot folder.

The application is a Blazor WebAssembly project, with no server code. I'm running the project using dotnet watch run; the result is the same when I dotnet run.

Describe the solution you'd like

Give application developers more control over what type of files are served, using configuration.

Assuming that the server returns 404 because no mime-type/mapping for .yml is registered in FileExtensionContentTypeProvider.cs, what about allowing us to add mime-types to the appsettings.json and to the launchSettings.json?

Maybe something like:

{
  "staticFiles": {
    "contentTypeProvider": {
      "mappings": {
        ".yml": "application/x-yaml", //<-- Add .yml
        ".mp4": null //<-- Remove .mp4
      }
    }
  }
}

Additional context

I don't think that the hacky FileExtensionContentTypeProvider workaround from the documentation is good enough. Moreover, that does not work with Blazor wasm (well if it does, please explain to me what I missed; I'm still new to Blazor wasm).

[blowdart]

The file extension is the way to do it already, it's not considered hacky.

We made a specific decision to not use config for this sort of thing when developing the static file middleware, rolling it back just for blazor seems awkward.

It should be working for blazor if it's in wwwroot and you've registered the type. There's always server side code, because you need a web server to serve up your project.

[Carl-Hugo]

The file extension is the way to do it already, it's not considered hacky.

No offense, but I consider it a bit hacky. That said, if you guys decided that it's good enough, it is good enough, I have no say in that. It is not something that I must play with often anyway; I only had to customize mime-types a few times in 15 years, usually adding missing types, like in this case, yml.

We made a specific decision to not use config for this sort of thing when developing the static file middleware, rolling it back just for blazor seems awkward.

I'm sure that non-Blazor projects could benefit from that too. When I Googled for a cause/workaround/solution, I found many posts/questions about that (not Blazor related).

I'm not expecting an answer, but please think about the following:

Don't you find it overkill to have to explicitly create an instance of FileExtensionContentTypeProvider, configure it manually, create an instance of StaticFileOptions, pass it to the "StaticFiles" middleware, and all of that, only to register one mime-type that was not registered by default?

Even the alternatives like configuring the StaticFileOptions in the ConfigureServices method, or loading your own data from custom settings into custom classes, or all of the other possible combinations, also feel overkill for one mime-type, don't you think?

This would not help me, but I send the idea in the universe: instead of configs, what about leveraging DI? For example services.AddSingleton<IMimeTypeMapping>(new MimeTypeMapping(".yml", "application/x-yaml"); would be pretty simple, or using an extension that do that like: services.RegisterMimeType(".yml", "application/x-yaml");. In my humble opinion, that would be simple and easy; one mime-type, one line of code, easy to read: clean.

It should be working for blazor if it's in wwwroot and you've registered the type. There's always server side code, because you need a web server to serve up your project.

No, I did not register the yml mime-type, because I'm building a client-only application, without any Asp.Net Core server (of course there is a server somewhere running, but none that I have the control on; well if there is a way, please enlighten me, I am all ears).

My Program class looks like that:

public class Program
{
    public static async Task Main(string[] args)
    {
        var builder = WebAssemblyHostBuilder.CreateDefault(args);
        builder.RootComponents.Add<App>("app");
        // Adding dependencies to the container here
        await builder.Build().RunAsync();
    }
}

The goal of my experiment is to deploy a static website; all information is public, so the "database" consists of static JSON and YAML files that I query over HTTP.

Why query static files over HTTP one may ask, well, if I ever see the need to grow the application further, I'll be able to swap out the files by a Web API and/or a document database (TBD if I ever reach that point). Moreover, it's not like I can use System.IO to read the content of a file that is on a remote machine's filesystem.

Why YAML and not JSON, well I can write multiline text in YAML, which is easier to read, write and maintain; by/for humans.

Thanks for your quick response and sorry for this wall of text...

[SteveSandersonMS]

We should consider changing the Blazor dev server to serve any file, regardless of extension. Ideally we'd put in MIME types for as many web-related file types as we can think of, but fall back on application/octet-stream for anything else.

This would not be a security issue because the dev server is only used during development. Additionally, it only serves files that you have chosen to emit to the wwwroot output.

This then frees up developers to configure their production servers however they want, independently of Blazor WebAssembly. If they are hosting on ASP.NET Core, then they have the same defaults and extensibility that ASP.NET Core always provides.

[Carl-Hugo]

We should consider changing the Blazor dev server to serve any file, regardless of extension. Ideally we'd put in MIME types for as many web-related file types as we can think of, but fall back on application/octet-stream for anything else.

This would not be a security issue because the dev server is only used during development. Additionally, it only serves files that you have chosen to emit to the wwwroot output.

Sounds like a plan for Blazor.

In case you plan on doing the same that you do with Asp.Net Core, I think that it would be more flexible to have access to that list of "known mime-types" externally (like config file, machine-wide config file, something) without the need for you to recompile everything to add the mime-type of the "newest cool file type" each time there is one.

This then frees up developers to configure their production servers however they want, independently of Blazor WebAssembly. If they are hosting on ASP.NET Core, then they have the same defaults and extensibility that ASP.NET Core always provides.

I still think that services.RegisterMimeType(".yml", "application/x-yaml"); or options => options.RegisterMimeType(".yml", "application/x-yaml"); or something similar would be better for ASP.NET Core than the actual solution. An hard-coded list is not super flexible, don't you think?