[whatwg] push/replaceState interacting with POSTs
ian at hixie.ch
Tue Aug 10 18:17:29 PDT 2010
On Fri, 16 Jul 2010, Justin Lebar 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 ,
> 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 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).
This seems reasonable. I recommend implementing it and reporting on
whether it is considered a success. If it is, I'd be happy to change the
spec to require this.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg