[whatwg] page refresh and resubmitting POST state

[Mike Wilson]

Jonas Sicking wrote:
> On Sat, May 23, 2009 at 4:29 AM, Mike Wilson 
> <mikewse at hotmail.com> 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.
> 
> Can you explain more in detail why PRG doesn't solve this problem? My
> understanding is that the "do you want to resubmit" UI comes up when
> sites *doesn't* use PRG, and the UI would disappear if they had used
> it.

PRG solves the immediate problem of getting rid of the 
resubmission dialog, but creates another problem: loss 
of page state. Sometimes this is not a problem, but 
often when you work with web applications, it is.

So, an author will have to choose between two evils; 
either go with plain POST, which will keep the page 
state but cause resubmission questions, or go PRG
which will eliminate the questions but lose page state.

At first, the loss of page state in PRG may seem 
solvable by tucking a handle to that data inside the
URL, but this scheme gets complex and breaks down when 
you want to separate multi-window operations (and are 
facing New Window in IE or Duplicate Tab in Chrome), or 
when you want bookmarkable URLs.

There is a whole spectrum of possible improvements that
could help out in these cases, but they all involve
defining something about state.

F ex, plain POST pages have to ask their question
because they don't know if the page state they carry is
"harmless" data needed only for telling the server what
to display, or if it is something that will trigger an
undoable action. Usually the page state is a mix of
both these. So, one improvement could be making it 
possible to specify (per input element) if the state is
for redisplay or for action. Then pressing Refresh could
safely send the redisplay state without asking the
resubmission question, and leave out the action state.
(Assuming we want the semantics of the Refresh button to
be Redisplay and not Redo.)

At the other end of the spectrum we could help authors
using PRG, to associate state with their GET pages 
without adding to the URL.
This could f ex be solved by giving the server the
possibility to associate some state with each page 
load (delivered in headers or body), which is then
sent back to the server (in header) on any request that
leaves that page, including page refresh.
Web storage is touching on the same problem, mentioning 
the limitations of cookies, but AFAICT depends on 
script and has no transparent UA/server transfer.

These are just examples of constructs that could be
possible. I hope I have provided enough information to
determine if this is indeed a subject that is relevant
for HTML5.

Best regards
Mike