Stephen Pattern:
idempotent? I don’t know about the word specifically, but the page you linked included the quote:
" If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method should be GET. Many database searches have no visible side-effects and make ideal applications of query forms.
- -
If the service associated with the processing of a form has side effects (for example, modification of a database or subscription to a service), the method should be POST.
"
A great example is that Google, of all companies, misuses GET a lot. I can craft a URL that you can click on (triggering a GET) that changes your google language to Gaelic until you clear your google cookie or find a way to change it back.
Until you clear the cookie or change your settings, every time you visit google with that browser, the page will be in Gaelic and all your results will be Gaelic-weighted.
The method that gets called is NOT idempotent - it has a lasting effect, therefor it should only be possible to trigger it via a POST, partially to prevent people from crafting that URL into their page and having it triggered by javascript or something so that just visiting a page that isn’t related to google at all will change your google settings without your knowledge.
This is just one example, completely unabashedly stolen from a Slashdot comment I stumbled upon a long time ago(yes, he included a demo link, and yes, it really did change your language).
That’s a very low-importance example though… but people put databases online behind web interfaces that allow you to modify data from your browser. what happens if you’re logged into one in one browser window, and visit a malicious website that attempts to send a GET request w/ a SQL statement that adds a new SQL user? That isn’t possible if you make it only use POST. Granted, they could craft one and POST it, but most browsers put a lot more restrictions on how you can POST without warnings and other issues. Sure you could check referrers, blah blah blah… the bottom line is, a malicious GET can come from a LOT of sources, a malicious POST is harder to get at. (You can embed misleading links in IM, email, .url files/shortcuts, etc… POST has to be triggered from within the browser session in all browsers that I know of. No, it isn’t a huge massive security hole(usually), just a small annoying one that could be almost completely avoided by following the standard!)