Сведения об ошибке подключения SignalR с помощью Longpolling

В jquery.signalR-1.1.3.js функция ошибки длинного опроса возвращает текст ответа вместо всего объекта jqXHR.

Есть ли хороший способ определить в обработчике ошибок концентратора, что на самом деле представляет собой ошибка?

$.connection.hub.error(function (error) {
            system.log('SignalR error: ' + error);
        });

Я использовал атрибут SignalR [Authorize], чтобы вернуть HTTP 403 Forbidden, когда в соединении должно быть отказано, но в моем клиенте все, что я получаю, — это страница ответа страницы ошибки IIS в объекте ошибки, потому что SignalR не передает обратно весь объект ответа, см. ниже : $(instance).triggerHandler(events.onError, [data.responseText]);. Это происходит в замкнутом цикле, потому что SignalR просто пытается повторно подключиться несколько сотен/тысяч/несколько раз, пока не истечет время ожидания повторного подключения.

Я хотел бы иметь возможность сказать, что это 403 или любой другой пользовательский код состояния, который я мог бы вернуть, а затем позволить моему приложению ответить соответствующим образом... в этом случае прекратите попытки повторного подключения и выйдите из системы.

Вот обработчик ошибок транспорта с длительным опросом:

error: function (data, textStatus) {
// Stop trying to trigger reconnect, connection is in an error state
// If we're not in the reconnect state this will noop
window.clearTimeout(reconnectTimeoutId);
reconnectTimeoutId = null;

if (textStatus === "abort") {
    connection.log("Aborted xhr requst.");
    return;
}

// Increment our reconnect errors, we assume all errors to be reconnect errors
// In the case that it's our first error this will cause Reconnect to be fired
// after 1 second due to reconnectErrors being = 1.
reconnectErrors++;

if (connection.state !== signalR.connectionState.reconnecting) {
    connection.log("An error occurred using longPolling. Status = " + textStatus + ". " + data.responseText);
    $(instance).triggerHandler(events.onError, [data.responseText]);
}

// Transition into the reconnecting state
transportLogic.ensureReconnectingState(instance);

// If we've errored out we need to verify that the server is still there, so re-start initialization process
// This will ping the server until it successfully gets a response.
that.init(instance, function () {
    // Call poll with the raiseReconnect flag as true
    poll(instance, true);
});

}

И код авторизации концентратора на стороне сервера

public override bool AuthorizeHubConnection(Microsoft.AspNet.SignalR.Hubs.HubDescriptor hubDescriptor, Microsoft.AspNet.SignalR.IRequest request)
{
    // If we want them to connect, return true, else false
    // Asp.NET will return a 403 if we return false here
    return false;
}

Возникает пара вопросов...

1. Почему signalR снова соединяется в такой тугой петле?
2. Есть ли лучший способ управления жизненным циклом подключения signalR на основе авторизации подключения к концентратору?