HTTP重定向带来的三次坑

时间：2023-02-09 13:09:01 | 来源：建站知识

时间：2023-02-09 13:09:01 来源：建站知识

老司机啊！耻辱啊！被坑一次也就算了，那时候还年轻。。这三次就很蛋疼了。。。我们来看三次被坑的经历。都和HTTP重定向有关

第一次的场景：

线下测试一切正常，上线后功能失效，提不上去。控制台显示的是 从https发起了http请求。

按照常理分析，俺们的ajax不会直接跨度那么大。。。仔细看了一下里面出现了一个重定向。。。算是粗心造成的：对一些设置时写了斜杠/ 的地址，但请求时不加这个斜杠，Django默认会使用重定向 放到带斜杠的/的地址上。而Django在默认不配置的时候，这个重定向的location会放在http协议上(因为https的请求在nginx那层就被剥开了，往后面的upstream转的时候已经变成了http)

第二次的场景：

内部服务间HTTP 调用接口，发现发出去的时候请求体还各种正常，但接收方收到的时候请求体全没了。。。

第三次的场景：

使用SSO进行登录，恰逢域名迁移(且没有收到通知，淡淡的忧伤，这就是没有存在感），登陆完进行回调的时候，原域名使用301重定向，把POST回调请求重定向了。结果导致使用了GET方法访问了回调地址，并且请求体全没了。


从HTTP标准来说：

301: Permanent redirect. Clients making subsequent requests for this resource should use the new URI. Clients should not follow the redirect automatically for POST/PUT/DELETE requests.

302: Redirect for undefined reason. Clients making subsequent requests for this resource should not use the new URI. Clients should not follow the redirect automatically for POST/PUT/DELETE requests.

303: The resource can be retrieved by following other URI using the GET method. When received in response to a POST, PUT, or DELETE, it can usually be assumed that the server processed the request successfully and is sending the client to an informational endpoint.



307: HTTP 1.1. The request should be repeated with the URI provided in the response, but future requests should still call the original URI.



301和302在PUT、POST、DELETE方法的时候，虽然标准里说不应该自动跟随，不过现在的httpclient库和浏览器通常都做成跟随，但第二个请求都会改成GET方法，请求体自然的就失去了

303没试过，照这个意思，客户端是当做服务器端已经处理完了这个请求，那么请求体按道理应该也是不带过去的

307和302都是临时重定向，区别是307会换个地址，重复对应的那个请求。

得到的教训就是：

1. 服务器端发重定向的时候，想一想是否允许对POST 进行重定向，请求又是否允许重放
2. 客户端发请求的时候，尽量避免被重定向。。