Comment empêcher les requêtes ajax de suivre les redirections à l'aide de jQuery

J'utilise les fonctions jQuery ajax pour accéder à un service Web, mais le serveur, au lieu de renvoyer une réponse avec un code d'état décrivant un problème, la requête est redirigée vers une page avec un en-tête 200, décrivant le problème. Je ne peux pas apporter de modifications à cela, donc je dois le résoudre sur le client d'une manière ou d'une autre.

Exemple: une demande va à une URL qui n'est pas trouvée, donc je reçois une redirection 302 vers un autre emplacement. Une nouvelle demande est envoyée et je reçois un 200 OK, empêchant ainsi le rappel d'erreur de se déclencher.

Existe-t-il un moyen d'empêcher la demande ajax de suivre les redirections et d'appeler à la place un rappel, de préférence la méthode d'erreur. Sinon, est-il possible de détecter si une redirection s'est produite dans le client?

Je trouve votre question intéressante, mais le problème dans son ensemble me semble plutôt un malentendu. Au moins, je vais essayer d'expliquer ma compréhension du problème.

La redirection silencieuse (transparente) fait partie de la XMLHttpRequestspécification (voir ici notamment les mots "... suivez la redirection de manière transparente ..."). La norme mentionne uniquement que l'agent utilisateur (le navigateur Web) peut empêcher ou notifier certains types de redirections automatiques, mais cela n'en fait pas partie XMLHttpRequest. Cela fait partie de la configuration du client HTTP (configuration du système d'exploitation) ou de la configuration du navigateur Web. jQuery.ajaxVous ne pouvez donc pas avoir d'option permettant d'empêcher la redirection.

Vous pouvez voir que la redirection HTTP fait partie du protocole HTTP et non de XMLHttpRequest. C'est donc à un autre niveau d'abstraction ou de la pile réseau. Par exemple, les données du XMLHttpRequestpeuvent être récupérées à partir du proxy HTTP ou du cache du navigateur local, et cela fait partie du protocole HTTP. La plupart du temps, le serveur qui fournit les données et non le client peut influencer la mise en cache.

Vous pouvez comparer l'exigence de votre question avec l'exigence d'empêcher le changement d'adresse IP du serveur Web ou le changement de la route IP pendant la communication. Toutes les choses peuvent être intéressantes dans certains scénarios, mais il y a des parties d' un autre niveau de la pile de communication et ne peuvent pas être gérées par jQuery.ajaxou XMLHttpRequest.

La XMLHttpRequestnorme dit que la configuration du client peut avoir des options qui empêchent la redirection. Dans le cas du "monde Microsoft", que je connais mieux, vous pouvez consulter fonction WinHttpSetOption qui peut être utilisée pour définir l' WINHTTP_OPTION_DISABLE_FEATUREoption avec la WINHTTP_DISABLE_REDIRECTSvaleur. Une autre façon est l'utilisation de l' WINHTTP_OPTION_REDIRECT_POLICYoption avec la WINHTTP_OPTION_REDIRECT_POLICY_NEVERvaleur. Une autre fonctionnalité que l'on peut utiliser dans Windows est la fonction WinHttpSetStatusCallback qui peut définir la fonction de rappel reçu des notifications comme WINHTTP_CALLBACK_FLAG_REDIRECT.

Il est donc possible d'implémenter vos exigences en général, mais la solution ne sera probablement pas indépendante du système d'exploitation ou du navigateur Web et ne sera pas au niveau de jQuery.ajax ou XMLHttpRequest.

Je ne crois pas que ce soit possible. La bibliothèque sous-jacente (XHR) effectue la nouvelle demande de manière transparente. Cela étant dit, ce que j'ai fait dans ces situations (généralement un type d'accord de délai d'expiration de session qui m'amène à une page de connexion) est de renvoyer un en-tête de réponse personnalisé. J'ai également configuré un gestionnaire ajax global qui vérifie la présence de cet en-tête et répond de manière appropriée lorsqu'il est présent (par exemple, en redirigeant la page entière vers l'écran de connexion).

Si vous êtes intéressé, voici le code jQuery que je dois surveiller pour cet en-tête personnalisé:

/* redirects main window when AJAX request indicates that the session has expired on the backend. */
function checkSession(event, xhr, ajaxOptions)
{
    if (xhr.readyState == 4)
    {
        if(xhr.getResponseHeader("Login-Screen") != null && xhr.getResponseHeader("Login-Screen").length)
        {
            window.location.href='sessionExpired.html'; //whatever
        }
    }
}

$(document).ajaxComplete(checkSession)

J'ai trouvé une fonction pour vérifier si votre appel a été redirigé. C'est xhr.state (): s'il est "rejeté" alors une redirection s'est produite.

Exemple avec rappel de réussite:

request.success(function(data, textStatus, xhr)
{
    if(xhr.state() == "resolved")
    {
        //no redirection
    }
    if(xhr.state() == "rejected")
    {
        //redirection
    }
});

Exemple avec rappel d'erreur:

request.error(function(xhr, textStatus)
{
    if (xhr.state() == "rejected")
    {
        //redirection
        location.href = "loginpage";
    } else
    {
        //some other error happened
        alert("error");
    }
});

Je ne peux pas ajouter à la sagesse perspicace des codeurs précédents qui ont répondu, mais j'ajouterai un cas spécifique que d'autres trouveront utile de connaître.

Je suis tombé sur cette redirection silencieuse 302 dans le contexte de SharePoint. J'ai un code client Javascript simple qui envoie un ping à un sous-site SharePoint, et s'il reçoit une réponse HTTP 200, il se déplace vers ce site, viawindow.location . S'il reçoit autre chose, il avertit l'utilisateur que le site n'existe pas.

Toutefois, dans le cas où le site existe mais que l'utilisateur n'a pas l'autorisation, SharePoint redirige silencieusement vers une page AccessDenied.aspx. SharePoint a déjà effectué la négociation d'authentification HTTP 401 au niveau du serveur / de la batterie de serveurs - l'utilisateur a accès à SharePoint. Mais l'accès au sous-site est géré, je suppose, à l'aide d'indicateurs de base de données. La redirection silencieuse contourne ma clause "else", donc je ne peux pas lancer ma propre erreur. Dans mon cas, ce n'est pas un spectacle - c'est un comportement prévisible cohérent. Mais c'était un peu surprenant, et j'ai appris quelque chose sur les requêtes HTTP dans le processus!

J'étais intéressé par la même chose et je n'ai pas pu trouver la state()méthode mentionnée par Takman et j'ai creusé un peu pour moi-même. Pour le bien des gens qui viennent ici à la recherche d'une réponse, voici mes conclusions:

Comme indiqué plusieurs fois, vous ne pouvez pas empêcher les redirections, mais vous pouvez les détecter. Selon MDN , vous pouvez utiliser responseURLla XMLHttpRequestObject, qui contiendra l'URL finale la réponse est venue, après toutes les redirections. Le seul inconvénient est qu'il n'est pas pris en charge par Internet Explorer (Edge l'a). Puisque le xhr/ jqXHRpassé dans la fonction success/ donede jquery est une extension du réel XMLHttpRequest, il devrait également y être disponible.

