HTTP请求重定向到HTTPS时POST请求被改成GET

背景

昨天平台域名从HTTP切换到HTTPS，切换上线后，部分openapi接口因业务轮询导致持续报错，经简单排查之后发现测试环境的openapi请求正常，正式环境的openapi报错。

同时经过查看日志发现，正式环境中从openapi请求到portal的请求，method从post变成了get，导致portal侧匹配不到对应的路由而报错。

将openapi请求到portal侧的域名改成https后，问题修复

问题分析

由于在切换https之后，对旧域名做了重定向，所以openapi在请求http域名时，请求被重定向到https的域名了，而这个过程中，会将post请求转成get。

参考文档，关于301状态码是这样描述的，尤其是粗体部分：

Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.

当一个POST请求在收到301状态码之后会自动重定向，某些HTTP/1.0的代理会错误地将其转换成GET请求

这还不是重点，继续往下看，在302状态码的描述中：

Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

RFC1945和RFC2068指出，在重定向请求时，客户端不允许修改请求方法。但是，大多数的代理在实现过程中会将302当做303处理，即无论原请求的方法是什么，都将执行一个GET请求。

在303状态码的描述中：

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource.

请求响应如果在其它URI下可以被找到的话，应该使用一个GET请求去获取资源。

因此，在整个过程中，应该是如下流程：

1. openapi发起对portal的HTTP请求
2. 得到301或302的状态码并要求重定向到HTTPS
3. 无论是302还是303，将按照303处理
4. 请求HTTPS的资源并将请求方法改成GET，并丢弃所有的参数

总结

在页面上的请求不会有问题，因为切换完之后，页面的请求都是https了，而openapi转发的请求的域名需要配置，所以在类似的情形下，应该在切换之后立即修改openapi的配置以防出现上述问题