http - 这些 HTTP 3xx 状态代码有什么区别？

Question

我正在阅读 the specification about HTTP/1.1重定向代码。我有很多问题:

1. 有一段文字是这样的:

   If the 301/302/307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
   

   问:这在什么意义上被浏览器应用了？我从未看到任何 301/302 响应让我的浏览器询问我是否要确认该操作(例如:通过 PHP 接收表单然后重定向到新输出)。

2. 我很清楚，大多数时候我们使用 302 而不是 303 进行处理和重定向(请参阅其他 - 正是为了这个目的而创建的)。但是，我对 301 302(请注意:预期的原始行为)和 307 感到困惑。Q:在实际示例/使用中它们之间有什么区别案例？

Answer 1

大多数 301/302 重定向响应发生在常规 GET 请求(与 POST 请求相反)上，因此不需要确认。此外，尽管 RFC 在技术上建议对非 GET/HEAD 请求进行确认，但 RFC 还提到:

Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

302 告诉用户代理在以后的请求中继续使用旧的 uri。 303 告诉用户代理在以后的请求中使用新的 uri。

此外，正如您链接到的 RFC 中的注释所述:

Note: Many pre-HTTP/1.1 user agents do not understand the 303
      status. When interoperability with such clients is a concern, the
      302 status code may be used instead, since most user agents react
      to a 302 response as described here for 303.

我认为应该更改 RFC，以便 如果收到 301/302 状态代码以响应 GET 或 HEAD 以外的请求，用户代理不得自动重定向请求，除非它可以由用户确认，因为这可能会改变发出请求的条件。

应重写为如果收到 301/302 状态代码以响应 GET 或 HEAD 以外的请求，则用户代理不应自动重定向请求，除非它可以被用户确认，因为这可能会更改发出请求的条件。

否则大多数当前用户代理都违反了 RFC。