W3C home > Mailing lists > Public > public-html@w3.org > January 2012

Re: Meta element to prevent resending post data

From: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>
Date: Fri, 27 Jan 2012 21:47:47 +0400
To: Tab Atkins Jr. <jackalmage@gmail.com>
Cc: public-html@w3.org
Message-Id: <77961327686467@web65.yandex.ru>
27.01.2012, 21:18, "Tab Atkins Jr." <jackalmage@gmail.com>:

> 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.

<meta http-equiv="refresh"> forces page to be reloaded and thus leads to extra-delay due to another HTTP-request.

On the contrary, my proposed solution has no this shortcoming. Moreover, extra-request delay is also peculiar of server-side self-redirect solution, so my proposed solution could be useful not just for bad CMSes, but also for wide range of situations where POST-requested page is identical (as for content) to same page after self-redirect, and making another request has no purpose other than preventing resending POST data during page refresh.

> (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.)

It's not my CMS (I personally use PHP and can implement anything I want.) But, unfortunately, there are CMSes that are written in compiled language Delphi and has insuperable architectural limitations such as inability to send arbitrary response headers (such limitations are odd for me too).
Received on Friday, 27 January 2012 17:48:28 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:19 UTC