Re: Meta element to prevent resending post data

27.01.2012, 21:00, "Tab Atkins Jr." <jackalmage@gmail.com>:
> On Thu, Jan 26, 2012 at 2:05 PM, Marat Tanalin | tanalin.com
> <mtanalin@yandex.ru> wrote:
>
>> šHello.
>>
>> šCurrently, if a page is result of POST request, trying to refresh it in browser do result in browser message confirming that user really wants to refresh page that will result in resending form data that is already sent. If user do not want to resend data, it ends up with complete _impossibility_ to refresh page without manual focusing location bar and pressing Enter key.
>>
>> šSo it would be nice to have a META element to prevent resending POST form-data when user refreshes page that is result of POST request.
>>
>> šA possible syntax of such META element:
>>
>> šš š<meta http-equiv="x-http-post-options" content="noresend" />
>>
>> šWhen page has such META element, pressing "Refresh" button of browser (or keyboard key like F5) would result in just _reloading_ page as if the page was regular page loaded by regular GET request.
>>
>> šOf course, it's usually good practice to just make server-side redirect via "Location" HTTP header (self-redirect in particular) after POST request, however unfortunately this is _not always technically possible_. Sending arbitrary HTTP headers is trivial task for modern script languages like PHP, but unfortunately is not an option at all for some self-made CMS written in compiled language like Delphi that a company has _anyway_ no resources to rework in, say, next 10 years.
>>
>> šIn such situations, the proposed META element would be quite useful to achieve same effect as server-side self-redirect provides: prevent accidental resending form data when user actually just wants to refresh page as if it was regular GET-requested page and wasn't result of POST request. There could be also server response header of same name ("x-http-post-options: noresend") for same purpose.
>
> 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.

Received on Friday, 27 January 2012 17:13:24 UTC