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 20:40:22 +0400
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Kornel Lesiński <kornel@geekhood.net>, public-html@w3.org
Message-Id: <49721327682422@web7.yandex.ru>
27.01.2012, 19:57, "Julian Reschke" <julian.reschke@gmx.de>:
> On 2012-01-27 15:09, Marat Tanalin | tanalin.com 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.
>>  ...
>
> Well, it's something new that would need to be implemented.
>
> Kornel's point seems to be that the whole thing wouldn't be needed if
> the browsers did the "right" thing automatically.
>
> Best regards, Julian

Problem with Kornel's point is that there is no only "right" thing to do here. Some pages do require POST data to be sent and will show different content when accessed via GET request, while another pages will show same content for both POST request and GET request except for that POST request adds another copy of comment or something else to site's database each time request is performed. For former pages, POST data should be resent on refresh, for latter ones -- on the contrary, should not.

It's of web-developer responsibility, not of browser, to decide whether POST data should be resent on a particular page. Usually this is solved by making server-side redirect. The proposed meta element is just sort of redirect replacement.
Received on Friday, 27 January 2012 16:41:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:29 UTC