[whatwg] push/replaceState interacting with POSTs

[Aryeh Gregor]

On Fri, Jul 16, 2010 at 1:13 PM, Justin Lebar <justin.lebar at gmail.com> wrote:
> We have a minor issue using replaceState in Bugzilla that we may or
> may not want to fix up in the spec.
>
> When you make a change to a bug, Bugzilla POSTs you from a nice-looking URL, say
>
>    https://bugzilla.mozilla.org/show_bug.cgi?id=577720 ,
>
> to
>
>    https://bugzilla.mozilla.org/process_bug.cgi
>
> This is annoying because it breaks refresh and bookmarking, even
> though process_bug.cgi is logically displaying the same page that
> show_bug.cgi was previously displaying.
>
> Apparently fixing this the Right Way is difficult in Bugzilla, so the
> developers are considering using history.replaceState() to change the
> URL of process_bug.cgi back to show_bug.cgi?id=xxx.

This is a standard nuisance: you want to display a success/failure
message.  You don't want to just display it in the POST result,
because then you get browser warnings, the URL can't be copy-pasted,
etc.  You don't want to tack it on as a URL parameter because then the
success/failure messages can be forged.  There's no good answer I'm
aware of barring tedious server-side trickery (like queuing up a
message for display on the next view of certain types of pages).

replaceState() sounds like it should be a decent solution if
implemented as you'd like, although it only works if JavaScript is
enabled, so it's not ideal.

> This works well, but it has the small problem that when you refresh
> the page after processing a bug, Firefox shows you the warning it
> shows when you refresh a page which was POST'ed to.
>
> I wonder if calling push/replaceState should cause the browser to
> consider the affected history entry as the result of a GET, even if it
> was the result of a POST.  Bugzilla may be abusing the API here a bit,
> but it's still not clear that we're doing the right thing when we
> prompt the user on a refresh (or if we were to refuse to load the page
> on a session restore since the load isn't idempotent).
>
> I'm curious what the WhatWG thinks of this.

I'd think that hitting refresh when the URL has been changed by
JavaScript should load the current URL displayed in the location bar.
If this is different from the actual URL that the page was originally
served from, then submitting POST data that was submitted for the
current page probably makes no sense, so treating the new request in
all ways as a GET seems like the only sensible thing.  So I'd say this
is a Firefox bug, if Firefox does this.  (What do other browsers do?
WebKit implements replaceState, right?)