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跳转的方式来解决。

参考：
http://blog.csdn.net/reliveit/article/details/50776984 【HTTP】http重定向301/302/303/307
http://blog.csdn.net/akon_vm/article/details/50418996 HTTP 的重定向301,302,303,307（转）