[whatwg] page refresh and resubmitting POST state

On Mon, 15 Jun 2009, Mike Wilson wrote:
> > 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.
> 
> As I pointed out in a followup to Jonas's mail: 
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019937.html 
> doing PRG with current technology has the drawback of losing the page 
> state. This can be patched back again by adding query params to the URL 
> but this isn't good for all scenarios (see below).

I think generally speaking if the user experience is being tweaked to this 
level, then it's best to just do a JS-based Web app rather than relying on 
multiple page loads from the server. So instead of navigating the entire 
browsing context, just do an XHR POST, update the UI accordingly, and 
pushState() to get the new UI into the history.


> > On Sun, 24 May 2009, Aryeh Gregor wrote:
> > > 
> > > 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.
> 
> Adding data to the URL makes sense in some scenarios, but not in others. 
> Often the application needs to hold on to state shared by a sequence of 
> pages in the same browsing context, but at the same time not wanting 
> this state to be shared with the same set of pages in another browsing 
> context. This rules out cookie-based state as this is shared by all 
> browsing contexts in the user agent.

That's what the Web Storage sessionStorage API is for.


> > > 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.
> 
> For server-oriented webapps a solution that doesn't rely on script is 
> preferred. This means the server should be able to transmit 
> browsing_context-scoped state to the client and have it automatically 
> sent back on any following request. Something like 
> browsing_context-oriented cookies.

If we want to support this, then that would be a new feature for Cookies, 
I guess.

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

Received on Thursday, 9 July 2009 17:55:29 UTC