302和307redirect有什么区别？
302 FOUND和307 TEMPORARY REDIRECT HTTP响应有什么区别？
W3规范似乎表明，它们都用于临时redirect，除非响应明确允许它们都不能被caching。
区别在于redirectPOST ， PUT和DELETE请求以及服务器对用户代理行为的期望（ RFC 2616 ）：
注意：RFC 1945和RFC 2068指定客户端不允许更改redirect请求上的方法。 然而，大多数现有的用户代理实现将302看作是303响应，无论原始请求方法如何，都对Location字段值执行GET。 状态码303和307已被添加到希望明确地清楚客户端期望哪种反应的服务器。
另外，请阅读关于30xredirect代码的维基百科文章。
307是因为用户代理采用事实上的行为来接收POST请求，收到302响应并向位置响应头发送GET请求。
这是不正确的行为 – 只有一个303应该导致一个POST变成一个GET。 如果原始的POST请求返回302，则用户代理在请求新的URL时应该（但不要）坚持POST方法。
307被引入以允许服务器向用户代理清楚，当跟随位置响应报头时客户端不应当进行方法改变。
Google 307 Internal Redirect一个很好的例子就是当谷歌浏览器遇到一个HTTP调用时，它就会知道这个域需要严格的传输安全性。
浏览器无缝地redirect，使用与原始调用相同的方法。
预期302：redirect在NEW_URL上使用相同的请求方法POST
CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL
ACTUAL for 302，303：将更改请求方法从POSTredirect到NEW_URL上的GET
CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET) CLIENT POST OLD_URL -> SERVER 303 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)
实际307：redirect在NEW_URL上使用相同的请求方法POST
CLIENT POST OLD_URL -> SERVER 307 NEW_URL -> CLIENT POST NEW_URL
另外，对于服务器pipe理员来说，重要的是要注意，如果使用307redirect，浏览器可能会向用户提示一个提示。
例如*，Firefox和Opera会要求用户redirect，而Chrome，IE和Safari会透明地redirect。
*每个Bulletproof SSL和TLS （第192页）。
在某些使用情况下，攻击者可能会滥用307个redirect来获知受害者的凭据。
更多的信息可以在OAuth 2.0综合正式安全分析的 第3.1节中find。
上述论文的作者build议如下：
固定。 与OAuth标准中的当前措词相反，redirect的确切方法不是实现细节，而是OAuth安全性的必要条件。 在HTTP标准（ RFC 7231 ）中，只有303redirect被非正式地定义为删除HTTP POST请求的主体。 所有其他的HTTPredirect状态代码，包括最常用的302，都会让浏览器保留POST请求和表单数据。 在实践中，浏览器通常重写为GET请求，从而删除表单数据，除了307redirect。 因此，对于上述步骤，OAuth标准应该需要303redirect来解决这个问题。
