entityMap|0|type|LINK|mutability|MUTABLE|data|url|http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html|1|http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection|blocks|key|47ko1|text|不同之处在于重定向POSTPUT和DELETE|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|arcap|请求以及服务器对用户代理行为的期望(RFC+2616):|8stde|注意:+RFC+1945和RFC+2068指定不允许客户端更改重定向请求的方法。然而，大多数现有的用户代理实现将302视为303响应，对位置字段值执行GET，而不考虑原始请求方法。已经为服务器添加了状态代码303和307，这些服务器希望明确地表明客户端期望哪种类型的反应。|6s5g0|另外，请阅读Wikipedia上的文章30倍重定向codes..。^0|9|7|H|6|0|I|8|I|8|0|0|0|J|B|1^^$0|$1|$2|3|4|5|6|$7|8]]|9|$2|3|4|5|6|$7|A]]]|B|@$C|D|E|F|2|G|H|U|I|@$J|V|K|W|L|M]|$J|X|K|Y|L|M]]|N|@]|6|$]]|$C|O|E|P|2|G|H|Z|I|@$J|10|K|11|L|M]]|N|@$J|12|K|13|C|14]]|6|$]]|$C|Q|E|R|2|G|H|15|I|@]|N|@]|6|$]]|$C|S|E|T|2|G|H|16|I|@]|N|@$J|17|K|18|C|19]]|6|$]]]]

The difference concerns redirecting <code>POST</code>, <code>PUT</code> and <code>DELETE</code> requests and what the expectations of the server are for the user agent behavior (<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" rel="noreferrer"><code>RFC 2616</code></a>):

<blockquote>
 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.
</blockquote>

Also, read Wikipedia article on the <a href="http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection" rel="noreferrer">30x redirection codes</a>.

entityMap|blocks|key|51ibi|text|307的出现是因为用户代理被采用为|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3kgoo|事实|1qg85|接受接收302响应并向Location响应头发送GET请求的POST请求的行为。这就是不正确行为-仅限303应该会导致POST变成GET。如果原始POST请求返回302，则用户代理在请求新URL时应该(但不要)坚持使用POST方法。|4v8dj|307的引入是为了允许服务器向用户代理清楚地表明，方法更改应该|aj25s|注释|33hhb|由客户端在跟随Location响应头时生成。^0|0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|M|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|N|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|O|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|P|9|@]|A|@]|B|$]]|$2|I|4|J|6|7|8|Q|9|@]|A|@]|B|$]]|$2|K|4|L|6|7|8|R|9|@]|A|@]|B|$]]]]

307 came about because user agents adopted as a de facto behaviour to take POST requests that receive a 302 response and send a GET request to the Location response header.

