Blazor.server.js not respecting configureSignalR builder defined url/path for disconnnects

[vflame]

Not using <base href="~/">

I have the following in the layout:

<script src="~/_framework/blazor.server.js" autostart="false"></script>
    <script>
        Blazor.start({
            configureSignalR: function (builder) {
                builder.withUrl("/_blazor");
            }
        });
    </script>

When I navigate off the page, the browser is invoking:

https://www.mydomain.com/relative-path/_blazor/disconnect instead of https://www.mydomain.com/_blazor/disconnect

the blazor js client should respect the signalR configured path for all server invocations, not just negotiate and the websocket connection

[javiercn]

@vflame thanks for contacting us.

disconnect is not part of the SignalR protocol, it's a "Blazor specific" endpoint.

Can I ask what reason motivates you use a different url than the default one?

[javiercn]

I think the fix here would involve grabbing the baseUrl from the client after the call to configureSignalR has run here and flow that to the code that handles the disconnect here

[vflame]

I have an existing asp.net core MVC app and want to host a few workflows through blazor components. Existing things are in place (such as pagination) that rely on the querystring of the http request to generate urls. These break when changing the url.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[icnocop]

As a work-around, I added this to Startup.cs in the Configure method:

var rewriteOptions = new RewriteOptions();
rewriteOptions.AddRewrite("_blazor/disconnect", "/_blazor/disconnect", skipRemainingRules: true);
app.UseRewriter(rewriteOptions);

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 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.

[marcvannieuwenhuijzen]

It looks like the configureSignalR function is completely ignored.