POST-requesting a location sending Refresh header makes Firefox create GET request but still hold POST data_问答_开发者

POST-requesting a location sending Refresh header makes Firefox create GET request but still hold POST data

开发者 https://www.devze.com 2023-04-02 21:19 出处：网络

Consider the following code; it\'s basically a form that sends some data via HTTP POST. When the POST data come, the Refresh HTTP header is sent.

相关专题：firefox http

Consider the following code; it's basically a form that sends some data via HTTP POST. When the POST data come, the Refresh HTTP header is sent.

<?php
if (!empty($_POST))
{
    header("Refresh: 5; URL=http://$_SERVER[SERVER_NAME]$_SERVER[REQUEST_URI]");
}
?>
<!doctype html>
<form method=post>
    <input type=hidden name=foo value=bar>
    <input type=submit>
</form>
<?php
echo "The location was requested using the HTTP $_SERVER[REQUEST_METHOD] method; \$_POST = ".var_export($_POST, 1);
?>

Now, do this:

Open it in Firefox browser (I've created a demo here; I use 6.0.1 on Debian).
Submit the form. Obviously, the browser performed an HTTP POST request. Note that the Refresh HTTP header came with the response.
Wait for 5 seconds. Now the Refresh header is being applied and the location will be redirected to itself.
Firefox performed a GET request. It is definitely GET because both Firebug and PHP's $_SERVER['REQUEST_METHOD'] say it.
Press F5 key. Since the last performed HTTP request was a GET request, one would expect that all POST data from previous requests will be lost. However, a dialog box appears and asks me to resend POST data:

To开发者_运维技巧 display this page, Iceweasel must send information that will repeat any action (such as a search or order confirmation) that was performed earlier.

So, my question is - why are the POST data still here? Is this a bug or intended behaviour? Note that use of any of the following will cause the loss of POST data (the expected behaviour):

Location header instead of Refresh
Different value of URL= parameter of Refresh header (the user will be redirected to another location).
Another browser (I've tested Internet Explorer 9.0.2 and Chromium 6.0).

This is neither a bug, nor intended behaviour. The reason for this is that there is no header called Refresh: defined by any of the HTTP RFCs (most notably RFC1945 and RFC2616 make no mention of it). This means that, while most browsers do implement the Refresh header as if it were a meta refresh, there is no expected behaviour for this that can be assumed to be the same across all browsers.

Looking around StackOverflow and the internet in general it seems that the Refresh: header was (like so many things) invented by Netscape in the early days of the internet and adopted by everybody. While many of these arbitrary Netscape designs (such as Javascript) were later adopted as industry standards, the Refresh: header was not, because HTTP already made provision for this functionality with 3xx response codes.

The long of the short of this is that it is hardly surprising that different browsers handle it differently, because there is no standard that tells the developers of the browsers exactly how to handle it. And about using the header in your applications - don't. Plain and simple. Use 3xx redirects. That's what they're for. And if you are using it because you need to refresh the page after a timeout, use a <meta> refresh - while this is now officially deprecated it should be handled the same way everywhere.