Re: Meta element to prevent resending post data

On Fri, 27 Jan 2012 14:09:02 -0000, Marat Tanalin | tanalin.com  
<mtanalin@yandex.ru> wrote:

> Thanks, Kornel. But the proposal is _not_ about adding something to  
> _all_ pages (that would be pointless).

Of course I've meant all relevant pages, i.e. those which use POST and  
don't use POST-redirect-GET workaround.

It's still an "all pages" kind of problem, because it requires webmasters  
to know and care about the problem, know the workaround, and to add it to  
existing (sometimes unmaintained) pages.

> The proposal is about minimizing negative user-experience impact _when_  
> server-side redirect would/should be used, but is _technically  
> impossible_.

What I'm trying to say is that there is another technical possibility of  
minimizing negative user experience, and it doesn't involve servers/pages  
at all. It's provably possible, because it's been done by at least one  
browser already.

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

No, this is a false dichotomy. There is at least a third option:

* History navigation (Back button) should always read POSTed pages from  
cache, even if pages had Cache-Control: no-cache set (this is  
RFC-compliant). This way there is no unexpected resubmission happening  
automatically, and—unless user forces browser to clear the cache—there is  
no need to ask any questions or switch to GET.

* Reload button on POSTed pages should always use POST. This way user can  
still re-submit if they want to.


This behavior gives good user experience on all POSTed pages, even if they  
don't use POST-redirect-GET or the proposed <meta> workaround. That's zero  
work for webmasters and it instantly works with all "legacy" pages.

If you can convince browser vendors to adopt that approach, it may be the  
fastest way to fix this problem for majority of users. Either solution  
requires browsers to be changed, but if browsers can fix the problem by  
default, without needing pages changed, that will make a difference much  
sooner on a bigger scale.

-- 
regards, Kornel Lesiński

Received on Friday, 27 January 2012 17:44:45 UTC