http-status-codes - solucion - status code 200

Después de un POST, ¿debería hacer una redirección 302 o 303?

Question

Un escenario común para una aplicación web es redirigir después de un POST que modifica la base de datos. Como redirigir al objeto de base de datos recién creado después de que el usuario lo crea.

Parece que la mayoría de las aplicaciones web usan 302 redireccionamientos, pero 303 parece ser lo correcto según la especificación si desea que la URL especificada en el redireccionamiento se obtenga con GET. Técnicamente, con un 302, se supone que el navegador debe buscar la url especificada con el mismo método con el que se obtuvo la url original, que sería POST. La mayoría de los navegadores no hacen eso sin embargo.

302 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3

303 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4

Entonces, ¿debería usar 302 o 303?

Answer 1

Al proporcionar la ubicación de un nuevo recurso creado por una solicitud POST, 201 ("Creado") es una respuesta adecuada.

HTTP / 1.1: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2

Protocolo de publicación de Atom: http://tools.ietf.org/html/rfc5023#section-5.3

Sin embargo, esto significa que un navegador web no redireccionará a la nueva URL; el usuario debe seguir un enlace para acceder al nuevo elemento (este enlace se puede proporcionar en el cuerpo de la respuesta, así como en el encabezado de la ubicación).

Answer 2

Depende
Se agregaron 303 y 307 respuestas en HTTP1.1.
Por lo tanto, los agentes del cliente que cumplen estrictamente con HTTP1.1 RFC deberían estar bien con una respuesta 303.
Pero puede haber agentes que no son totalmente conformes o son compatibles con HTTP1.0 y no podrán manejar el 303.
Por lo tanto, para asegurarme de que la mayoría de las implementaciones del cliente puedan manejar la respuesta de su aplicación, creo que 302 es la opción más segura.
Extracto de RFC-2616 :

Nota: Muchos agentes de usuario anteriores a HTTP / 1.1 no entienden el estado 303. Cuando la interoperabilidad con dichos clientes es una preocupación, el código de estado 302 puede utilizarse en su lugar, ya que la mayoría de los agentes de usuario reaccionan a una respuesta 302 como se describe aquí para 303.

Answer 3

El correcto es 303.

Lo uso y no he encontrado ningún problema de compatibilidad con los UA más nuevos que Netscape 4 (1998, publicado hace 17 años ).

Si usa 302, se arriesga a que UA vuelva a enviar POST a la nueva URL en lugar de cambiar a GET.

Sin embargo, si le preocupan los clientes HTTP / 1.0 (que no son compatibles con los fantasmas y probablemente no podrán acceder a su página de todos modos), debe incluir HTML con un enlace a la nueva página en el cuerpo de la respuesta 303 ( los servidores web como Apache ya lo hacen).

Answer 4

En la mayoría de los lenguajes del lado del servidor, el mecanismo de redirección predeterminado usa 302:

• Java response.sendRedirect(..) usa 302
• ASP.NET response.Redirect(..) usa 302
• El header("Location: ..") PHP header("Location: ..") usa 302
• RoR redirect_to usa 302
• etc.

Así que preferiría esto, en lugar de establecer el estado y los encabezados manualmente.

Answer 5

En teoría, usted (y todo el mundo) debería estar usando 303 como ha notado. Pero también, la mayoría de los navegadores reaccionan a un 302 como deberían reaccionar a un 303. Entonces, en general, parece que no importará si envía 302 o 303. En el enlace que proporcionó para la especificación 303, hay una nota interesante :

Nota: Muchos agentes de usuario anteriores a HTTP / 1.1 no entienden el estado 303. Cuando la interoperabilidad con dichos clientes es una preocupación, el código de estado 302 puede utilizarse en su lugar, ya que la mayoría de los agentes de usuario reaccionan a una respuesta 302 como se describe aquí para 303.

Es importante tener en cuenta los agentes de usuario pre -HTTP / 1.1, así que tal vez esto fue importante hace un tiempo, pero no creo que sea el caso ahora.

Entonces, en definitiva, depende de usted (podría apostar lo que quiera que los navegadores no cambien su comportamiento contra los estados 302 nunca, por temor a romper el internet para sus usuarios).