[Nginx] 3.由HTTP转发引出的重定向问题
问题背景
最近在调试接口时遇到了一个奇怪的问题：在 Postman 进行调试的时候，使用 HTTPS 协议 POST 请求一切正常，但切换到 HTTP 协议后却报错，并且，错误信息显示请求方法变成了GET，而后端日志显示所有参数的非空校验都失败。
经过一些分析以及排查，排除了代码本身的问题，将问题定位到了 Nginx 转发上。
考虑到安全性，会强制将所有的 HTTP 请求转为 HTTPS，配置如下：
server {listen 80;server_name nginx localhost 127.0.0.1;rewrite ^(.*)$ https://$host$1 permanent;
}
HTTP重定向的工作流程
- 步骤一：由客户端发送 HTTP POST请求
POST http://api.example.com/login
Body: {"username":"admin","password":"123456"}
- 步骤二：Nginx 检测到 HTTP，返回301重定向响应
HTTP/1.1 301 Moved Permanently
Location: https://api.example.com/login
- 步骤三：客户端自动发起新的GET请求
GET https://api.example.com/login
- 步骤四：服务器收到GET请求
- 期待POST方法，但收到GET
- 请求体为空 → 所有参数为null
在第三步中，客户端自动将请求方法从 POST 改成了 GET。这里是涉及到了一个历史中的默认行为。HTTP/1.0规范中对301/302重定向的处理描述比较模糊，但大家约定俗成：301-资源永久移动，302-临时处于不同位置。因此，在浏览器以及 HTTP 客户端在实现时，出于简化考虑，决定对于301/302响应，自动将重定向请求的方法改为GET。
这么做的原因也是考虑到安全性，因为，一般GET方法偏向于请求数据，相比于POST的提交表单等操作，相对而言更加安全，以及幂等性。
对于这个问题，在1.1中引入了 307 和 308 两个新的状态码，可以保留原方法以及请求体。
深入理解：Redirect vs Rewrite
上面的内容实际上已经将问题说的比较清楚了，但要彻底理解这个问题，还需要区分两个概念：
- Redirect：重定向
- 服务器告诉客户端"请换个地址重新请求"
- 客户端感知，地址栏变化
- Rewrite：重写
- 服务器内部修改请求路径，客户端无感知
- 完全在服务器内部完成
- 例如：
rewrite ^/api/(.*)$ /internal/$1 break;
参数处理的差异
URL查询参数（?key=value）
会被保留，因为 Nginx 能够自动追加查询字符串
原始请求：http://api.com/login?token=abc
重定向后：https://api.com/login?token=abc
请求体参数（Body数据）
浏览器/客户端会丢弃原始POST的body数据，同时，转化为 GET 方法，导致完全丢失。
解决方法
方法一：避免HTTP请求
直接使用HTTPS协议，从根本上避免重定向
方法二：使用307/308重定向
保留原始请求方法和请求体
server {listen 80;server_name api.example.com;# 使用307临时重定向，保留POST方法和bodyreturn 307 https://api.example.com$request_uri;
}
方法三：避免重定向
Nginx 同时监听 80 和 443 端口，避免重定向。
方法四：使用重写而不是重定向
# 重写配置
location /submit/ {rewrite ^/submit/(.*)$ /backend/handle/$1 break;proxy_pass http://backend_server;
}