URL Rewrite exceptions for Blazor WebAssembly Hosted deployment

Question

During development, i have used Swagger on the server side of my Blazor WebAssembly App. Always launching (debug) using kestrel instead of IIS Express. Routing worked as expected, all my component routed properly and if i manually typed /swagger, i got to the swagger page. All good.

We have deployed under IIS on our pre-prod servers, the Server side and Blazor WebAssembly App (client) work as expected and are usable, however, my /swagger url gets rewritten (I assume) to go somewhere in my App instead of letting it go to Swagger, obviously there isn't any component that answers to /swagger.

My only guess is that, when hosted on IIS, the aspnet core app takes care of telling IIS what to rewrite and how (similar to the configs that could be provided thru a web.config for a "Standalone" deployment.)

I can't find how to specify exceptions, I've been following the doc at https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/blazor/webassembly?view=aspnetcore-3.1#iis

Any idea how i could add an exception for /swagger ?

EDIT:

Turns out it works without issues in Chrome, only Firefox has the unwanted behavior. If i clear my cache, or use Incognito mode, the issue does not happen in Firefox. So, it seems that Firefox caches some stuff and tries to send my URL input to the Blazor Wasm instead of going thru to the server. I will debug some more with the dev tools and fiddler open to try and figure it out, will report back.

Answer 1

Turns out there this is part of the service-worker.js file that is published. It is different in dev than what gets published (which makes sense).

During my debugging i was able to reproduce the issue on all browsers (Edge, Chrome and Firefox), regardless of being in Incognito/Private mode or not.

Once the service-worker is running, it handles serving requests from cache/index.html of the Blazor WebAssembly app.

If you go into your Blazor WebAssembly Client "wwwroot" folder, you'll find a service-worker.js and a service-worker.published.js. In the service-worker.published.js, you will find a function that looks like this :

async function onFetch(event) {
    let cachedResponse = null;
    if (event.request.method === 'GET') {
        // For all navigation requests, try to serve index.html from cache
        // If you need some URLs to be server-rendered, edit the following check to exclude those URLs
        const shouldServeIndexHtml = event.request.mode === 'navigate'
            && !event.request.url.includes('/connect/')
            && !event.request.url.includes('/Identity/');

        const request = shouldServeIndexHtml ? 'index.html' : event.request;
        const cache = await caches.open(cacheName);
        cachedResponse = await cache.match(request);
    }

    return cachedResponse || fetch(event.request);
}

Simply following the instructions found in the code comments is gonna fix the issue. So we ended up adding an exclusion for "/swagger" like so :

&& !event.request.url.includes('/swagger')

Hopefully this post is useful for people who are gonna want to serve things outside of the service worker, not only Swagger.

Answer 2

Do you have UseSwagger first in your Startup.Configure method?

public static void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseSwagger();
    app.UseSwaggerUI(c =>
        c.SwaggerEndpoint("/swagger/v1/swagger.json", "YourAppName V1")
    );

In Startup.ConfigureServices I have the Swagger code last.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.AddSwaggerGen(c =>
        c.SwaggerDoc(
            name: "v1",
            info: new OpenApiInfo
            {
                Title = "YourAppName",
                Version = "V1",
            }));
}

This is working just fine for us.

Note: You must navigate to https://yourdomain/swagger/index.html