POST请求慎用301 Moved Permanently

在全站启用HTTPS的过程中,遇到一个坑,在此做下记录。在全站支持HTTPS以后,用户可能还会使用http访问,所以很多建议使用301 Moved Permanently+HSTS( Strict Transport Security Policy)的方式要求用户跳转到HTTPS后再访问。

然而,对于有POST请求的域名是不适合用301 Moved Permanently的,关于post请求重定向用户确认的问题,实际上浏览器都没有实现;而且post请求的重定向应该发起post请求,这里浏览器也并不一定遵守,所以说HTTP规范的实现并未严格按照HTTP规范的语义。如下图所示。 
这里写图片描述
所以这种情况,一个POST请求经过301后可能就变为GET请求。而很多服务端是对METHOD有严格限制的,万一限制只接受POST请求,对GET请求就会响应405错误,悲剧就产生了。

那么POST请求应该如何解决跳转问题呢?

HTTP/1.1 301 Moved Permanently: 301状态码在HTTP 1.0和HTTP 1.1规范中均代表永久重定向,对于资源请求,原来的url和响应头中location的url而言,资源应该对应location中的url。对于post请求的重定向,还是需要用户确认之后才能重定向,并且应该以post方法发出重定向请求。 
关于post请求重定向用户确认的问题,实际上浏览器都没有实现;而且post请求的重定向应该发起post请求,这里浏览器也并不一定遵守,所以说HTTP规范的实现并未严格按照HTTP规范的语义。 
在301中资源对应的路径修改为location的url,在SEO中并未出现问题,但是在302中就出现了302劫持问题,请往下看。 
HTTP/1.1 302 Found:在HTTP1.0规范中,302表示临时重定向,location中的地址不应该被认为是资源路径,在后续的请求中应该继续使用原地址。 
规范:原请求是post,则不能自动进行重定向;原请求是get,可以自动重定向; 
实现:浏览器和服务器的实现并没有严格遵守HTTP中302的规范,服务器不加遵守的返回302,浏览器即便原请求是post也会自动重定向,导致规范和实现出现了二义性,由此衍生了一些问题,譬如302劫持,因此在HTTP 1.1中将302的规范细化成了303和307,希望以此来消除二义性。 
补充:302劫持——A站通过重定向到B站的资源xxoo,A站实际上什么都没做但是有一个比较友好的域名,web资源xxoo存在B站并由B站提供,但是B站的域名不那么友好,因此对搜索引擎而言,可能会保存A站的地址对应xxoo资源而不是B站,这就意味着B站出了资源版权、带宽、服务器的钱,但是用户通过搜索引擎搜索xxoo资源的时候出来的是A站,A站什么都没做却被索搜引擎广而告之用户,B站做了一切却不被用户知道,价值被A站窃取了。 
作为HTTP1.1的标准,以前叫做Moved Temporarily ,现在叫Found. 现在使用只是为了兼容性的处理,包括PHP的默认Location重定向用的也是302. 
但是HTTP 1.1 有303 和307作为详细的补充,其实是对302的细化 
HTTP/1.1 303 See Other:对于POST请求,它表示请求已经被处理,客户端可以接着使用GET方法去请求Location里的URI。 
HTTP/1.1 307 Temporary Redirect:对于POST请求,表示请求还没有被处理,客户端应该向Location里的URI重新发起POST请求。

所以,对待POST请求,我们可以使用307跳转的方式来解决。

--------------------- 作者:皖南笑笑生 来源:CSDN 原文:https://blog.csdn.net/zhuyiquan/article/details/78712332?utm_source=copy 版权声明:本文为博主原创文章,转载请附上博文链接!

没有更多推荐了,返回首页