307内部重定向的一个很好的例子是当谷歌Chrome遇到一个HTTP调用到一个域，它知道需要严格的传输安全。

浏览器使用与原始调用相同的方法无缝重定向。

307内部重定向的一个很好的例子是当谷歌Chrome遇到一个HTTP调用到一个域，它知道需要严格的传输安全。

浏览器使用与原始调用相同的方法无缝重定向。

302的预期:重定向使用相同的请求方法POST在NEW_URL

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL

实际302,303:重定向改变请求方法从POST到GET的NEW_URL

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的ACTUAL:重定向在NEW_URL上使用相同的请求方法POST

CLIENT POST OLD_URL -> SERVER 307 NEW_URL -> CLIENT POST NEW_URL

在某些用例中，攻击者可能会滥用307重定向来了解受害者的凭据。

更多信息可以在OAuth 2.0的全面正式安全分析的3.1节中找到。

上述论文的作者建议如下:

Fix. Contrary to the current wording in the OAuth standard, the exact method of the redirect is not an implementation detail but essential for the security of OAuth. In the HTTP standard (RFC 7231), only the 303 redirect is defined unambigiously to drop the body of an HTTP POST request. All other HTTP redirection status codes, including the most commonly used 302, leave the browser the option to preserve the POST request and the form data. In practice, browsers typically rewrite to a GET request, thereby dropping the form data, except for 307 redirects. Therefore, the OAuth standard should require 303 redirects for the steps mentioned above in order to fix this problem.

另外，对于服务器管理员，重要的是要注意，如果使用307重定向，浏览器可能会向用户显示提示。

例如，Firefox和Opera会要求用户允许重定向，而Chrome、IE和Safari会透明地进行重定向。

*每个防弹SSL和TLS(第192页)。

302 is temporary redirect, which is generated by the server whereas 307 is internal redirect response generated by the browser. Internal redirect means that redirect is done automatically by browser internally, basically the browser alters the entered url from http to https in get request by itself before making the request so request for unsecured connection is never made to the internet. Whether browser will alter the url to https or not depends upon the hsts preload list that comes preinstalled with the browser. You can also add any site which support https to the list by entering the domain in the hsts preload list of your own browser which is at chrome://net-internals/#hsts.One more thing website domains can be added by their owners to preload list by filling up the form at https://hstspreload.org/ so that it comes preinstalled in browsers for every user even though I mention you can do particularly for yourself also.

Let me explain with an example: I made a get request to http://www.pentesteracademy.com which supports only https and I don't have that domain in my hsts preload list on my browser as site owner has not registered for it to come with preinstalled hsts preload list. GET request for unsecure version of the site is redirected to secure version(see http header named location for that in response in above image). Now I add the site to my own browser preload list by adding its domain in Add hsts domain form at chrome://net-internals/#hsts, which modifies my personal preload list on my chrome browser.Be sure to select include subdomains for STS option there. Let's see the request and response for the same website now after adding it to hsts preload list. you can see the internal redirect 307 there in response headers, actually this response is generated by your browser not by server. Also HSTS preload list can help prevent users reach the unsecure version of site as 302 redirect are prone to mitm attacks. Hope I somewhat helped you understand more about redirects.