That is the incorrect behaviour &mdash; only a 303 should cause a POST to turn into a GET. User agents should (but don't) stick with the POST method when requesting the new URL if the original POST request returned a 302.

307 was introduced to allow servers to make it clear to the user agent that a method change should not be made by the client when following the Location response header.

entityMap|0|type|IMAGE|mutability|IMMUTABLE|data|imageUrl|https://ask.qcloudimg.com/http-save/actteam/55b5a1f6977cc0f7929e445f62fe15b9.png|imageAlt|blocks|key|3devi|text|这是一个很好的例子307+Internal+Redirect当Google+Chrome遇到对它所知道的需要严格传输安全的域的HTTP调用时，就会发生这种情况。|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|1veg1|浏览器使用与原始调用相同的方法无缝重定向。|bjlm8|​|3vllu|?|atomic|2raod^0|9|L|0|0|0|0|1|0|0^^$0|$1|$2|3|4|5|6|$7|8|9|-4]]]|A|@$B|C|D|E|2|F|G|V|H|@$I|W|J|X|K|L]]|M|@]|6|$]]|$B|N|D|O|2|F|G|Y|H|@]|M|@]|6|$]]|$B|P|D|Q|2|F|G|Z|H|@]|M|@]|6|$]]|$B|R|D|S|2|T|G|10|H|@]|M|@$I|11|J|12|B|13]]|6|$]]|$B|U|D|Q|2|F|G|14|H|@]|M|@]|6|$]]]]

A good example of the <code>307 Internal Redirect</code> in action is when Google Chrome encounters a HTTP call to a domain it knows as requiring Strict Transport Security.

The browser redirects seamlessly, using the same method as the original call.

<img src="https://i.stack.imgur.com/HmNU4.png" alt="HTST 307 Internal Redirect">

entityMap|0|type|IMAGE|mutability|IMMUTABLE|data|imageUrl|https://ask.qcloudimg.com/http-save/actteam/ff8aff582cc6c311c47537fa6aec6973.png|imageAlt|1|LINK|MUTABLE|url|https://tools.ietf.org/html/rfc2616#section-10.3.3|2|https://tools.ietf.org/html/rfc7238|3|https://github.com/Fyrd/caniuse/issues/1830#issuecomment-233700576|blocks|key|5qsp|text|​|unstyled|depth|inlineStyleRanges|entityRanges|fbuod|?|atomic|offset|length|4boht|8t4d4|301:永久重定向:+URL太旧，需要更换。|c9d5m|浏览器将对此进行缓存。|6qg8r|示例用法：URL已从/register-form.html至|style|CODE|bkpo3|signup-form.html。|872ku|根据RFC7231，该方法将更改为GET：“由于历史原因，用户代理可能会将后续请求的请求方法从POST更改为GET。”|4dfcn|302:临时重定向。仅用于HTTP/1.0客户端。|3lsfp|此状态代码不应更改方法，但浏览器无论如何都会更改。RFC说：“许多早于HTTP/1.1的用户代理不理解303。当与这样的客户端的互操作性是一个问题时，可以使用302状态码来代替，因为大多数用户代理对302响应作出反应，就像这里为303所描述的那样。“当然，一些客户端可能会根据规范来实现它，所以如果与这些古老的客户端的互操作性不是一个真正的问题，那么303更好以获得一致的结果。|tek1|303:临时重定向，修改方法为GET。|rqsh|drnkh|9m9ie|示例用法：|18lh5|如果浏览器将POST发送到/register.php，然后现在加载(GET)/success.html。307:临时重定向，重复相同的请求。|bt0h|示例用法：如果浏览器将POST发送到/register.php，然后这将告诉它在以下位置重做POST/signup.php。|f23rq|308:永久重定向，重复相同的请求。|5i28o|其中，307是303的“无方法改变”的对应物，该308状态是301的“无方法改变”的对应物。|eirkn|RFC+7231+(from+2014)可读性很强，而且不会过于冗长。如果你想知道确切的答案，这是一本推荐的读物。其他一些答案使用1999年的RFC+2616，但没有任何变化。|f718p|RFC+7238+指定了+308+状态。它被认为是实验性的，但它在+2016+年已经被supported+by+all+major+browsers|a77j5|76a6|83v6a^0|0|0|1|0|0|0|0|0|A|J|0|0|G|0|0|0|0|0|0|0|0|D|D|12|D|0|I|D|1E|B|0|0|0|0|K|1|0|0|8|2|17|V|3|0|0|0^^$0|$1|$2|3|4|5|6|$7|8|9|-4]]|A|$2|B|4|C|6|$D|E]]|F|$2|B|4|C|6|$D|G]]|H|$2|B|4|C|6|$D|I]]]|J|@$K|L|M|N|2|O|P|1Z|Q|@]|R|@]|6|$]]|$K|S|M|T|2|U|P|20|Q|@]|R|@$V|21|W|22|K|23]]|6|$]]|$K|X|M|N|2|O|P|24|Q|@]|R|@]|6|$]]|$K|Y|M|Z|2|O|P|25|Q|@]|R|@]|6|$]]|$K|10|M|11|2|O|P|26|Q|@]|R|@]|6|$]]|$K|12|M|13|2|O|P|27|Q|@$V|28|W|29|14|15]]|R|@]|6|$]]|$K|16|M|17|2|O|P|2A|Q|@$V|2B|W|2C|14|15]]|R|@]|6|$]]|$K|18|M|19|2|O|P|2D|Q|@]|R|@]|6|$]]|$K|1A|M|1B|2|O|P|2E|Q|@]|R|@]|6|$]]|$K|1C|M|1D|2|O|P|2F|Q|@]|R|@]|6|$]]|$K|1E|M|1F|2|O|P|2G|Q|@]|R|@]|6|$]]|$K|1G|M|-4|2|O|P|2H|Q|@]|R|@]|6|$]]|$K|1H|M|-4|2|O|P|2I|Q|@]|R|@]|6|$]]|$K|1I|M|1J|2|O|P|2J|Q|@]|R|@]|6|$]]|$K|1K|M|1L|2|O|P|2K|Q|@$V|2L|W|2M|14|15]|$V|2N|W|2O|14|15]]|R|@]|6|$]]|$K|1M|M|1N|2|O|P|2P|Q|@$V|2Q|W|2R|14|15]|$V|2S|W|2T|14|15]]|R|@]|6|$]]|$K|1O|M|1P|2|O|P|2U|Q|@]|R|@]|6|$]]|$K|1Q|M|1R|2|O|P|2V|Q|@]|R|@]|6|$]]|$K|1S|M|1T|2|O|P|2W|Q|@]|R|@$V|2X|W|2Y|K|2Z]]|6|$]]|$K|1U|M|1V|2|O|P|30|Q|@]|R|@$V|31|W|32|K|33]|$V|34|W|35|K|36]]|6|$]]|$K|1W|M|-4|2|O|P|37|Q|@]|R|@]|6|$]]|$K|1X|M|-4|2|O|P|38|Q|@]|R|@]|6|$]]|$K|1Y|M|-4|2|O|P|39|Q|@]|R|@]|6|$]]]]

<a href="https://i.stack.imgur.com/zz2Mx.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/zz2Mx.png" alt="Flowchart" /></a>
<ul>
<li>301: permanent redirect: the URL is old and should be replaced. Browsers will cache this. 
Example usage: URL moved from <code>/register-form.html</code> to <code>signup-form.html</code>. 
The method will change to GET, as per RFC 7231: &quot;For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.&quot;</li>
<li>302: temporary redirect. Only use for HTTP/1.0 clients. This status code should not change the method, but browsers did it anyway.
The RFC says: &quot;Many pre-HTTP/1.1 user agents do not understand [303]. 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.&quot; Of course, some clients may implement it according to the spec, so if interoperability with such ancient clients is not a real concern, 303 is better for consistent results.</li>
<li>303: temporary redirect, changing the method to GET. 
Example usage: if the browser sent POST to <code>/register.php</code>, then now load (GET) <code>/success.html</code>.</li>
<li>307: temporary redirect, repeating the request identically. 
Example usage: if the browser sent a POST to <code>/register.php</code>, then this tells it to redo the POST at <code>/signup.php</code>.</li>
<li>308: permanent redirect, repeating the request identically. Where 307 is the &quot;no method change&quot; counterpart of 303, this 308 status is the &quot;no method change&quot; counterpart of 301.</li>
</ul>
<a href="https://www.rfc-editor.org/rfc/rfc2616#section-10.3.3" rel="nofollow noreferrer">RFC 7231 (from 2014)</a> is very readable and not overly verbose. If you want to know the exact answer, it's a recommended read. Some other answers use RFC 2616 from 1999, but nothing changed.
<a href="https://www.rfc-editor.org/rfc/rfc7238" rel="nofollow noreferrer">RFC 7238</a> specifies the 308 status. It is considered experimental, but it was already <a href="https://github.com/Fyrd/caniuse/issues/1830#issuecomment-233700576" rel="nofollow noreferrer">supported by all major browsers</a> in 2016.

entityMap|blocks|key|73mtl|text|预期为302:重定向在新的上使用相同的请求方法POST_URL|type|unstyled|depth|inlineStyleRanges|entityRanges|data|e87ou|CLIENT+POST+OLD_URL+->+SERVER+302+NEW_URL+->+CLIENT+POST+NEW_URL|code-block|syntax|js|6pr6t|302，303的实际:将请求方法从POST重定向到GET+on+NEW_URL|dck97|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)|15vcb|307的实际:重定向在新的上使用相同的请求方法POST_URL|c8aa6|CLIENT+POST+OLD_URL+->+SERVER+307+NEW_URL+->+CLIENT+POST+NEW_URL^0|0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|P|9|@]|A|@]|B|$]]|$2|C|4|D|6|E|8|Q|9|@]|A|@]|B|$F|G]]|$2|H|4|I|6|7|8|R|9|@]|A|@]|B|$]]|$2|J|4|K|6|E|8|S|9|@]|A|@]|B|$F|G]]|$2|L|4|M|6|7|8|T|9|@]|A|@]|B|$]]|$2|N|4|O|6|E|8|U|9|@]|A|@]|B|$F|G]]]]

