Re: Meta element to prevent resending post data

2012/1/27 Marat Tanalin | tanalin.com <mtanalin@yandex.ru>:
> 27.01.2012, 21:00, "Tab Atkins Jr." <jackalmage@gmail.com>:
>> If you can get the same page back with a GET request, then it
>> shouldn't have been a POST in the first place.  That's an abuse of
>> request semantics, usually just so the page maintains a "pretty URL".
>
> Since my point is likely misunderstood, let's consider an example for additional clarity.
>
> We have a no-so-advanced CMS that technically _can't_ make server-side redirects.
>
> A site based on this CMS has a page that contains a form to add messages, and list of messages added earlier. The form's @action attribute contains same URL as the page that contains the form itself. Since each POST request from the form adds new message, the form _must_ be sent via POST request, not GET request -- it's well-known best-practice approach that GET request should not modify or add something to database (except, well, for visit counters).
>
> So POST here cannot be replaced with GET at all.

If your CMS is dumb enough that it can't do redirects directly, it can
always serve the page with a <meta http-equiv="refresh" content="0;
url=http://example.com/">.  This kinda sucks, but the CMS apparently
kinda sucks anyway, so it seems fitting.

(I'm quite confused, though - what CMS *can* add things to a
server-side database, but *can't* issue a redirect?  This is trivial
to do in every server-side language I know of.)

~TJ

Received on Friday, 27 January 2012 17:19:00 UTC