[whatwg] page refresh and resubmitting POST state

[Mike Wilson]

Ian Hickson wrote:
> 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.

Nice, thanks.

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

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

The information I've compiled goes outside the subject
of this thread, so I'll explore further parts of the state 
handling problem in a separate mail thread titled 
"html5 state handling: overview and extensions".

> 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.
With current technology a common solution is to add a unique id
to the URL that points to a storage area on the server where 
the full state is stored. The same id is then used on all pages 
throughout the navigation sequence, and the id could be said
to represent the browsing context (ie window or tab) as each
browsing context will get a different id, mapping to state for
that browsing context.

For this scenario it would be better if the id parameter was 
not part of the URL, because:
- the id parameter adds no meaning to the URL
- the id parameter maps to an internal and transient data
  structure on the server and not to an entity
- the above two bullets mean we don't want it in bookmarks
- coming back with an old URL (with an old id) requires
  handling cases like recreating an expired data structure, or 
  handling conflicts if our id is now allocated to another 
  user

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

I'll include this in my state handling overview in the new
thread.

Best regards
Mike Wilson