![[Home]](/download/logo.png){kind=logo}
Make sure your edit form plays nice with the browser’s back button.
Text editing on wikis is often done using a HTML form with an text box in it, containing the page’s text, which is modified by the user and then sent to the server with the HTTP POST method to be saved as the new page content. This simple and straightforward mechanism may create some problems when used together with the browser’s history – most commonly by the use of the browser’s “back” button.
If your wiki simply accepts the POST-ed form, saves the page and then sends the new rendered page content as the response to that POST request, then going back to that point in browser history is going to make the borwser re-post that content – that’s because the browser doesn’t know that it can get the same page using a GET (and this is true for some wiki engines, as they sometimes will display an additional information in responses to POSTs, like messages confirming that the page has been saved). This means that each time you try to go back in your browsing history, the old page content will be re-posted, destroying any changes that could have been made in the mean time or triggering edit conflicts, if the wiki engine in question can detect them.
Modern web browsers have developed some countermeasures for this problem. Microsoft Internet Explorer will simply not allow you to go back in history to that point – or beyond it. Firefox will ask you if you want to re-post the form. Chrome will display a replacement page, informing you about the situation, and will let you repost the form manually. No matter which workaround is used, the experience is still jarring, unfriendly and potentially dangerous for the wiki content.
But there is a way around that. Instead of sending the new page content, respond to the POST HTTP request with a code 303 redirect to that page. The browser will then make another request, a GET this time, and save that in the browsing history: the POST will disappear from it as if it never was there, replaced with the new address. Now the users can use the “back” button safely… except for another problem.
Fixing one problem with the browser history exposes another one, which wasn’t evident at first because the history didn’t work anyways. Now that it’s working as expected, people can use their “back” buttons to go back to the editor page. But because browsers cache the pages, the editor you get may contain the old page content, while the page might have been edited in the mean time by many users. Of course posting that will again result in destroying content or edit conflicts.
Since the problem is caused by browser’s cache, we can simply forbid caching of the editor pages. Adding “no-cache” or “must-revalidate” to the “Cache-Control” HTTP headers for those pages should solve the problem, right? Wrong! It would solve the problem in a perfect world where browser developers obey the specifications. Unfortunately, in the race to seem to be faster, modern browsers often ignore the cache control headers and cache the pages anyways. This is very frustrating: there is a mechanism for solving this problem, but it’s unusable because the browser developers have chosen to simply ignore it on purpose.
I didn’t try this et, but perhaps it’s possible to force a refresh of the page with javascript. It’s like a patching the broken browser, really.
All we need is some way to tell if the page is freshly loaded from the server or loaded from the browser’s cache, either by pressing the back button, visiting browsing history or loading a saved browser session. In the latter case the script could simply force a refresh of the page. It’s not yet clear whether this can be reliably detected though. Some possibilities:
This doesn’t work, the events are not cached together with the form’s content.