Reverse Proxy => Problem with generated Proxy URL

[iqmeta]

Expected behavior

If you define URL on jQuery Client, SignalR Client should stick to the URL even
with generated proxies.

Problem is, MVC is running App on / (root) on IIS.

SSL is added by a reverse proxy where the / is rewritten to /whatever

Of course signalR thinks /signalr/hubs is therefore correct, but for browser it's /whatever/signalr/hubs

There should be posibility to tell jquery client always use a certain start url
on any calls, or at least always take the relative url passed as parameter defined in client.

Actual behavior

when is set on jquery client $.connection.hub.url = "/whatever/signalr/hubs"
negotiate works HTTP 200, but in result the Url path is the one generated by
proxy from IIS AppPool with is not the url set on client.

So the following connect is 404 because of taking the URL from hub/negotiate reply is for this wrong.

Steps to reproduce

use any reverse proxy (apache/nginx/etc) and map the IIS application to another url
than it's used with IIS directly. hub.url will only be used once for the generated proxies.

 $(function () {
        var ip = $.connection.imageProcessor;
        var path = "../../signalr";
        $.connection.hub.url = path;
        //USAGE LIKE  $.hubConnection(.(path, { useDefaultPath: false } ?
        // FUNCTIONS
        ip.client.ping = function () {
            console.log("Ping");
        };
        // EVENTS
        $.connection.hub.disconnected(function () {
            console.log("Disconnected");
        });
        $.connection.hub.start().done(function () {
            console.log("Started");
        });
    });

negotiate

the result of it

connect call canceled because wrong url

Even with non generated proxies same problem:

var path = "../../signalr";
        var connection = $.hubConnection(path, { useDefaultPath: false });
        var ip = connection.createHubProxy('imageProcessor');
        connection.start(function (d) {
        });

Server generated URL always wins.

[iqmeta]

Working fix for me:

https://github.com/SignalR/SignalR/blob/799d9bc32524066344cb3656e5f28f2fd03ba9b3/src/Microsoft.AspNet.SignalR.Client.JS/jquery.signalR.transports.common.js

from

getUrl: function (connection, transport, reconnecting, poll, ajaxPost) {
            /// <summary>Gets the url for making a GET based connect request</summary>
            var baseUrl = transport === "webSockets" ? "" : connection.baseUrl,
                url = baseUrl + connection.appRelativeUrl,
                qs = "transport=" + transport;

            if (!ajaxPost && connection.groupsToken) {
                qs += "&groupsToken=" + window.encodeURIComponent(connection.groupsToken);
            }

changed/added

getUrl: function (connection, transport, reconnecting, poll, ajaxPost) {
            /// <summary>Gets the url for making a GET based connect request</summary>
            var baseUrl = transport === "webSockets" ? "" : connection.baseUrl,
                url = baseUrl + connection.appRelativeUrl,
                qs = "transport=" + transport;

            //take my url, if not the same!
        if (url != connection.url) {
                url = connection.url;
            }

            if (!ajaxPost && connection.groupsToken) {
                qs += "&groupsToken=" + window.encodeURIComponent(connection.groupsToken);
            }

Works on / (root) if not defined or for reverse proxy if defined

[javier-troconis]

or instead of completely reimplementing the function, we just change its output :

var getUrl = $.signalR.transports._logic.getUrl;
        $.signalR.transports._logic.getUrl = function(connection, transport, reconnecting, poll, ajaxPost) {
            var url = getUrl(connection, transport, reconnecting, poll, ajaxPost);
            return connection.url + url.substring(url.indexOf(connection.appRelativeUrl) + connection.appRelativeUrl.length);
        };

[aspnet-hello]

This issue has been closed as part of issue clean-up as described in https://blogs.msdn.microsoft.com/webdev/2018/09/17/the-future-of-asp-net-signalr/. If you're still encountering this problem, please feel free to re-open and comment to let us know! We're still interested in hearing from you, the backlog just got a little big and we had to do a bulk clean up to get back on top of things. Thanks for your continued feedback!

[danieldaeschle]

I have this Problem!