Redirect after POST request
Every web developer knows that after submitting a form submission, it is advisable to redirect to prevent data from being sent again when the user wants to refresh the page. Basically, this is a critical operation, since these forms can be stored in a database or participate in a payment transaction. And then the data is not only duplicated, but also extra money will be written off.
But it's not about money, but about the right redirect ...
Almost all web applications with a redirect POST request return the status of 302 Found. For example, in php, a redirect is done like this: header ('Location: / new / location') ;. Without additional parameters or if no other status is specified separately, the function will return 302 Found.
Now let's turn to official documents. RFC 2616 states the following:
If you haven’t been able to make it, it’s not a problem.
')
If status 302 is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request until it is confirmed by the user, as this may violate the terms of the request.
It also says in the notes that despite this, many user agents neglect this rule and interpret 302 status as 303. And it went from the time of HTTP / 1.0, in which 303 status was not yet.
Those. To redirect a POST request, you need to use the status 303 See Other, which is intended for this purpose. In php, a redirect will look, for example, like this: header ('Location: / new / location', true, 303);
The RFC in the note to the status of 303 says:
Do not understand the 303 status. For example, the 302
Many pre-HTTP / 1.1 user agents do not understand 303 status. If compatibility with such clients is important, then 302 status can be used instead, since the majority of such agents respond to 302 status as well as to 303.
And it turns out two options:
1. Still use 302;
a. There is a chance to run into a user agent who honors the specification and will issue a warning.
b. Since this behavior is not standard, you can run into an unpredictable result.
2. Use 303, then old customers will not understand what they want from them.
In the second case, you can analyze the version of the protocol requested by the client, and issue 302 for old clients. In the body of the answer to write a link to the new URL. Then the user of the old agent can at least click on the link.
But it's not about money, but about the right redirect ...
Almost all web applications with a redirect POST request return the status of 302 Found. For example, in php, a redirect is done like this: header ('Location: / new / location') ;. Without additional parameters or if no other status is specified separately, the function will return 302 Found.
Now let's turn to official documents. RFC 2616 states the following:
If you haven’t been able to make it, it’s not a problem.
')
If status 302 is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request until it is confirmed by the user, as this may violate the terms of the request.
It also says in the notes that despite this, many user agents neglect this rule and interpret 302 status as 303. And it went from the time of HTTP / 1.0, in which 303 status was not yet.
Those. To redirect a POST request, you need to use the status 303 See Other, which is intended for this purpose. In php, a redirect will look, for example, like this: header ('Location: / new / location', true, 303);
The RFC in the note to the status of 303 says:
Do not understand the 303 status. For example, the 302
Many pre-HTTP / 1.1 user agents do not understand 303 status. If compatibility with such clients is important, then 302 status can be used instead, since the majority of such agents respond to 302 status as well as to 303.
And it turns out two options:
1. Still use 302;
a. There is a chance to run into a user agent who honors the specification and will issue a warning.
b. Since this behavior is not standard, you can run into an unpredictable result.
2. Use 303, then old customers will not understand what they want from them.
In the second case, you can analyze the version of the protocol requested by the client, and issue 302 for old clients. In the body of the answer to write a link to the new URL. Then the user of the old agent can at least click on the link.
Source: https://habr.com/ru/post/86258/
All Articles