create_update.delete_object always needs a confirmation page

[czajnik@…]

I've found one thing annoying about delete_object() view. In my application I prefer to use HREFs (as opposed to forms) for object deletion, together with JavaScript-based confirmation dialogs. This makes delete_object() useless for me, as I want it to delete the object upon GET request, without aby further confirmation page.

Could it be possible to add additional param like no_confirmation (with False as default for backward compatibility) ?

Changing

if request.method == 'POST':

to

if no_confirmation or request.method == 'POST':

would do the trick then.

[Russell Keith-Magee]

GET requests should never modify the server, so server-modifying methods (such as object deletion) shouldn't be deployed behind a GET request.

[Przemyslaw Wegrzyn <czajnik@…>]

What is the reason for this statement? I mean - has it technical or philosophycal background?

I see nothing wrong in GET requets changing the server-side state, actually it is not uncommon (e.g. webmail app marking the mail as read, upon displaying the mail, to mention the most trivial case).

Assuming that I do need POST requests to delete objects, I have to add some artifical JavaScript code to submit a POST request (as stated before, I use plain links for deletion).

[pytechd@…]

Because GET requests should always be safe. Some browsers, extensions, ISPs, caches, etc can pre-fetch information from links. There was a big problem a while back when Google introduced their caching mechanisms client-side, where the extension would end up pre-fetching "delete" links. "POST" forms are never pre-fetched. See also the HTTP 1.1 Spec, Section 9: ​http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html. (Small quip: restyle an INPUT to look like a link. You don't need JavaScript!)