¿Por qué HTTP no tiene redirección POST?

En HTTP 1.1, en realidad hay un código de estado ( 307 ) que indica que la solicitud debe repetirse utilizando el mismo método y la publicación de datos .

Como han dicho otros, hay un potencial de uso indebido aquí, lo cual puede ser la razón por la que muchos marcos se adhieren a 301 y 302 en sus abstracciones. Sin embargo, con comprensión adecuada y uso responsable, debería poder lograr lo que está buscando.

Tenga en cuenta que de acuerdo con la W3.org spec , cuando METHOD no es HEAD o GET , los agentes de usuario deben avisar al usuario antes de volver a ejecutar la solicitud en la nueva ubicación. También debe proporcionar una nota y un mecanismo de reserva para el usuario en caso de que los antiguos agentes de usuario no estén seguros de qué hacer con un 307.

Usando este formulario:

<form action="Test307.aspx" method="post">
    <input type="hidden" name="test" value="the test" />
    <input type="submit" value="test" />    
</form>

Y tener Test307.aspx simplemente devuelve 307 con la ubicación: enlace , Chrome 13 y Fiddler confirman que "test = the test" está publicado a Google. Por supuesto, la respuesta adicional es un 405 ya que Google no permite el POST, pero muestra la mecánica.

Para obtener más información, consulte Lista de códigos de estado HTTP y W3.org spec .

  

307 Redireccionamiento temporal (desde HTTP / 1.1) En esta ocasión, la solicitud   debe repetirse con otro URI, pero las solicitudes futuras pueden seguir utilizándose   el URI original. 2 A diferencia de 303, el método de solicitud no debe   Se modificará al volver a emitir la solicitud original. Por ejemplo, un POST   la solicitud debe repetirse utilizando otra solicitud POST.

Encontré una buena explicación en esta página aquí .

  

Las situaciones más simples en la WWW son transacciones "idempotentes", es decir,   Aquellos que pueden repetirse sin causar daño alguno. Estos son   Por lo general, las transacciones "GET", ya sea porque son de recuperación   referencias directas a URL (por ejemplo, href = o src = atributos en HTML),   o porque son envíos de formularios utilizando el método GET. Redirigiendo   una transacción de ese tipo es sencilla y no se hacen preguntas:   el cliente recibe la respuesta de redirección, incluida una ubicación:   encabezado que especifica la nueva URL, y el cliente reacciona a ella por   reemitiendo la transacción a la nueva URL. Hay una diferencia   entre los diferentes códigos de estado 30x asociados con estos   redirecciones en su cacheabilidad implícita, pero por lo demás son   básicamente similar (301 y 302) en respuesta a las solicitudes GET.

     

Las transacciones POST son diferentes, ya que se definen como, en   principio, no idempotente (como ordenar una pizza, emitir un voto o   lo que sea) y no debe repetirse arbitrariamente.

     

Las especificaciones del protocolo HTTP están diseñadas para tomar esta distinción   en cuenta: el método GET se define como inherentemente idempotente,   mientras que el método POST se define como, al menos potencialmente,   no idempotente; las especificaciones requieren una serie de precauciones para   Ser tomada por los agentes del cliente (como los navegadores) para proteger a los usuarios.   contra (inadvertidamente) reenviar una transacción POST que tuvieron   no pretende, o enviar un POST en un contexto que no lo harían   he querido.

Aunque no soy un fanático de restringir técnicamente a los usuarios para evitar que causen un caos no deseado o que hagan un daño no deseado a sus aplicaciones, puedo entender el punto y tiene sentido.

GET (y algunos otros métodos) se definen como 'SEGUROS' en la especificación http ( RFC 2616 ):

  

9.1.1 Métodos seguros

     

Los implementadores deben tener en cuenta que el software representa al usuario en   sus interacciones a través de Internet, y deben tener cuidado de permitir   el usuario debe ser consciente de cualquier acción que pueda tomar que pueda tener una   significado inesperado para ellos mismos u otros.

     

En particular, se ha establecido la convención de que el GET y   Los métodos de HEAD NO DEBEN tener el significado de tomar una acción   Aparte de la recuperación. Estos métodos deben considerarse "seguros".   Esto permite a los agentes de usuario representar otros métodos, como POST, PUT   y BORRAR, de una manera especial, para que el usuario tenga conocimiento de la   hecho de que se está solicitando una acción posiblemente insegura.

     

Naturalmente, no es posible garantizar que el servidor no lo haga   generar efectos secundarios como resultado de realizar una solicitud GET; en   De hecho, algunos recursos dinámicos consideran que una característica. Lo importante   La distinción aquí es que el usuario no solicitó los efectos secundarios, por lo que   por lo tanto, no puede ser responsabilizado por ellos.

Esto significa que una solicitud GET nunca debe tener consecuencias graves para el usuario, más allá de ver algo que no desea ver, pero una solicitud POST podría cambiar un recurso que es importante para ellos o para otras personas.

Aunque esto ha cambiado con JavaScript, tradicionalmente había diferentes interfaces de usuario: los usuarios podían activar solicitudes GET haciendo clic en los enlaces, pero tendrían que rellenar un formulario para activar una solicitud POST. Creo que los diseñadores de HTTP estaban dispuestos a mantener la distinción entre métodos seguros y no seguros.

También creo que nunca debería ser necesario redirigir a un POST. Cualquier acción que deba llevarse a cabo se puede realizar presumiblemente llamando a una función dentro del código del lado del servidor, o si tiene que suceder en un servidor diferente, en lugar de enviar un redireccionamiento que contenga una URL para que el navegador publique, el servidor podría realizar una solicitud a ese servidor en sí mismo, actuando como un proxy para el usuario.