Be really careful with this. While all browsers out there speak http 1.1 by now and thus should support 303 redirects, many proxy servers are still living in http 1.0 land.<p>A proxy shouldn't care about a status code in the 300 range, but it might (maybe erroring out on "unknown" codes as part of some security feature).<p>And then there are scripts quickly thrown together using the HTTP libraries of $LANGUAGE. You'd have to check these too if you use them in a context where you'd also use a 303 redirect.<p>For what it's worth: my app is serving pages to users behind the worst possible collections of both enterprise and personal firewalls that seem to mangle HTTP headers at will. Heck, I even have more than 10% IE 5.5 users on one installation.<p>That said, ever since 2004 I have never had one instance of a browser or proxy resubmitting a form in response to a 302 redirect. But many instances of where leaving the trodden path, was causing the strangest unexpected breakages due to severely broken client software.<p>As such, personally, I will stay with what works and what the RFC is admitting to generally work even if it shouldn't, instead of experimenting with semantics for no visible gain what so ever.<p>Sounding bitter? Once you witness AV software altering Content-Encoding headers without altering the encoding, you too would get bitter :-)