302和307重定向有什么区别?

时间:2010-01-14 23:53:05

标签: http redirect

302 FOUND307 TEMPORARY REDIRECT HTTP响应之间有什么区别?

The W3 spec似乎表明它们都用于临时重定向,除非响应明确允许,否则它们都不能被缓存。

9 个答案:

答案 0 :(得分:143)

307出现是因为用户代理采用事实行为来接收接收302响应的POST请求并向Location响应头发送GET请求。

这是不正确的行为 - 303应该导致POST变成GET。如果原始POST请求返回302,用户代理应该(但不要)在请求新URL时坚持使用POST方法。

引入了307以允许服务器向用户代理明确说明在遵循位置响应标头时客户端应该进行方法更改。

答案 1 :(得分:89)

区别在于重定向POSTPUTDELETE请求以及服务器对用户代理行为的期望(RFC 2616):

  

注意:RFC 1945和RFC 2068指定不允许客户端   更改重定向的方法   请求。但是,大多数现有用户   代理实现将302视为好像   这是一个303响应,执行一个   获取位置字段值   不管原始要求   方法。状态代码303和307   已添加到希望的服务器   毫不含糊地明确哪种   反应是预期的   客户端。

另外,请阅读30x redirection codes上的维基百科文章。

答案 2 :(得分:54)

307 Internal Redirect的一个很好的例子就是当谷歌浏览器遇到对其知道需要严格传输安全的域的HTTP调用时。

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

HTST 307 Internal Redirect

答案 3 :(得分:6)

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

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

ACTUAL for 302,303:将更改请求方法从POST重定向到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)

FORT for 307:重定向在NEW_URL上使用相同的请求方法POST

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

答案 4 :(得分:3)

Flowchart

  • 301:永久重定向:URL旧且应替换。浏览器将对此进行缓存。
    用法示例: URL从/register-form.html移至signup-form.html
    根据RFC 7231,该方法将更改为GET:“由于历史原因,用户代理可以针对后续请求将请求方法从POST更改为GET。”
  • 302:临时重定向。仅用于HTTP / 1.0客户端。此状态代码不应更改方法,但是浏览器还是可以使用。 RFC表示:“许多HTTP / 1.1之前的用户代理不了解[303]。当需要考虑与此类客户端的互操作性时,可以改用302状态代码,因为大多数用户代理都会对302响应做出反应,如此处所述303。”当然,有些客户可能会按照规范实施它,因此,如果与真正的客户之间的互操作性不是真正的问题,那么303会更好地获得一致的结果。
  • 303:临时重定向,将方法更改为GET。
    用法示例:如果浏览器将POST发送到/register.php,则现在加载(GET)/success.html
  • 307:临时重定向,以相同的方式重复请求。
    用法示例:如果浏览器向/register.php发送了POST,则告诉它在/signup.php重做POST。
  • 308:永久重定向,重复相同的请求。其中307是303的“无方法更改”对应项,此308状态是301的“无方法更改”对应项。

RFC 7231 (from 2014)可读性强,不太冗长。如果您想知道确切的答案,建议阅读。其他一些答案使用的是1999年的RFC 2616,但没有任何变化。

RFC 7238指定308状态。它被认为是实验性的,但在2016年已经是supported by all major browsers

答案 5 :(得分:3)

302是由服务器生成的临时重定向,而307是由浏览器生成的内部重定向响应。内部重定向意味着重定向是由浏览器内部自动完成的,基本上,浏览器会在发出请求之前自行在get请求中将输入的URL从http更改为https,因此永远不会进行不安全连接的请求。浏览器是否将URL更改为https取决于浏览器预安装的hsts预加载列表。您还可以通过在自己的浏览器的hsts预加载列表中输入chrome:// net-internals /#hsts中的域,将支持https的任何网站添加到列表中。所有者可以添加其他网站域名通过填写https://hstspreload.org/处的表单来预加载列表,这样即使我提到您也可以自己做,它也已为每个用户预装在浏览器中。


让我用一个例子来解释:
我向http://www.pentesteracademy.com发送了一个get请求,该请求仅支持https,并且我的浏览器的hsts预加载列表中没有该域,因为网站所有者尚未为其预装hsts预加载列表进行注册。 request and response headers
将网站不安全版本的GET请求重定向到安全版本(请参见上图中以HTTP标头命名的位置,以获取响应)。
现在,我通过在chrome:// net-internals /#hsts的Add hsts domain表单中添加站点的域来将该站点添加到我自己的浏览器预加载列表中,这将在chrome浏览器中修改我的个人预加载列表。请确保选择include子域用于有STS选项。
将我们的网站添加到hsts预加载列表中后,现在来看其对网站的请求和响应。
request and response headers
您可以在响应标头中看到内部重定向307,实际上此响应是由您的浏览器而不是服务器生成的。
HSTS预加载列表还可以帮助防止用户访问不安全版本的站点,因为302重定向容易受到mitm攻击。
希望我能帮助您更多地了解重定向。

答案 6 :(得分:2)

| Response               | What browsers should do   | What browsers actually do |
|------------------------|---------------------------|---------------------------|
| 302 Found              | Redo request with new url | GET with new url          |
| 303 See Other          | GET with new url          | GET with new url          |
| 307 Temporary Redirect | Redo request with new url | Redo request with new url |

所有浏览器都错了302。因此创建了303307

╔═══════════╤════════════════════════════════════════════════╗
║           │                Switch to GET?                  ║
║ Temporary │          No            │         Yes           ║
╠═══════════╪════════════════════════╪═══════════════════════╣
║ No        │ 308 Permanent Redirect │ 301 Moved Permanently ║
╟───────────┼────────────────────────┼───────────────────────╢
║ Yes       │ 307 Temporary Redirect │ 303 See Other         ║
║           │ 302 Found (intended)   │ 302 Found (actual)    ║
╚═══════════╧════════════════════════╧═══════════════════════╝

答案 7 :(得分:1)

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

例如*,Firefox和Opera会要求用户重定向,而Chrome,IE和Safari会透明地进行重定向。

* per Bulletproof SSL and TLS(第192页)。

答案 8 :(得分:1)

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

更多信息可在A Comprehensive Formal Security Analysis of OAuth 2.0第3.1节中找到。

上述论文的作者提出以下建议:

  

修复。与OAuth标准中的当前措辞相反,重定向的确切方法不是实施细节,而是OAuth安全性的必要条件。在HTTP标准(RFC 7231)中,仅定义了303重定向,以放弃HTTP POST请求的主体。所有其他HTTP重定向状态代码(包括最常用的302)使浏览器保留POST请求和表单数据的选项。实际上,浏览器通常会重写为GET请求,从而删除表单数据,但307重定向除外。因此,为了解决此问题,OAuth标准应该要求303重定向上述步骤。