Why should you delete HTTP POST or DELETE, not GET?

Question

I am working on Microsoft ASP.NET MVC tutorials ending on this page

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

The following expression is made at the bottom of this page:

In general, you do not want to perform an HTTP GET operation when invoking an action that changes the state of your web application. When performing the uninstall, you want to perform an HTTP POST or, even better, an HTTP DELETE operation.

It's true? Can someone suggest a more detailed explanation of the rationale for this statement?

Edit

Wikipedia claims the following:

Some methods (for example, HEAD, GET, OPTIONS, and TRACE) are defined as safe, which means that they are intended only to extract information and should not change the server state.

In contrast, methods such as POST, PUT, and DELETE are for actions that can cause side effects either on the server

Answer 1

John Skeet's answer is a canonical answer. But: suppose you have a link:

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

and googlebot goes and indexes your page? What happens next?

Answer 2

GET usually does not contain side effects - in other words, it does not change state. This means that the results can be cached, bookmarks can be safely, etc.

From HTTP 1.1 RFC 2616

Artists should be aware that the software represents the user in their interactions over the Internet and should be careful to be aware of any actions that they might take that could be of unexpected significance to themselves or to others.

In particular, the convention was that the GET and HEAD methods SHOULD NOT have the significance of accepting anything other than search. These methods should be considered "safe." This allows the user agents to present other methods, such as POST, PUT, and DELETE, in a special way so that the user is created aware that it is possible that an unsafe action is being requested.

Naturally, it is impossible to make sure that the server does not generate side effects as a result of executing a GET request; in fact, some dynamic resources consider that a feature. An important difference is that the user did not request side effects, so they cannot be held liable for them.

Answer 3

In addition to the purist problems around the idempotent, there is a practical side: spiders / bots / searchers, etc. will follow the hyperlinks. If you have the delete action as a hyperlink that executes GET, Google can have fun deleting all your data. See " The Spider of Doom .

Messaging is not a risk.

Answer 4

Please see my answer here . This applies equally to this issue.

• Prefetch: Many web browsers will use prefetch. What does it mean that it will load the page before you click on the link. Assuming you click on this link later.
• Bots: There are several bots that crawl and index the Internet for information. They will only issue GET requests. You do not want to remove something from the GET request for this reason.
• Caching: GET HTTP requests should not change state, and they should be idempotent. Idempotent means that issuing a request once or issuing it several times gives the same result. That is, there are no side effects. For this reason, GET HTTP requests are tightly cached.
• The HTTP standard says that : the HTTP standard says that every HTTP method for. Several programs are built to use the HTTP standard, and they assume that you will use it the way you suggested. That way, you will have undefined behavior from the set if you don't follow.

Answer 5

Another example.

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

This will delete the article if you are logged in and have the correct rights. If your site accepts comments, for example, and the user passes this link as an image; So:

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

Then, when you yourself, as the admin user, view comments on your site, the browser will try to extract this image by sending a request to this URL. But since you are logged in while the browser does this, the article will be deleted.

You may not even notice without looking at the source code, since most browsers show nothing if they cannot find the image.

Hope this makes sense.

Answer 6

In addition to spiders and requests that should be idempotent, there is also a security issue with requests for receive. Someone can easily send their users an email using

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

in the text, and the browser will happily go and try to access the resource. Using POST is not a cure for such things (since you can easily compile a message in javascript), but it is a good start.

Answer 7

About this topic (using HTTP methods), I recommend reading this blog post: http://blog.codevader.com/2008/11/02/why-learning-http-does-matter/

This is actually the opposite problem: why not use POST when the data is not changed.

Answer 8

Another problem with GET is that the command is sent to the address bar of the browser. Therefore, if you refresh the page, you again issue a command, whether it is “delete the last material”, “send the order” or similar.

Answer 9

Let's say we have an application for Internet banking, and we go to the transfer page. A registered user decides to transfer 10 US dollars to another account.

Pressing the submit button redirects (as a GET request) to https://my.bank.com/users/transfer?amount=10&destination=23lk3j2kj31lk2j3k2j

But the Internet connection is slow and / or the server is busy, so after clicking the submit button, the new page slowly loads.

The user gets frustrated and starts hitting F5 (refresh page) violently. Guess what will happen? More than one transfer may occur, possibly omitting the user account.

---

Now, if the request is made as POST (or something else than GET), the first F5 (update page), the user will make a browser, gently ask: "Are you sure you want to do this?" It may have side effects [bla bla bla] ... "