Re: Meta element to prevent resending post data

Old CMS is just one of possible usecases. Quoting myself from another message in this thread:

http://lists.w3.org/Archives/Public/public-html/2012Jan/0172.html :

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

28.01.2012, 00:48, "Ryosuke Niwa" <rniwa@webkit.org>:
> I don't think we should be adding a new HTML feature just to work-around the limitation of an old CMS you happen to use.  The correct fix is to replace your CMS with a more sensible CMS that correctly overrides HTTP headers.
>
> - Ryosuke
> On Jan 27, 2012 6:10 AM, "Marat Tanalin | tanalin.com" <mtanalin@yandex.ru> wrote:
>> 27.01.2012, 04:56, "Kornel Lesiński" <kornel@geekhood.net>:
>>> On Thu, 26 Jan 2012 22:05:04 -0000, Marat Tanalin | tanalin.com
>>> <mtanalin@yandex.ru> wrote:
>>>
>>>>  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.
>>>
>>> I think this is a quality of implementation issue.
>>>
>>> For example Opera does not ask this question at all— Back button never
>>> re-sends POST (this is what RFC 2616 §13.13[1] suggests), and Reload
>>> always re-sends (since this is an explicit instruction from the user
>>> already, there is no need to ask).
>>>
>>> I find this to be quite good behavior. There are no annoying requesters at
>>> all, Back button navigation is always smooth, and it works with all pages
>>> already.
>>>
>>> It may be easier to convince other browser vendors to implement history
>>> and caching according to RFC 2616 §13.13, rather than to define a
>>> workaround and add it to all pages.
>>>
>>> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13
>>>
>>> --
>>> regards, Kornel Lesiński
>>
>> Thanks, Kornel. But the proposal is _not_ about adding something to _all_ pages (that would be pointless).
>>
>> The proposal is about minimizing negative user-experience impact _when_ server-side redirect would/should be used, but is _technically impossible_.
>>
>> The proposed meta element would be used exactly and _only_ on pages that normally would use (self-)redirect. Resending POST data always (without user confirmation) is even worse since it would result in sending multiple copies of same comment or feedback message much more likely than if browser needs confirmation from user.
>>
>> So it's not browser-implementation issue at all, it should be controllable by web-developer on _per-page basis_ -- same way as server-side redirect is controlled by web-developer on _per-page basis_, not by browser.
>>
>> It's frequent situation when a POST-requested page do look and do function same way as GET-requested page with same URL, with only one distinction: refreshing the page resends POST data resulting in undesired adding multiple copies of comments/messages/etc. So there are just two options in such situations:
>>
>> 1. put up with negative impact caused by inability for user to refresh page and/or potential resending of POST data when user refreshes the page;
>>
>> 2. use the proposed meta element to prevent resending POST data when server-side (self-)redirect would be used if it was technically available.

Received on Friday, 27 January 2012 21:48:15 UTC