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 18:09:02 +0400
To: Kornel Lesiński <kornel@geekhood.net>
Cc: public-html@w3.org
Message-Id: <649831327673342@web147.yandex.ru>
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 14:09:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:43 GMT