ERR_TOO_MANY_REDIRECTS: Dos cosas que están cada una configurada correctamente

La propia descripción de Chromium es admirablemente clara: “Intentar cargar una URL resultó en demasiadas redirecciones”. El navegador siguió una cadena de redirecciones, la cadena no terminó, y en algún momento dejó de seguir.

El número en el que se detiene viene del Fetch Standard, que es inequívoco al respecto: si el recuento de redirecciones de la solicitud es 20, entonces devuelve un error de red. Así que veinte saltos, y entonces la página que ve es la del navegador, no la suya.

Lo que hace que este error merezca su propio artículo no es el mecanismo, que es obvio. Es que un bucle de redirección casi nunca es una sola cosa rota. Son dos cosas, cada una comportándose exactamente como está configurada, en desacuerdo sobre algo que ninguna de ellas puede ver.

Lo clásico, que es un desacuerdo sobre HTTPS

Usted coloca una CDN o un equilibrador de carga delante de su aplicación. Termina TLS, que es su función, y reenvía la solicitud a su origen sobre HTTP plano, que es normal y generalmente deliberado.

Su aplicación tiene una regla que dice: si esta solicitud no es HTTPS, redirige a HTTPS. También correcto, y en un servidor sin proxy delante, exactamente lo correcto.

Ahora júntelos. El navegador pide https://example.com. La CDN termina TLS y reenvía http://example.com a su aplicación. Su aplicación ve HTTP plano, hace lo sensato, y responde “redirige a https://example.com”. El navegador obedece. La CDN termina TLS y reenvía HTTP. Veinte veces, y luego el navegador se rinde.

Ningún componente está mal configurado por sí solo. La aplicación está imponiendo HTTPS. El proxy está terminando TLS. El bug vive en el espacio entre ellos, por lo que ambos equipos pueden mirar su propia configuración y concluir correctamente que está bien.

La solución es que la aplicación debe dejar de hacer la pregunta equivocada. En lugar de “era esta solicitud HTTPS”, debe preguntar “era la solicitud original HTTPS”, que es lo que el encabezado X-Forwarded-Proto existe para indicarle. La mayoría de los marcos de trabajo tienen una configuración para confiar en ese encabezado de un proxy conocido, y generalmente está desactivada por defecto por una buena razón: un encabezado que cualquiera puede establecer no es evidencia a menos que sepa quién lo estableció.

La misma forma, tres veces más

Una vez que ve el patrón, los otros bucles comunes tienen la misma historia con sustantivos diferentes.

www contra el ápice. Una capa redirige example.com a www.example.com. Otra, agregada después o por alguien más, redirige www de vuelta al ápice. Cada regla es defendible. El par es un bucle.

La barra diagonal final. Su servidor web redirige /about a /about/. El enrutador del marco de trabajo redirige /about/ a /about. Ambos están imponiendo una forma canónica. Están en desacuerdo sobre cuál es canónica.

El bucle de inicio de sesión, que es el que llega a usuarios reales. La aplicación no ve una sesión válida, así que redirige a /login. La página de inicio de sesión verifica la cookie de sesión, cree que está iniciada, y redirige a la aplicación. Una y otra vez.

Vale la pena detenerse en ese último, porque la causa suele ser que la cookie no persiste en lugar de que las reglas de redirección sean incorrectas: una cookie Secure en una página servida por HTTP, una cookie SameSite=None sin Secure, una cookie establecida en www.example.com siendo leída en example.com, o un navegador configurado para rechazar cookies de terceros en un contexto incrustado. La lógica de redirección es correcta en toda su extensión. Está actuando sobre una sesión que nunca persistió.

Débil

"Su página de inicio de sesión está atrapada en un bucle. Solo sigue recargándose".

Mejor

ERR_TOO_MANY_REDIRECTS en /login, solo en una ventana privada, solo después de cerrar sesión e iniciar sesión nuevamente. Funciona en mi ventana normal. La cadena es /app → /login → /app.

Por qué este es inusualmente difícil de ver desde el interior

Un bucle de redirección a menudo es específico de un estado en el que no está.

Si es el bucle de inicio de sesión, su cookie ya está establecida y funcionando, por lo que el sitio se comporta perfectamente para usted y entra en bucle para cualquiera que llegue nuevo. Si es una regla de www que alguien agregó la semana pasada, solo entra en bucle para personas que escribieron el otro nombre de host. Si depende de una cookie que el navegador rechaza, se reproduce en una ventana privada y en ningún otro lugar.

Y la verificación obvia la pierde. curl -I https://example.com le muestra una respuesta, que será una 301 que se ve perfectamente razonable con un encabezado Location. Nada sobre ella dice que la cadena nunca termina. Lo que quiere es seguir toda:

curl -sIL -o /dev/null -w '%{url_effective} %{http_code}\n' https://example.com
curl -sI https://example.com | grep -i '^location'

O abra la pestaña Red con Conservar registro marcado, que es la única forma de mantener los saltos anteriores en lugar de borrarlos en cada navegación. La cadena es el diagnóstico: lea el encabezado Location en cada paso y generalmente puede ver las dos reglas en desacuerdo dentro de tres saltos.

Una cosa sobre 301 que vale la pena saber antes de usarla

Un 301 no es simplemente un 302 que significa más.

MDN es específica sobre una consecuencia que sorprende a la gente: en el Fetch Standard, un agente de usuario que recibe un 301 en respuesta a un POST usa GET para la solicitud redirigida. Su envío de formulario se convierte en un GET, el cuerpo desaparece, y el fallo no se parece en nada a un problema de redirección. Si necesita que se conserve el método, 308 es el que prohíbe cambiarla.

La regla general es más aburrida y más útil: use 302 o 307 mientras aún está trabajando en cuál es la URL canónica, y use 301 o 308 cuando esté seguro. Una redirección permanente es una afirmación, y las afirmaciones son mucho más fáciles de hacer que de retirar.

Qué sacar de esto

ERR_TOO_MANY_REDIRECTS significa veinte saltos sin un final, y el final falta porque dos reglas están en desacuerdo, no porque una esté rota.

Así que no comience buscando la regla rota. Comience listando cada capa a la que se le permite emitir una redirección: la CDN, el equilibrador de carga, el servidor web, el marco de trabajo, la aplicación, y lo que sea que un complemento agregó sin decirle a nadie. Luego lea la cadena, un encabezado Location a la vez, y encuentre los dos que están en desacuerdo.

Y cuando no se reproduce para usted, esa es información en lugar de un obstáculo. Significa que el bucle depende de un estado que ya ha pasado, y la forma más rápida de llegar a él es una ventana privada, un nombre de host diferente, o la imagen completa de lo que el navegador realmente recibió de parte de alguien para quien está fallando en este momento.