http 307重定向
刚才在做hexo页面优化,发现了本地测试返回http 307。以前没见过这个响应码,于是做一下调研。
相关文章:
http 307
在rfc规范中,http 307 Temporary Redirect 是临时重定向。
平时常见的重定向是:
- 301:Permanently Moved,永久重定向
- 302:Temporarily Moved,临时重定向
http 307和302的区别在于:307要求客户端不改变原先的请求方法,对在Location头部中规定的URI进行访问。对于302,很多客户端的实现是,直接使用GET方式访问重定向地址。
例子
客户端请求
1
|
POST /index.php HTTP/1.1
|
服务器端响应
1
|
HTTP/1.1 307 Temporary Redirect
|
那么客户端必须以POST方式重定向访问https://www.example.org/
。
本地测试产生http 307
next的_config.yml
配置
1
|
# Internal version: 2.1.5 & 3.5.7
|
平时写url地址,一般是http或者https,但是next里面的例子都是//
。
//
的意义是,沿用当前页面的协议。如果当前页面是http协议,那么发出去的请求就是http;如果是当前页面是https,那么发出去走https。//
写法的好处是,不需要关注协议,只需要关注URI路径。如果哪一天发生协议变更,比如http升级为全站https,那么代码完全都不用修改。
但是这没有解释为什么返回了http 307。
仔细看看response header,除了Location
指示重定向地址外,还有
1
|
Non-Authoritative-Reason: HSTS
|
HSTS是HTTP严格传输安全(英语:HTTP Strict Transport Security),之前的文章提到过:
因为本地测试,使用http://localhost:4000
访问,所以//
的页面协议是http。但是cloudflare.com开启了HSTS,所有请求都必须是https协议。对cloudflare.com原来的http请求必须升级为https。
事实上,这个307响应不是cloudflare.com产生的,是chrome浏览器干的好事。
The way Chrome shows this in the network tab is by creating a dummy 307 response with a redirect to the https version of the address. But that’s a fake response and is not generated by the server - the reality is Chrome did that internally before the request even went to the server.
注意到,rfc定义http 307是Temporary Redirect,而截图显示的是Internal Redirect。 回想到HSTS只在第1次http访问之后才会生效。如果chrome不做这个返回,会是怎样的流程呢:
- 本地客户端http方式访问cloudflare.com
- 服务器表示要以https方式访问资源
- 于是本地客户端以https方式再次访问cloudflare的资源
中途多了一次网络请求。
因为chrome维护了一份HSTS站点列表,知道cloudflare必须要https方式请求。于是截获http请求后,直接以https方式访问,同时做出dummy 307响应。
小实验
把next的_config.yml
从//
修改为https://
,再测试
直接就是http 200了。
小结
//
比写死具体http、https更加灵活,推荐使用- http 307 Temporary Redirect,临时重定向,客户不能改变请求方式
- chrome知道HSTS站点,会自动把这些站点的http请求改写为https,同时在response header增加
Non-Authoritative-Reason: HSTS
,并且把307响应码解析为Internal redirect
本文作者ycwu314,备份地址 https://ycwu314.github.io/p/http-307/