Need to manually set connection.appRelativeUrl when backend sits behind reverse proxy

[dalager]

When using websockets the appRelativeUrl is always taken from the negotiate response.

However, when the backend sits behind a reverse proxy the relativeUrl is not known by the backend.

From the frontend perspective the endpoint sits at mydomain.com/subfolder/signalr

But the negotiate response sets the relative url as i.e. /signalr which is correct from the backend's perspective.

So after a succesful request to mydomain.com/subfolder/signalr/negotiate the connect goes to mydomain.com/signalr/connect?transport....

It looks as if it is not possible to override the appRelativeUrl from the JavaScript client without patching the jquery.signalr.js file with a new config setting.

Or is there another way to approach this?

[WilliamBZA]

A workaround of configuring an IIS rewrite rule is possible here until the connection.appRelativeUrl is addressed:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <outboundRules>
                <rule name="Update Url property" preCondition="JSON" enabled="true" stopProcessing="true">
                    <match filterByTags="None" pattern="\&quot;Url\&quot;:\&quot;(.+?)\&quot;" />
                    <conditions>
                        <add input="{URL}" pattern="(.*)/api/" />
                    </conditions>
                    <action type="Rewrite" value="&quot;Url&quot;:&quot;{C:1}{R:1}&quot;" />
                </rule>
                <preConditions>
                    <preCondition name="JSON">
                        <add input="{URL}" pattern="/api/messagestream/negotiate" />
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="application/json" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
    </system.webServer>
</configuration>

[jpierson]

I ran into this recently as well and would like to see a better way of dealing with this built into SignalR. Is there are reason why the server should be telling the client the path that the client must already clearly know about when initially negotiating the connection?

[jpierson]

@WilliamBZA, that workaround is what I've gone with for now but for others that may stumble across this who may not be familiar with ARR you should expect to modify the configuration posted above in order to work for your specific situation. More plainly put "api/messagestream" and other elements of @WilliamBZA's example are hard coded values that apply only to that URL and not to something generic to SignalR.

[guidoffm]

This mapping works for me:

      <outboundRules>
        <rule name="Update Url property" preCondition="JSON" enabled="true" stopProcessing="true">
            <match filterByTags="None" pattern="\&quot;Url\&quot;:\&quot;(.+?)\&quot;" />
            <conditions>
                <add input="{URL}" pattern="(.*)/signalr/" />
            </conditions>
            <action type="Rewrite" value="&quot;Url&quot;:&quot;{C:1}{R:1}&quot;" />
        </rule>
        <preConditions>
            <preCondition name="JSON">
                <add input="{URL}" pattern="/signalr/negotiate" />
                <add input="{RESPONSE_CONTENT_TYPE}" pattern="application/json" />
            </preCondition>
        </preConditions>
       </outboundRules>

[WojcikMike]

I created a post in here:
http://forums.asp.net/t/2095053.aspx?SignalR+and+reverse+proxy
To raise the awareness of this issue. Yet there was only 1 response. No more feedback so far.

[jpjerkins]

The rewrite rule only works if there's only one SignalR endpoint being reverse proxied with a given appRelativeUrl (like the default, "/SignalR"). If multiple endpoints are being reverse proxied, then each endpoint needs to use a different appRelativeUrl, and a rewrite rule will be needed for each. I work in an enterprise environment, and this is affecting our architecture.

Please consider this one vote in favor of getting this fixed.

[Roustalski]

I'm not sure if this helps with context, RE: Forum post by @WojcikMike

The appRelativeUrl is referenced within a method getURL, which is tied to this bug: #2953

I'm thinking about forking the client repo just to remove the appRelativeUrl as this bug is a show stopper for us.

[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!