EXPECTED for 302: redirect uses same request method POST on NEW_URL

<pre><code>CLIENT POST OLD_URL -&gt; SERVER 302 NEW_URL -&gt; CLIENT POST NEW_URL
</code></pre>

ACTUAL for 302, 303: redirect changes request method from POST to GET on NEW_URL

<pre><code>CLIENT POST OLD_URL -&gt; SERVER 302 NEW_URL -&gt; CLIENT GET NEW_URL (redirect uses GET)
CLIENT POST OLD_URL -&gt; SERVER 303 NEW_URL -&gt; CLIENT GET NEW_URL (redirect uses GET)
</code></pre>

ACTUAL for 307: redirect uses same request method POST on NEW_URL

<pre><code>CLIENT POST OLD_URL -&gt; SERVER 307 NEW_URL -&gt; CLIENT POST NEW_URL
</code></pre>

entityMap|0|type|LINK|mutability|MUTABLE|data|url|https://hstspreload.org/|1|http://www.pentesteracademy.com/|2|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/actteam/fc55edff82a9aed46513c1573b3cf448.png|imageAlt|3|https://ask.qcloudimg.com/http-save/actteam/84284cfded254a8a6787114d43a23c2f.png|blocks|key|a5hvm|text|302是由服务器生成的临时重定向，而307是由浏览器生成的内部重定向响应。内部重定向意味着重定向是由浏览器在内部自动完成的，基本上浏览器在发出请求之前将get请求中输入的url从http更改为https，这样就永远不会向互联网发出不安全连接的请求。浏览器是否会将url更改为https取决于浏览器预装的hsts预加载列表。您还可以通过在您自己的浏览器的hsts预加载列表中输入域名，将支持https的任何网站添加到列表中，该列表位于chrome://net-internals/#hst。net+thing网站域名可以由其所有者添加到预加载列表，方法是填写表单，地址为https://hstspreload.org/因此，它为每个用户预装在浏览器中，尽管我提到你也可以为自己做特别的事情。|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|1frm4|让我举个例子来解释一下：我发出了一个get请求http://www.pentesteracademy.com它只支持https，我没有在我的hsts预加载列表中的域名，因为网站所有者没有注册它来预装hsts预加载列表。|18bvo|?|atomic|9c088|对不安全版本的站点的GET请求被重定向到安全版本(参见上图中响应的名为location的http标头)。|3u100|现在，我将站点添加到我自己的浏览器预加载列表中，方法是在位于chrome://net-internals/#hsts的add+HSTS域表单中添加它的域，这会修改我的chrome+browser.Be上的个人预加载列表，并确保在那里选择include+subdomains+for+STS选项。|4dab0|现在让我们看看将同一个网站添加到hsts预加载列表后的请求和响应。|b4hnn|erivi|您可以在响应头中看到内部重定向307，实际上此响应是由您的浏览器生成的，而不是由服务器生成的。|3olgg|此外，HSTS预加载列表可以帮助防止用户访问站点的不安全版本，因为302重定向容易受到mitm攻击。|9jcne|希望我能在一定程度上帮助你更好地理解重定向。^0|7W|O|0|0|N|V|1|0|0|1|2|0|0|0|0|0|1|3|0|0|0^^$0|$1|$2|3|4|5|6|$7|8]]|9|$2|3|4|5|6|$7|A]]|B|$2|C|4|D|6|$E|F|G|-4]]|H|$2|C|4|D|6|$E|I|G|-4]]]|J|@$K|L|M|N|2|O|P|1C|Q|@]|R|@$S|1D|T|1E|K|1F]]|6|$]]|$K|U|M|V|2|O|P|1G|Q|@]|R|@$S|1H|T|1I|K|1J]]|6|$]]|$K|W|M|X|2|Y|P|1K|Q|@]|R|@$S|1L|T|1M|K|1N]]|6|$]]|$K|Z|M|10|2|O|P|1O|Q|@]|R|@]|6|$]]|$K|11|M|12|2|O|P|1P|Q|@]|R|@]|6|$]]|$K|13|M|14|2|O|P|1Q|Q|@]|R|@]|6|$]]|$K|15|M|X|2|Y|P|1R|Q|@]|R|@$S|1S|T|1T|K|1U]]|6|$]]|$K|16|M|17|2|O|P|1V|Q|@]|R|@]|6|$]]|$K|18|M|19|2|O|P|1W|Q|@]|R|@]|6|$]]|$K|1A|M|1B|2|O|P|1X|Q|@]|R|@]|6|$]]]]

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 <a href="https://hstspreload.org/" rel="nofollow noreferrer">https://hstspreload.org/</a> 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 <a href="http://www.pentesteracademy.com" rel="nofollow noreferrer">http://www.pentesteracademy.com</a> 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.
<a href="https://i.stack.imgur.com/mhTrM.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/mhTrM.png" alt="request and response headers"></a>
 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. 
