¿Por qué debe eliminar utilizando un HTTP POST o DELETE, en lugar de GET?

Question

He estado trabajando a través de tutoriales MVC ASP.NET de Microsoft, para terminar en esta página

http://www.asp.net/learn/mvc/ tutorial-32-cs.aspx

La siguiente declaración se realiza hacia la parte inferior de esta página:

  

En general, usted no desea llevar a cabo una operación HTTP GET al invocar una acción que modifica el estado de su aplicación web. Cuando se realiza una eliminación, desea realizar un HTTP POST, o mejor aún, un HTTP operación de eliminación.

¿Es esto cierto? ¿Alguien puede ofrecer una explicación más detallada de las razones detrás de esta afirmación?

Editar

Wikipedia indica lo siguiente:

  

Algunos métodos (por ejemplo, HEAD, GET, opciones y TRACE) se definen como seguro, lo que significa que están destinados sólo para la recuperación de información y no deben cambiar el estado del servidor.

     

Por el contrario, los métodos tales como POST, PUT y DELETE están destinados para las acciones que puede provocar efectos secundarios, ya sea en el servidor

Answer 1

La respuesta de Jon Skeet es la respuesta canónica. Pero: Suponga que tiene un enlace:

href = "\myApp\DeleteImportantData.aspx?UserID=27"

y el Google-bot viene e indexar su página? ¿Qué ocurre entonces?

Answer 2

GET es convencionalmente libre de efectos secundarios - en otras palabras, que no cambia el estado. Eso significa que los resultados pueden almacenar en caché, los marcadores se pueden hacer con seguridad, etc.

el HTTP 1.1 RFC 2616

  

Los ejecutores deben ser conscientes de que la   software representa el usuario en su   interacciones a través de Internet, y   debe tener cuidado para que el usuario pueda   estar al tanto de cualquier acción que pudiera   tomar que puede tener un inesperado   importancia a sí mismos oa otros.

     

En particular, la convención ha sido   establecido que el GET y HEAD   métodos no deberían tener el   importancia de tomar una acción distinta   de recuperación. Estos métodos deben   ser considerado "seguro". Esto permite al usuario   agentes para representar otros métodos,   tales como POST, PUT y DELETE, en una   de manera especial, para que el usuario se hace   consciente del hecho de que un posible   se solicita la acción insegura.

     

Naturalmente, no es posible   asegúrese de que el servidor no se   generar efectos secundarios como resultado de   realizar una petición GET; de hecho,   algunos recursos dinámicos consideran que una   característica. La distinción importante   aquí es que el usuario no ha solicitado   los efectos secundarios, por lo tanto, no puede   ser responsables de ellos.

Answer 3

Además de los problemas en torno a ser puristas idempotente, hay un punto de vista práctico: arañas / bots / rastreadores etc seguirá los hipervínculos. Si usted tiene su acción "eliminar" como un hipervínculo que hace un GET, entonces Google puede eliminar alegremente todos sus datos. Ver " La araña de la condenación ".

Con los mensajes, esto no es un riesgo.

Answer 4

Otro ejemplo ..

http://example.com/admin/articles/delete/2

Esto eliminará el artículo si está en el sistema y tener los privilegios adecuados. Si su sitio acepta comentarios por ejemplo, y que un usuario envía enlace como una imagen; de esta manera:

<img src="http://example.com/admin/articles/delete/2" alt="This will delete your article."/>

A continuación, cuando usted mismo como el usuario administrador llegado a navegar a través de los comentarios en su sitio el navegador intentará obtener esa imagen mediante el envío de una petición a la URL. Pero debido a que está en el sistema, mientras que el navegador está haciendo esto, el artículo se eliminan.

Es posible que ni siquiera notar, sin mirar el código fuente como la mayoría de los navegadores muestran planteo nada si no puede encontrar una imagen.

La esperanza que tiene sentido.

Answer 5

Véase mi respuesta aquí . Se aplica igualmente a esta pregunta.

  

  
• Prefetch: Una gran cantidad de navegadores web que permitirá la obtención previa. Lo que significa   que va a cargar una página antes   clic en el enlace. Previendo que   deberá hacer clic en ese enlace más adelante.
  
• Motores de búsqueda: Hay varios robots que escanean y el índice de la Internet para   información. Sólo se emitirá GET   peticiones. Usted no quiere eliminar   algo de una petición GET para este   la razón.
  
• Almacenamiento en caché: HTTP GET no se supone que las solicitudes para cambiar de estado y deben ser idempotent. Idempotente significa que   emitir una solicitud de una vez, o que lo emite   varias veces da el mismo resultado.   Es decir. No hay efectos secundarios. por   esta razón GET peticiones HTTP son   estrechamente ligada a la memoria caché.
  
• HTTP estándar por lo que dice : El estándar HTTP dice lo que cada método HTTP es   para. Varios programas están diseñados para   utilizar el estándar HTTP, y asumen   que lo va a usar como eres   supone. Por lo que tendrá   un comportamiento indefinido a partir de una serie de   programas al azar si no siguen.
  

Answer 6

Además de las arañas y las peticiones que tienen que ser idempotente también hay un problema de seguridad con las peticiones GET. Alguien puede enviar fácilmente a sus usuarios un e-mail con

<img src="http://yoursite/Delete/Me" />

en el texto y el navegador estará feliz de estar de acuerdo y tratar de acceder al recurso. El uso de correos no es una cura para este tipo de cosas (como se puede armar un post forma en javascript con bastante facilidad), pero es un buen comienzo.

Answer 7

Sobre este tema (el uso de métodos HTTP), recomiendo leer esta entrada del blog: http://blog.codevader.com/2008/11/02/why-learning-http-does-matter/

Esto es en realidad el problema opuesto: ¿por qué no usar POST cuando se cambia ningún dato.

Answer 8

Supongamos que tenemos una aplicación de banca por Internet y visitar la página de la transferencia. El usuario que ha entrado elige para transferir $ 10 a otra cuenta.

Al hacer clic en el botón de envío redirecciones (como una petición GET) a https: //my.bank.com/users/transfer?amount=10&destination=23lk3j2kj31lk2j3k2j

Sin embargo, la conexión a Internet es lenta y / o el servidor (s) es (son) ocupada así que después de golpear el botón de enviar la nueva página se carga lenta.

El usuario se frustra y comienza a golpear F5 (actualizar la página) furiosamente. Adivinar lo que va a pasar? Más de una transferencia se producirá posiblemente vaciar la cuenta del usuario.

---

Ahora bien, si la solicitud se realiza como POST (o cualquier otra cosa que GET) el primer F5 (actualizar la página), el usuario hará que el navegador va suavemente pregunta "¿estás seguro de que quieres hacer eso? Puede tener efectos secundarios [ bla bla bla] ... "

Answer 9

Además de las solicitudes de todas las excelentes razones mencionadas aquí, obtener podrían ser registrados por el servidor receptor, como en el access.log. Si envía a través de los datos sensibles como contraseñas en la solicitud, que van a ser registrados como texto sin formato.

Incluso si se hash / sal durante el almacenamiento seguro DB, una violación (o alguien que mira sobre el hombro del chico de TI) podría revelar ellos. Tales datos deben ir en el cuerpo POST.

Answer 10

Otro problema con GET es que el comando va a la barra de direcciones del navegador. Así que si actualiza la página, se emite el comando de nuevo, ya sea "borrar la última cosas", "enviar la orden" o similar.