如何允许空POST请求体/避免GCP负载均衡返回411错误

当发送不带Content-Length头的空POST请求时，GCP HTTP(S)负载均衡器（通过GKE Ingress创建）会返回411 Length Required错误，示例请求及错误如下：

$ curl -L -X POST 'http://example.com/fund?amount=0'

返回的错误页面：

<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>411 Length Required</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Length Required</h1>
<h2>POST requests require a <code>Content-length</code> header.</h2>
<h2></h2>
</body></html>

在无法修改客户端的情况下，可通过以下几种方式让负载均衡器接受这类请求：

方案一：为Pod添加Nginx Sidecar代理 #

在GKE Deployment中给目标服务的Pod增加一个Nginx容器作为前置代理，自动为无Content-Length的空POST请求补全该头：

1. 编写Nginx配置文件（保存为nginx.conf）：

server {
    listen 8080;
    location / {
        # 对POST请求检查Content-Length，为空则添加Content-Length:0
        if ($request_method = POST) {
            if ($content_length = "") {
                add_header Content-Length 0;
            }
        }
        # 转发请求到主服务的端口（假设主服务监听8000）
        proxy_pass http://localhost:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

2. 更新Deployment的Pod模板，添加Nginx容器，并将Ingress的目标端口改为8080（Nginx监听的端口）。

方案二：配置GCP负载均衡器的请求改写规则 #

直接通过GCP负载均衡的请求改写功能，为符合条件的请求插入Content-Length:0头：

使用gcloud命令更新后端服务（替换BACKEND_SERVICE_NAME为你的后端服务名称）：

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --global \
    --add-request-header-override "Content-Length:0" \
    --condition='request.method == "POST" && !request.headers.containsKey("Content-Length")'

注意：条件语法需符合GCP负载均衡的规则，若上述条件不生效，可调整为检查Content-Length头为空的情况。

方案三：通过服务网格（如Istio）处理请求 #

如果你的集群已部署Istio等服务网格，可通过VirtualService配置为目标请求添加缺失的头：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: example-fund-service
spec:
  hosts:
  - example.com
  http:
  - match:
    - method:
        exact: POST
      headers:
        Content-Length:
          notPresent: true
    route:
    - destination:
        host: fund-service
    headers:
      request:
        set:
          Content-Length: "0"

方案对比 #

• Sidecar代理：无需依赖额外GCP服务，仅针对单个服务生效，配置灵活，但会增加Pod资源开销。
• LB请求改写：全局生效，无需修改Pod配置，但需要有负载均衡的管理权限，且条件语法有一定限制。
• 服务网格：适合已使用服务网格的集群，可统一管理请求规则，但需要熟悉Istio的配置。

内容的提问来源于stack exchange，提问作者Daniel Porteous