You are here

HTTP headers to indictate side-effects of forms


You've all seen it many times. You hit the 'back' button and the browser tells you it has to resubmit a form, which may be dangerous, in order to go back. A lot of the blame for this I presume lies on pages not setting suitable cache TTLs on pages served by forms, but I think we could be providing more information here, even with an accurate cache note.

I suggest that when responding to a form POST, the HTTP response should be able to indicate how safe it is to re-post the form, effectively based on what side-effects (other than returning a web page) posting the form had. There are forms that are totally safe to re-POST, and the browser need not ask the user about it, instead treating them more like they do a GET.

(Truth be told, the browser should not really treat GET and POST differently, my proposed header would be a better way to do it on both of them.)

The page could report that the side effects are major (like completing a purchase, or launching an ICBM) and thus that re-posting should be strongly warned against. The best way to do this would be a string, contained in the header or in the HTML so the browser can say, "This requires resubmitting the form which will " for example.

This is, as noted, independent of whether the results will be the same, which is what the cache is for. A form that loads a webcam has no side effects, but returns a different result every time that should not be cached.

We could also add some information on the Request, telling the form that it has been re-posted from saved values rather than explicit user input. It might then decide what to do. This becomes important when the user has re-posted without having received a full response from the server due to an interruption or re-load. That way the server can know this happened and possibly get a pointer to the prior attempt.

In addition, I would not mind if the query on the back button about form repost offered me the ability to just see the expired cache material, since I may not want the delay of a re-post.

With this strategy in mind, it also becomes easier to create the deep bookmarks I wrote of earlier, with less chance for error.

Some possible levels of side-effects could be None, Minor, Major and Forbidden. The tag could also appear as an HTML attribute to the form itself, but then it can't reveal things that can only be calculated after posting, such as certain side effects.


I'm not sure a back button should *ever* re-submit a form. It's a side-effect of the stateless web, but it's certainly not a feature that is designed. Augmenting the behavior would probably just confuse people more. With Ajax (and other technologies) the notion that sending data to the server automatically sends you to *another* page is becoming a bit obsolete anyway.


It's possible one could do that, though it would mean showing people pages after they have expired. However, there are other ways to get to an old page besides the back button, such as history -- and as I've pointed out, bookmarks. If there are going to be time when you want forms to be resubmitted with data, you want to know what the consequences of that are, and in particular if there are no consequences. One of the classes of side-effects I should add to the list is "login." If a form logs you in, that's a big side effect in some senses, but really a very minimal one in other senses.

Right now the distinction between POST and GET is arbitrary. Both are forms, they are largely isomorphic. POST just doesn't show what you submitted in the URL, and can be used for larger bits of data.

I use the w3m web browser most of the time, and I don't usually say so because using a console-based web browser with no JavaScript support gets me blank looks. But it has some serious usability advantages over Firefox, one being that if you navigate off a page, you can ALWAYS GET THAT EXACT PAGE BACK. With no delay, no side effects.

I do not see any reason why this is hard to do. Everything is cached. Netscape Navigator and its clones (which includes every major browser today) seem to be deliberately broken to deny you the web page you saw 30 seconds ago. This is really a basic sanity feature without which I cannot consider myself in control of my browsing.

What is the philosophy behind reloading pages when the user does not ask for it? Why is this considered a feature?

Another broken relic from Netscape: Go back several pages, then click a link. All your "Forward" history vanishes. w3m fixes this, too.

That back button message drives me up the wall at the best of times. Who on earth decides these things? I'm dumbfounded no-one's ever thought to add a "show me the page but DON'T resubmit the form" option.

At this point we hear all kinds of rhetoric like: "Ahh, you see, it's all to do with the history of the internet. When we devised the POST mechanism we had no idea the web would end up being used for actual *applications*..."

So things often seem to stay broken because of historic convention. Thank goodness we have a few forward-thinkers like Brad.

Add new comment

Subscribe to Comments for "HTTP headers to indictate side-effects of forms"