Re: [Bug11458] Managing redirects

On Jan 31, 2013, at 4:04 PM, Travis Leithead <Travis.Leithead@microsoft.com> wrote:

> Bug 11458, suggests creating a mechanism to redirect the browser to an alternate URL when the user refreshes the page.
>  
> This feature would appear to solve the problem we often see where the browser prompts the user with a "do you want to re-send your information to this page" (because the page may have been a form post result page) by instructing the browser to navigate to another URL instead of refreshing the page.
>  
> In the discussion in the bug, it is suggested that history.pushState is a solution to this problem. I haven't thought too deeply about this, but it seems like the History API could be use used to programmatically redirect the page on a "popstate" event.
>  
> Does anyone disagree? Am I understanding the proposed solution and/or problem correctly?


<chair hat off>

The example in the bug does not involve POST. I think the use case in the bug itself is clearly handled by history.pushState(). This allows changing the URL the browser considers itself to be on without doing an actual navigation, which is sufficient for the "save state of dynamic Web app" use case and actually works better than what is proposed, because it works even if the user bookmarks the page, copies the URL into another browser, or shares the URL with someone else.

For the POST use case that you describe, there is a solution within existing Web technology called the Post/Redirect/Get pattern: <http://en.wikipedia.org/wiki/Post/Redirect/Get>. Basically it amounts to redirecting a POST request to a GET request that describes the results of the POST's non-idempotent operation. This solution is also superior to the proposal in the bug for the form POST case, again because it makes bookmarking and copying of the URL work as expected. Another alternative is using Ajax techniques for form submission; this avoids doing a page load with POST in the first place.

Thus, to the best of my understanding, the proposed feature is not required for the suggested use cases, and is actually worse than existing solutions.

Regards.
Maciej