[whatwg] push/replaceState interacting with POSTs

[Ian Hickson]

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 ,
> 
> 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 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.   `._.-(,_..'--(,_..'`-.;.'