Perché si dovrebbe eliminare utilizzando un HTTP POST o DELETE, piuttosto che GET?

Question

Ho lavorato attraverso esercitazioni ASP.NET MVC di Microsoft, finendo a questa pagina

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

La seguente dichiarazione è fatta verso la parte inferiore di questa pagina:

  

In generale, non si desidera eseguire un'operazione HTTP GET quando si invoca un'azione che modifica lo stato della vostra applicazione web. Quando si esegue un'operazione di eliminazione, si desidera eseguire un HTTP POST, o meglio ancora, un HTTP operazione di cancellazione.

E 'vero? Chiunque può offrire una spiegazione più dettagliata per la logica alla base di questa affermazione?

Modifica

Wikipedia afferma quanto segue:

  

Alcuni metodi (ad esempio, HEAD, GET, OPZIONI e TRACE) sono definiti come sicuro, il che significa che sono destinati solo per il recupero delle informazioni e non dovrebbe cambiare lo stato del server.

     

Al contrario, metodi come POST, PUT e DELETE sono destinati ad azioni che possono causare effetti collaterali sia sul server

Answer 1

La risposta di Jon Skeet è la risposta canonica. Ma: Supponiamo di avere un link:

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

e il google-bot arriva e gli indici la pagina? Cosa succede allora?

Answer 2

GET è convenzionalmente privo di effetti collaterali - in altre parole, non cambia lo stato. Ciò significa che i risultati possono essere memorizzati nella cache, i segnalibri possono essere effettuate in modo sicuro, ecc.

HTTP 1.1 RFC 2616

  

Implementors dovrebbero essere consapevoli che il   software rappresenta l'utente nel loro   le interazioni su Internet, e   deve fare attenzione per consentire all'utente di   essere a conoscenza di eventuali azioni che potrebbero   prendere che può avere un inaspettato   significato per sé o per altri.

     

In particolare, la convenzione è stata   stabilito che il GET e HEAD   metodi non dovrebbe avere il   importanza di compiere un'azione altro   di recupero. Questi metodi dovrebbero   essere considerato "sicuro". Questo permette all'utente   agenti per rappresentare altri metodi,   come POST, PUT e DELETE, in un   modo speciale, in modo che l'utente è composta   consapevole del fatto che un possibilmente   si chiede situazioni di pericolo.

     

Naturalmente, non è possibile   assicurarsi che il server non lo fa   generare effetti collaterali come risultato di   l'esecuzione di una richiesta GET; infatti,   alcune risorse dinamici ritengono che una   caratteristica. La distinzione importante   qui è che l'utente non ha richiesto   gli effetti collaterali, in modo quindi non può   essere ritenuti responsabili per loro.

Answer 3

A parte le questioni purista intorno essere idempotente, c'è un lato pratico: ragni / bot / crawler ecc seguiranno collegamenti ipertestuali. Se avete la vostra azione "cancella" come un collegamento ipertestuale che fa un GET, allora Google può allegramente eliminare tutti i dati. Vedere " Il Ragno di Doom ".

Con i messaggi, questo non è un rischio.

Answer 4

Un altro esempio ..

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

Questo eliminerà l'articolo se si è connessi e disporre dei privilegi di destra. Se il tuo sito accetta commenti per esempio, e un utente sostiene che collegamento come un'immagine; in questo modo:

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

Poi, quando si te stesso come l'utente admin venire a sfogliare i commenti sul vostro sito il browser tenterà di recuperare l'immagine inviando fuori una richiesta in tal URL. Ma perché si è connessi, mentre il browser sta facendo questo l'articolo otterrà cancellato.

Si può anche non notare, senza guardare il codice sorgente maggior parte dei browser mostrano solito nulla se non riesce a trovare un'immagine.

La speranza che abbia un senso.

Answer 5

Si prega di vedere la mia risposta qui . Si applica anche a questa domanda.

  

  
• Prefetch: Un sacco di browser userà prelettura. Che significa   che caricherà una pagina prima di   clicca sul link. anticipando che   si clicca su questo link più tardi.
  
• Motori di ricerca: Ci sono diversi bot che la scansione e indice di Internet per la   informazione. Emetterà GET solo   richieste. Se non si desidera eliminare   qualcosa da una richiesta GET per questo   ragione.
  
• Caching: GET HTTP richieste non sono tenuti a cambiare stato e dovrebbero essere idempotente. Idempotente significa che   emettere una richiesta volta, o che lo rilascia   più volte dà lo stesso risultato.   Cioè Non ci sono effetti collaterali. Per   questo motivo GET richieste HTTP sono   strettamente legato alla cache.
  
• HTTP standard dice : Lo standard HTTP dice ciò che ogni metodo HTTP è   per. Diversi programmi sono costruiti per   utilizzare lo standard HTTP, e assumono   che si intende utilizzare come sei   suppone. Così si avrà   comportamento non definito da un gran numero di   programmi casuali se non seguono.
  

Answer 6

Oltre a ragni e le richieste di dover essere idempotente c'è anche un problema di sicurezza con richieste GET. Qualcuno può facilmente inviare agli utenti un messaggio e-mail con il

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

nel testo e il browser sarà lieto di andare avanti e cercare di accedere alla risorsa. Utilizzando POST non è una cura per queste cose (come si può mettere insieme un post modulo in javascript abbastanza facilmente), ma è un buon inizio.

Answer 7

A proposito di questo argomento (utilizzo metodi HTTP), vi consiglio di leggere questo post del blog: http://blog.codevader.com/2008/11/02/why-learning-http-does-matter/

Questo è in realtà il problema opposto: perché non utilizzare POST quando i dati non viene modificato.

Answer 8

Diciamo che abbiamo un programma di internet banking e visitiamo la pagina di trasferimento. L'utente connesso sceglie di trasferire $ 10 a un altro account.

Cliccando sulle redirect pulsante Invia (come una richiesta GET) per https: //my.bank.com/users/transfer?amount=10&destination=23lk3j2kj31lk2j3k2j

Ma la connessione internet è lenta e / o il server (s) è (sono) occupato in modo dopo aver colpito il pulsante di invio della nuova pagina si sta caricando lento.

L'utente si sente frustrato e comincia a colpire F5 (refresh della pagina) furiosamente. Indovinate che cosa accadrà? Più di un trasferimento si verifica eventualmente svuotare account dell'utente.

---

Ora, se la domanda è presentata come POST (o qualsiasi altra cosa che GET) il primo F5 (refresh della pagina) che l'utente farà il browser sarà gentilmente chiedere "sei sicura di volerlo fare? Può avere effetti collaterali [ bla bla bla] ... "

Answer 9

Oltre a tutte le ottime ragioni di cui sopra qui, GET richieste potrebbero essere registrati dal server del destinatario, come ad esempio nel access.log. Se si invia attraverso i dati sensibili come le password nella richiesta, otterranno registrati in testo semplice.

Anche se sono hashing / salato per l'archiviazione sicura DB, una violazione (o qualcuno guardando sopra la spalla del ragazzo IT) li potrebbe rivelare. Tali dati dovrebbero andare nel corpo POST.

Answer 10

Un altro problema con GET è che il comando va a barra degli indirizzi del browser. Quindi, se si aggiorna la pagina, si emette nuovamente il comando, sia esso "cancella ultima roba", "invia l'ordine" o simili.