javascript - mostrar - Cómo evitar que las solicitudes ajax sigan los redireccionamientos usando jQuery

ejecutar funcion javascript antes de cargar la pagina

Question

Utilizo las funciones jQuery ajax para acceder a un servicio web, pero el servidor, en lugar de devolver una respuesta con un código de estado que describe un problema, la solicitud se redirige a una página con un encabezado 200, que describe el problema. No puedo hacer ningún cambio en esto, así que tengo que resolverlo en el cliente de alguna manera.

Ejemplo: una solicitud va a alguna URL que no se encuentra, por lo que recibo una redirección 302 a otra ubicación. Se envía una nueva solicitud, y recibo un 200 OK, evitando así que la devolución de llamada de error se dispare.

¿Existe alguna forma de evitar que la solicitud de Ajax siga los redireccionamientos y, en su lugar, invocar una devolución de llamada, preferiblemente el método de error? Alternativamente, ¿es posible detectar si ha ocurrido un redireccionamiento en el cliente?

Answer 1

En los encabezados de solicitud en el caso de la solicitud de ajax, tendrá lo siguiente

X-Requested-With XMLHttpRequest

Según este criterio del lado del servidor, puede filtrar las solicitudes.

Answer 2

Encontré una función para verificar si su llamada ha sido redirigida. Es xhr.state (): si es "rechazado", se produce una redirección.

Ejemplo con devolución de llamada exitosa:

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

Ejemplo con devolución de llamada de error:

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

Answer 3

Encuentro su pregunta interesante, pero el problema en conjunto me parece más un malentendido. Al menos intentaré explicar mi comprensión del problema.

La redirección silenciosa (transparente) es la parte de la especificación XMLHttpRequest (consulte here especialmente las palabras "... sigue de forma transparente la redirección ..."). La mención estándar solo menciona que el agente de usuario (el navegador web) puede evitar o notificar ciertos tipos de redirecciones automáticas, pero no es parte de XMLHttpRequest . Es la parte de la configuración del cliente HTTP (configuración del sistema operativo) o la configuración del navegador web. Entonces jQuery.ajax no puede tener ninguna opción donde pueda evitar la redirección.

Puede ver que la redirección HTTP es parte del protocolo HTTP y no una parte de XMLHttpRequest . Por lo tanto, está en el otro nivel de abstracción o la pila de red. Por ejemplo, los datos de XMLHttpRequest se pueden recuperar del proxy HTTP o del caché del navegador local, y es parte del protocolo HTTP. En su mayoría, el servidor que proporciona los datos y no el cliente puede influir en el almacenamiento en caché.

Puede comparar el requisito de su pregunta con el requisito de evitar el cambio de la dirección IP del servidor web o el cambio de la ruta IP durante la comunicación. Todas las cosas pueden ser interesantes en algunos escenarios, pero hay partes de otro nivel de la pila de comunicación y no pueden ser gestionadas por jQuery.ajax o XMLHttpRequest .

El estándar XMLHttpRequest dice que la configuración del cliente puede tener opciones que impidan la redirección. En el caso de "Microsoft world", que mejor conozco, puede mirar la función WinHttpSetOption que se puede usar para configurar la opción WINHTTP_OPTION_DISABLE_FEATURE con el valor WINHTTP_DISABLE_REDIRECTS . Otra forma es el uso de la opción WINHTTP_OPTION_REDIRECT_POLICY con el valor WINHTTP_OPTION_REDIRECT_POLICY_NEVER . Una característica más que se puede usar en Windows es la función WinHttpSetStatusCallback que puede establecer la función de devolución de llamada recibida algunas notificaciones como WINHTTP_CALLBACK_FLAG_REDIRECT .

Por lo tanto, es posible implementar sus requisitos en general, pero la solución probablemente no sea independiente del sistema operativo o del navegador web y no esté en el nivel de jQuery.ajax o XMLHttpRequest .

Answer 4

Estaba interesado en lo mismo y no pude encontrar el método state() mencionado por Takman e hice un poco de investigación por mi cuenta. Por el bien de las personas que aparecen aquí en busca de una respuesta, estos son mis hallazgos:

Como se indicó varias veces, no puede evitar los redireccionamientos, pero puede detectarlos. Según MDN , puede usar responseURL del XMLHttpRequestObject , que contendrá la URL final de la que proviene la respuesta, después de todos los redireccionamientos. La única advertencia es que no es compatible con Internet Explorer (Edge lo tiene). Como el xhr / jqXHR pasó a la función de success / done de jquery es una extensión del XMLHttpRequest real, también debería estar disponible allí.

Answer 5

No creo que sea posible. La biblioteca subyacente (XHR) realiza la nueva solicitud de forma transparente. Una vez dicho esto, lo que he hecho en estas situaciones (generalmente un tipo de trato de tiempo de espera de sesión que me lleva a una página de inicio de sesión) es devolver un encabezado de respuesta personalizado. También he configurado un controlador global de ajax que verifica la presencia de ese encabezado y responde apropiadamente cuando está presente (por ejemplo, redireccionando toda la página a la pantalla de inicio de sesión).

En caso de que esté interesado, aquí está el código jQuery que tengo que mirar para ese encabezado personalizado:

/* 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)

Answer 6

No estoy seguro de si esto se aplicará en su caso, pero puede escribir código para responder a códigos de estado específicos en la función 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.
}
}
});

Answer 7

No puedo agregar nada a la perspicaz sabiduría de los codificadores anteriores que respondieron, pero agregaré un caso específico que otros puedan encontrar útil para conocer.

Me encontré con esta redirección silenciosa 302 en el contexto de SharePoint. Tengo un código de cliente Javascript simple que hace ping a un subsitio de SharePoint, y si recibe una respuesta HTTP de 200, se reubica en ese sitio, a través de window.location . Si recibe algo más, le da al usuario un aviso de que el sitio no existe.

Sin embargo, en el caso donde el sitio existe pero el usuario no tiene permiso, SharePoint redirige silenciosamente a una página AccessDenied.aspx. SharePoint ya ha realizado el protocolo de enlace de autenticación HTTP 401 a nivel de servidor / granja: el usuario tiene acceso a SharePoint. Pero el acceso al subsitio se maneja, supongo, usando banderas de bases de datos de algún tipo. La redirección silenciosa pasa por alto mi cláusula "else", por lo que no puedo arrojar mi propio error. En mi caso, esto no es un show-stopper, es un comportamiento predecible constante. Pero fue un poco sorprendente, ¡y aprendí algo sobre las solicitudes HTTP en el proceso!

Answer 8

Supongo que recibes una respuesta de 200 porque la segunda vez que no hay redirección, porque la página 404 no caduca, se guarda en la caché. Es decir, la segunda vez que el navegador le da la página en el caché. Hay una propiedad "caché" en el ajax jquery. http://api.jquery.com/jQuery.ajax/

Debes escribirlo en "falso"