【问题标题】:When following 302 redirect after domain forward, subsequent get requested back to original domain, causing a loop域转发后跟随302重定向,后续get请求返回原域,造成循环
【发布时间】:2016-05-05 21:29:55
【问题描述】:

http://example.com的第一个请求:

GET / HTTP/1.1
Host: example.com
Connection: close
User-Agent: Paw/2.3.3 (Macintosh; OS X/10.11.4) GCDHTTPRequest

此时,DNS 通过 302 将请求转发到 https://www.example.com。 (注意协议更改)

HTTP/1.1 302 Found
Location: https://www.example.com

此时 Paw 发出以下请求(此时为 https):

GET / HTTP/1.1
Host: www.example.com

并得到以下响应:

HTTP/1.1 302 Found
Server: Cowboy
Connection: close
X-Powered-By: Express
X-Frame-Options: SAMEORIGIN
Location: /verify-age

这就是事情变得有趣的地方。没有主机名信息的那个位置实际上向原始主机名和协议发出了下一个请求! (现在返回 http 请求这个请求?!):

GET /verify-age HTTP/1.1
Host: example.com

这会被 DNS 服务器拦截,当然会以 302 响应:

HTTP/1.1 302 Found
Location: https://www.example.com

回到正确的协议和 url,但循环当然会回到 302 重定向到 /verify-age,它会切换回原始协议和主机名!我们陷入了这个循环。奇怪的是 Chrome 没有遵循这个循环,但 Paw 遵循了。那么这里的坏人是谁呢?域名系统?爪子?节点?铬?

【问题讨论】:

标签: http dns paw-app


【解决方案1】:

这很有趣。虽然RFC2616 要求Location 标头字段值由单个绝对URI (Location = "Location" ":" absoluteURI) 组成,但在RFC7231 中进行了修改,放松了原始约束,允许使用相对URL (Location = URI-reference),位置值计算参考RFC3986

在第 5.1 节 RFC3986 中明确指出:

请注意,如果检索是重定向请求的结果, 最后使用的 URI(即,导致实际检索的 URI 表示的) 是基本 URI。

所以我的猜测是,向原始主机名发出下一个请求的浏览器在这里是错误的。

【讨论】:

    【解决方案2】:

    更新:此错误已在 Paw 2.3.4 中修复


    我确认这是 Paw 的错误,我自己已经能够重现此错误。我们将在 Paw 的下一个错误修复版本中修复这个问题,希望在 10 天内发布。感谢您报告此问题,对于给您带来的不便,我们深表歉意。

    【讨论】:

      猜你喜欢
      • 2016-08-27
      • 2018-02-14
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-11-26
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多