[whatwg] page refresh and resubmitting POST state

[Ian Hickson]

On Fri, 22 May 2009, Mike Wilson wrote:
>
> I can see some usefulness for adding a couple of subjects
> to the HTML5 spec:
> - how browsers should handle page refresh, in particular
>   for pages received through POST (= do you want to 
>   resubmit?)

Done.


> - potentially add constructs to help users avoid the above
>   resubmit question (this could f ex be through providing
>   some support for PRG = Post-Redirect-Get, or other)

On Fri, 22 May 2009, Jonas Sicking wrote:
> 
> This is already supported. If you use a 302 or 303 redirect in response 
> to a POST this will redirect to a uri that the UA then GETs. Refresing 
> that page will simply result in a new GET to the second uri.

On Fri, 22 May 2009, Mike Wilson wrote:
> 
> With current technology there are limitations to the usefulness of PRG 
> (f ex in multi-window/tab scenarios), so I am asking if it is within 
> HTML5's scope to explore improved or alternative solutions to the 
> "resubmit" problem.

On Sat, 23 May 2009, Kornel Lesinski wrote:
> 
> As far as I understand the "resubmit problem" is just sign of poor 
> implementation that violates SHOULD NOT in the HTTP RFC: 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13
> 
> This problem can be elegantly solved within existing standards: Opera 
> simply goes back in history without resubmitting forms, and resubmits 
> only when user clicks standard Reload button (or F5, etc.)

On Sat, 23 May 2009, Mike Wilson wrote:
>
> I was thinking about the resubmit problem in a general
> context, specifically how browsers could make it possible
> for web authors to create POSTing pages that avoids giving 
> the dreaded "do you want to resubmit" question at all,
> independent of operation.

Just do a redirect like Jonas describes, instead of returning the page 
contents directly. You can even redirect to the same URL.


> [...] Defining some support in the browser could replace or simplify 
> parts of these solutions.

I'm sure people are open to suggestions. I wouldn't worry about whether 
they're in scope for HTML5 or not; if they're not, we can always redirect 
you to the right group.


On Sun, 24 May 2009, Aryeh Gregor wrote:
> 
> The problem is that since HTTP is stateless, you don't have the data 
> available to show a confirmation page.  For instance, suppose a user on 
> Wikipedia moves a page to a new name.  That user is presented with a 
> page saying "You have successfully moved X to Y."  If this confirmation 
> page is the result of a POST, then trying to go back in the history (in 
> Firefox, at least) will risk presenting the annoying "Do you want to 
> resubmit?" dialog.  But if you use a 303 (practically, 302), then how do 
> you know what X and Y are in the new request?
> 
> One workaround is to just stick the info in the query string of the GET.  
> One problem with this is that it makes it easy to trick users into 
> thinking they've just done something alarming: you can link to 
> confirmmove.php?page1=Main_Page&page2=Main_Page_ON_WHEELS, and the user 
> will think they actually just moved the page (the software told them 
> so!).  Another problem is that sometimes there's way too much data to 
> fit into a query string.  For instance, in MediaWiki you can move a page 
> with all its subpages.  There might be hundreds or even thousands of 
> these, and a success/failure message is printed for each, with the 
> reason for failure if appropriate.  This might be too long to fit in a 
> GET.

Just stick the data into the query parameters, including the user's ID, 
then sign the query parameters, and when serving the page, check the 
signature and check the user's ID matches the cookie.


> A similar workaround would be to use cookies.  This is nicer than the 
> previous method, but has the potential to break confusingly if the user 
> takes several similar actions at once (e.g., moving a number of pages at 
> once in multiple tabs).

Using sessionStorage can be used to work around this somewhat, at least 
in AJAX apps.


On Sun, 24 May 2009, Kornel Lesinski wrote:
> 
> Is it possible for HTML 5 spec to say that browsers may re-send PUT 
> without asking? (and that authors should use PUT only when resending is 
> not going to cause this problems).

This would be something for the HTTP spec, I believe. HTML5 just mentions 
asking for reloads when the method is not idempotent.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'