Je suppose que vous recevez une réponse 200 car la deuxième fois il n'y a pas de redirection, car la page 404 n'expire pas, elle est enregistrée dans le cache. C'est-à-dire que la deuxième fois que le navigateur vous donne la page dans le cache. Il y a une propriété "cache" dans la jquery ajax. http://api.jquery.com/jQuery.ajax/

Vous devriez l'écrire sur "false"

Bien qu'il ne soit pas possible de désactiver la redirection d'emplacement suivante dans XmlHttpRequests , c'est lors de l'utilisation de fetch () :

fetch('url', {redirect: manual});

Je ne sais pas si cela s'appliquera dans votre cas, mais vous pouvez écrire du code pour répondre à des codes d'état spécifiques dans la fonction AJAX -

$.ajax({
    url: '/admin/secret/data',
    type: 'POST',
    contentType: 'application/json; charset=utf-8',
    statusCode: {
        200: function (data) {
            alert('302: Occurred');
            // Bind the JSON data to the UI
        },
        401: function (data) {
            alert('401: Occurred');
            // Handle the 401 error here.
        }
    }
});

Dans les en-têtes de requête, dans le cas d'une requête ajax, vous aurez les éléments suivants

X-Requested-With    XMLHttpRequest

Par ce critère côté serveur, vous pouvez filtrer les demandes.