Redirecciones 301, 302, 307 y 308: cuáles conservan el método de la solicitud

Qué es

RFC 9110 define cuatro códigos que significan «el recurso está en la URI indicada en Location» y uno que apunta a otro lugar:

• 301 Moved Permanently: por razones históricas, un agente de usuario PUEDE cambiar POST por GET en la solicitud de seguimiento. Cacheable heurísticamente.
• 302 Found: temporal; se aplica la misma observación sobre el cambio de POST a GET. No cacheable heurísticamente.
• 303 See Other: el cliente realiza una recuperación (GET o HEAD) de otro recurso; es el patrón post-redirect-get para formularios.
• 307 Temporary Redirect: el agente de usuario NO DEBE cambiar el método. No cacheable heurísticamente.
• 308 Permanent Redirect: NO DEBE cambiar el método. Cacheable heurísticamente. RFC 9110 señala que es mucho más reciente que sus homólogos y que puede no estar reconocido en todas partes.

RFC 9110 también describe lo que hace un cliente al seguir una redirección: sustituir la URI de destino, descartar los campos generados automáticamente y específicos de la conexión, considerar la posibilidad de descartar Authorization y Cookie, cambiar el método solo cuando el código de estado lo indique, y eliminar los encabezados de contenido si el método pasó a ser GET. Los clientes deberían detectar bucles; una especificación anterior sugería un límite de cinco saltos.

Por qué importa

Una API que responde a un POST con 301 o 302 no puede saber si el cliente reenviará el cuerpo con POST o emitirá un GET; la página de MDN sobre 302 recomienda usar 307 en su lugar para evitar que los agentes de usuario modifiquen la solicitud. Las cachés pueden reutilizar los códigos permanentes sin consultar al origen, de modo que un 301 o un 308 erróneo sigue enviando a los clientes al lugar equivocado incluso después de corregirlo.

Cómo aplicarlo

• Recurso trasladado de forma definitiva y puede llegar cualquier método: 308. Solo importa el tráfico GET y HEAD y los clientes antiguos: 301.
• Desvío temporal en el que el método y el cuerpo deben conservarse (mantenimiento, canary): 307.
• Tras un POST de formulario exitoso desde el navegador: 303 a la página de resultado, para que una recarga no reenvíe el formulario.
• Recurso retirado sin sucesor: 410, no una redirección a la página de inicio.
• Establecer un Cache-Control explícito en las redirecciones permanentes para acotar la duración de un error.
• Probar con curl -v -L -d '' URL y observar el método en cada salto: curl cambia a GET tras 301, 302 y 303 a menos que se indique --post301, --post302 o --post303. -X POST -L no puede mostrar el cambio, porque curl documenta que un método fijado con -X se usa para todas las solicitudes.

Trampas

Redirigir un endpoint POST http:// a HTTPS con 301 pierde o reemite los cuerpos según el cliente. Las cadenas de redirecciones multiplican los round trips y el comportamiento de la caché. Los clientes suelen descartar Authorization cuando una redirección lleva a otro host, tal como RFC 9110 les indica que consideren; curl documenta que retiene las credenciales frente a otros nombres de host a menos que se indique --location-trusted, de modo que una solicitud autenticada redirigida puede llegar sin su token.