<a href="https://i.stack.imgur.com/r86yg.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/r86yg.png" alt="request and response headers"></a>
 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.

entityMap|0|type|LINK|mutability|MUTABLE|data|url|https://www.feistyduck.com/books/bulletproof-ssl-and-tls/|blocks|key|3ikkg|text|此外，对于服务器管理员，重要的是要注意，如果您使用307重定向，浏览器可能会向用户显示提示。|unstyled|depth|inlineStyleRanges|entityRanges|ci3m2|例如，Firefox和Opera会要求用户允许重定向，而Chrome，IE和Safari会透明地进行重定向。|1iqig|每安全套接字层协议[防弹安全套接层协议和TLS]+Bulletproof+SSL+and+TLS(第192页)。|offset|length^0|0|0|P|N|0^^$0|$1|$2|3|4|5|6|$7|8]]]|9|@$A|B|C|D|2|E|F|O|G|@]|H|@]|6|$]]|$A|I|C|J|2|E|F|P|G|@]|H|@]|6|$]]|$A|K|C|L|2|E|F|Q|G|@]|H|@$M|R|N|S|A|T]]|6|$]]]]

Also, for server admins, it may be important to note that browsers may present a prompt to the user if you use 307 redirect.

For example*, Firefox and Opera would ask the user for permission to redirect, whereas Chrome, IE and Safari would do the redirect transparently.

