Si define la URL en jQuery Client, SignalR Client debería ceñirse a la URL incluso
con proxies generados.
El problema es que MVC está ejecutando la aplicación en / (root) en IIS.
SSL se agrega mediante un proxy inverso donde / se reescribe a / lo que sea
Por supuesto, signalR piensa que / signalr / hubs es, por lo tanto, correcto, pero para el navegador es / lo que sea / signalr / hubs
Debería haber la posibilidad de decirle al cliente de jquery que siempre use una determinada URL de inicio
en cualquier llamada, o al menos siempre tome la URL relativa pasada como parámetro definido en el cliente.
cuando está configurado en el cliente jquery $ .connection.hub.url = "/ lo que sea / signalr / hubs"
Negociar funciona HTTP 200, pero como resultado, la ruta de URL es la generada por
proxy de IIS AppPool con no es la URL establecida en el cliente.
Entonces, la siguiente conexión es 404 debido a que tomar la URL del concentrador / negociar la respuesta es incorrecta .
use cualquier proxy inverso (apache / nginx / etc) y asigne la aplicación IIS a otra URL
de lo que se usa directamente con IIS. hub.url solo se utilizará una vez para los proxies generados.
$(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");
});
});
negociar
el resultado de eso
conectar llamada cancelada porque URL incorrecta
Incluso con proxies no generados, el mismo problema:
var path = "../../signalr";
var connection = $.hubConnection(path, { useDefaultPath: false });
var ip = connection.createHubProxy('imageProcessor');
connection.start(function (d) {
});
La URL generada por el servidor siempre gana.
Solución de trabajo para mí:
de
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);
}
cambiado / agregado
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);
}
Funciona en / (root) si no está definido o para proxy inverso si está definido
o en lugar de volver a implementar completamente la función, simplemente cambiamos su salida:
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);
};
Este problema se ha cerrado como parte de la limpieza de problemas como se describe en https://blogs.msdn.microsoft.com/webdev/2018/09/17/the-future-of-asp-net-signalr/. Si aún tiene este problema, no dude en volver a abrir y comentar para hacérnoslo saber. Todavía estamos interesados en saber de usted, la acumulación se hizo un poco grande y tuvimos que hacer una limpieza masiva para volver a estar al tanto de las cosas. ¡Gracias por sus continuos comentarios!
¡Tengo este problema!
Comentario más útil
o en lugar de volver a implementar completamente la función, simplemente cambiamos su salida: