303

See Other

El patrón POST-Redirect-GET en acción. Formularios, confirmaciones y el arte de evitar envíos duplicados.

📝 Redirection

📋 ¿Qué narices es esto?

El código 303 See Other es el "tu formulario se envió, ahora ve a ver el resultado" de HTTP. Es la estrella del patrón POST-Redirect-GET (PRG), diseñado específicamente para evitar el clásico problema del "¿Quieres reenviar este formulario?" cuando recargas una página. Como el camarero que te dice "tu pedido está listo, ve a recogerlo a la barra".

Este código fue introducido en HTTP/1.1 para solucionar problemas del 302. Cuando envías un formulario con POST, el servidor procesa los datos y te responde con 303 + Location header apuntando a una página de confirmación. El navegador automáticamente hace un GET a esa nueva URL, y si recargas la página, solo repites el GET (seguro) en lugar del POST (peligroso).

El 303 aparece típicamente en:

  • Envío de formularios → página de confirmación
  • Operaciones de compra → página "pedido recibido"
  • APIs RESTful después de POST/PUT/DELETE
  • Registro de usuarios → página de bienvenida
  • Cualquier operación que modifica datos

🎯 Dato curioso

El 303 existe porque el 302 era ambiguo: algunos navegadores cambiaban POST a GET, otros no. El 303 clarifica: "usa GET obligatoriamente". Es HTTP siendo específico después de años de confusión.

La magia del 303 es que siempre fuerza el método GET en la redirección, sin importar qué método usaste originalmente. Esto hace que la página resultante sea "segura" para recargar, marcar como favorito o compartir. Es la diferencia entre hacer una acción y ver el resultado de esa acción.

🔧 Cómo implementar esto

🖥️ Para servidores (patrón PRG)

  1. Recibe POST/PUT/DELETE: Procesa la operación que modifica datos.
  2. Ejecuta la acción: Guarda en base de datos, envía email, etc.
  3. Responde 303 + Location: Apunta a página que muestra el resultado.
  4. Usuario hace GET automático: Ve página de confirmación.
  5. Recargar es seguro: Solo repite GET, no la operación original.

📱 Para desarrolladores frontend

  1. Diseña formularios normalmente: action="submit" method="POST".
  2. Maneja 303 automáticamente: Los navegadores lo hacen solos.
  3. Diseña páginas de confirmación: Donde aterrizará el usuario.
  4. Testea el flujo completo: POST → 303 → GET → confirmación.
  5. No muestres warnings de recarga: El 303 los elimina.

Problemas típicos con 303

  • Uso incorrecto en APIs:
    Algunas APIs devuelven 303 cuando deberían usar 201 (Created) tras un POST. El 303 es para redirigir al usuario a ver el resultado, no para indicar creación de recurso.
  • Olvidar el header Location:
    Sin el header Location, el navegador no sabe a dónde redirigir tras el 303. Es obligatorio.
  • Redirecciones en bucle:
    Si el Location apunta a una URL que vuelve a devolver 303, puedes crear un bucle infinito. Revisa la lógica de tus redirecciones.
  • Usar 303 para GET o sin modificar datos:
    El 303 está pensado para POST/PUT/DELETE, no para GET. Si no hay acción previa, no tiene sentido usarlo.

🚀 Respuesta rápida para emergencias

🔥 Si el usuario ve el formulario al recargar:
1. Asegúrate de responder con 303 tras el POST.
2. Comprueba que el header Location apunte a la página de confirmación.
3. Testea el flujo POST → 303 → GET.
⚡ Si hay bucles de redirección:
1. Revisa que la URL de Location no devuelva otro 303.
2. Testea el flujo con herramientas como redirect-checker.org.
3. Corrige la lógica para terminar en una página final (200).
🎯 Truco UX:
El 303 elimina el mensaje de "¿Quieres reenviar este formulario?" al recargar. Si sigue apareciendo, revisa tu implementación.