*per <a href="https://www.feistyduck.com/books/bulletproof-ssl-and-tls/" rel="nofollow noreferrer">Bulletproof SSL and TLS</a> (page 192).

entityMap|0|type|LINK|mutability|MUTABLE|data|url|https://arxiv.org/pdf/1601.01229v2.pdf|1|https://tools.ietf.org/html/rfc7231|blocks|key|epvlc|text|在某些用例中，攻击者可能会滥用307重定向来获取受害者的凭据。|unstyled|depth|inlineStyleRanges|entityRanges|bgrb8|有关更多信息，请参阅第3.1节的A+Security+Security+Analysis+of+OAuth+2.0+]。|offset|length|4qmk4|上述论文的作者提出了以下建议：|612v1|使固定。与+OAuth+标准中的当前措辞相反，重定向的确切方法不是实现细节，而是对+OAuth+的安全性至关重要。在+HTTP+标准+(RFC+7231)+中，只有+303+重定向被明确定义为丢弃+HTTP+POST+请求的正文。所有其他+HTTP+重定向状态代码，包括最常用的+302，都让浏览器选择保留+POST+请求和表单数据。在实践中，浏览器通常会重写+GET+请求，从而丢弃表单数据，307+重定向除外。因此，OAuth+标准应要求对上述步骤进行+303+重定向才能解决此问题。|9ik2o|d3bos^0|0|G|15|0|0|0|1W|8|1|0|0^^$0|$1|$2|3|4|5|6|$7|8]]|9|$2|3|4|5|6|$7|A]]]|B|@$C|D|E|F|2|G|H|U|I|@]|J|@]|6|$]]|$C|K|E|L|2|G|H|V|I|@]|J|@$M|W|N|X|C|Y]]|6|$]]|$C|O|E|P|2|G|H|Z|I|@]|J|@]|6|$]]|$C|Q|E|R|2|G|H|10|I|@]|J|@$M|11|N|12|C|13]]|6|$]]|$C|S|E|-4|2|G|H|14|I|@]|J|@]|6|$]]|$C|T|E|-4|2|G|H|15|I|@]|J|@]|6|$]]]]

In some use cases, 307 redirects might be abused by an attacker to learn the victim's credentials.
Further information can be found in section 3.1 of <a href="https://arxiv.org/pdf/1601.01229v2.pdf" rel="nofollow noreferrer">A Comprehensive Formal Security Analysis of OAuth 2.0</a>.
The authors of the above paper suggest the following:
<blockquote>
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 (<a href="https://www.rfc-editor.org/rfc/rfc7231" rel="nofollow noreferrer">RFC 7231</a>), 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.
</blockquote>

What's the difference between a <code>302 FOUND</code> and a <code>307 TEMPORARY REDIRECT</code> HTTP response?

<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3" rel="noreferrer">The W3 spec</a> seems to indicate that they're both used for temporary redirects, and neither can be cached unless the response specifically allows it.

What's the difference between a 302 and a 307 redirect?

服务器

OAuth

 这两者之间的区别是什么？302 FOUND和一个 307 TEMPORARY REDIRECTHTTP响应？The W3 spec ] 似乎表明它们都用于临时重定向，除非响应明确允许，否则两者都不能缓存。

问302重定向和307重定向有什么区别？
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问302重定向和307重定向有什么区别？EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问302重定向和307重定向有什么区别？
EN