307

Temporary Redirect

El 302 pero sin ambigüedades. Redirecciones temporales que respetan el método HTTP original.

🔄 Redirection

📋 ¿Qué narices es esto?

El código 307 Temporary Redirect es el "ve a esa dirección, pero hazlo exactamente como me preguntaste" de HTTP. Es la versión clarificada y mejorada del 302, diseñada para eliminar las ambigüedades sobre qué método HTTP usar en la redirección. Como el GPS que te dice "gira a la derecha" pero especificando si vas caminando, en bici o en coche.

La diferencia clave es que el 307 preserva el método HTTP original. Si haces POST al endpoint original, el navegador hará POST al destino de la redirección. Si haces PUT, seguirá siendo PUT. El 302 era ambiguo: algunos navegadores cambiaban POST a GET, otros no. El 307 dice "haz exactamente lo mismo que ibas a hacer, pero allá".

El 307 aparece típicamente en:

  • APIs que mueven endpoints temporalmente
  • Balanceadores de carga redirigiendo tráfico
  • Servicios en mantenimiento con respaldo temporal
  • CDNs redirigiendo a servidores más cercanos
  • Migraciones temporales de infraestructura

🎯 Dato curioso

El 307 existe porque el 302 causaba inconsistencias. Los navegadores interpretaban diferente si cambiar POST a GET. El 307 clarifica: "mantén el método original, siempre". Es HTTP siendo específico después de años de confusión.

La belleza del 307 es su predictibilidad. No hay ambigüedad sobre qué pasará: el navegador hará exactamente la misma petición que iba a hacer, pero a la nueva dirección. Es la diferencia entre "ve por ahí" y "ve por ahí, del mismo modo que venías". Perfecto para APIs RESTful donde el método HTTP tiene significado semántico.

🔧 Cómo implementar esto

🖥️ Para servidores (redirección temporal)

  1. Identifica necesidad temporal: Endpoint movido por poco tiempo.
  2. Responde 307 + Location: Apunta a la nueva ubicación temporal.
  3. Preserva método HTTP: El navegador mantiene POST, PUT, DELETE.
  4. Incluye Cache-Control: Para controlar cuánto cachear.
  5. Usuario repite petición: Mismo método, nueva URL.

📱 Para desarrolladores frontend

  1. Maneja 307 automáticamente: Los navegadores lo hacen solos.
  2. Prepara para redirecciones: En llamadas a APIs.
  3. Considera el cuerpo de la petición: Se reenviará tal como está.
  4. Testea con métodos no-GET: POST, PUT, DELETE.
  5. Monitorea en Network tab: Para ver el flujo completo.

Problemas típicos con 307

  • Olvidar el header Location:
    Sin el header Location, el navegador no sabe a dónde redirigir. Es obligatorio en 307.
  • Redirecciones en bucle:
    Si la URL de destino vuelve a devolver 307, puedes crear un bucle infinito. Revisa la lógica de tus redirecciones.
  • No controlar el cache:
    Sin Cache-Control, los clientes pueden repetir la petición más veces de lo necesario. Usa max-age para limitarlo.
  • Confusión con 302:
    Algunos desarrolladores siguen usando 302 para redirecciones temporales, pero solo el 307 garantiza que el método HTTP no cambia.

🚀 Respuesta rápida para emergencias

🔥 Si el navegador no redirige:
1. Comprueba que el header Location está presente y correcto.
2. Verifica que el código de estado es 307.
3. Testea con diferentes métodos HTTP.
⚡ Si hay bucles de redirección:
1. Revisa la lógica de tus reglas de redirección.
2. Usa herramientas como redirect-checker.org.
3. Asegúrate de que la URL destino no devuelva otro 307.
🎯 Truco para APIs:
El 307 es ideal para APIs RESTful porque mantiene el método y el cuerpo de la petición. Úsalo siempre que quieras mover temporalmente un endpoint sin romper integraciones.