[Update: it’s working now, after upgrading Ubuntu. Here’s an online test for your own browser.]
Post/Redirect/Get (PRG) is a common web-application design pattern, where a server responds to an HTTP POST request not by generating HTML immediately, but by redirecting the browser to GET a different page. At the cost of an extra request, PRG allows users safely to bookmark, reload, etc.
When someone attempts to reload a page generated by a POST request, browsers will generally pop up a warning that reloading will cause a form to be resubmitted, possibly causing you to purchase two sports cars (etc.) — that warning is a good thing. Strangely, however, Firefox 1.5.03 will pop up the same warning after a PRG operation, when reloading should not cause anything bad to happen. I can think of a few possible reasons:
- Firefox wants to repeat the entire PRG operation rather than just the final GET
- Because the GET was the (indirect) result of a POST operation, Firefox still wants to warn you that there might be something fishy.
- An obscure bug.
I’m leaning towards #3, but I’m curious about whether anything thinks that Firefox is doing the right thing here, and whether other browsers (MSIE, Opera, Safari, etc.) act the same way.
Quoderat 
I’m in the middle of developing a webapp that makes heavy use of P-R-G and that’s not my experience with Firefox 1.5.0.3 (on Windows at least). Perhaps it is a bug triggered by certain headers in your redirect or something.
Whereas I can confirm seeing the same, using the following:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3You saw the same as me, Aristotle? If so, then it sounds like a bug specific to the Linux version. I’m glad to hear it’s not a general practice.
Same problem here on windows … preventing us from using our selenium based tests
Nobody’s mentioned the response code, but I assume this is all using 303, right? That’s the only redirect response code with semantics that align with PRG as described. If you were using 301 or 302, then Firefox’s behaviour would be appropriate because that’s telling the client to POST to a new URI, not – as with 303 – to find the results at some other URI.
Since I updated Ubuntu on the weekend (same upstream Firefox version), PRG is working fine. By default, PHP5 generates a 302 when I set a location header, but I see no difference with 303.
For anyone else interested, I’ve put a small test online: http://www.megginson.com/test/prg/prg-test.html.
Hi – the form is not rendering in Safari due to missing quote in “input” tag. BTW all working with PRG, on Firefox 1.5.0.4 on Mac (OS X 10.4)
Thanks for catching that, Paul — I’ve fixed the mangled attribute.
Ouch, that’s a bug. The warning should show on a POST request that results in a 302 or 301 response. As I say, 303 is the only http response code with PRG semantics.
I’ll submit a bug when I get a chance.
Yes, 302 is sometimes treated as being identical to 303, unfortunately, which is why 307 was created. Still, 303 is better than 302 in this case because there’s less ambiguity.