passerbyabc commented on issue #13673:
URL: https://github.com/apache/apisix/issues/13673#issuecomment-5350842783

   ## Additional reproduction (production, K3s + APISIX Ingress)
   
   Same regression as this issue. Confirmed it is **not** an actually-oversized 
body.
   
   ### Environment
   - APISIX on K3s (Ingress Controller), TLS terminated at APISIX
   - `nginx.conf` has `client_max_body_size 0;` (unlimited, default)
   - HTTP/1.1 POST from a Spring `RestTemplate` webhook client
   - Route: third-party callback `POST /callback/...` → HTTP upstream
   
   ### Access log (redacted)
   ... "POST /callback_api/... HTTP/1.1" 413 255 0.018 "-" "" - - -
   `upstream_addr` / `upstream_status` / `upstream_response_time` are all `-` → 
rejected in APISIX, never forwarded.
   
   ### Error log (redacted)
   client intended to send too large chunked body: 0+311 bytes, ... request: 
"POST /callback/... HTTP/1.1", host: "xxx.xxx.com"
   First chunk is only **311 bytes**. The `0+` matches `client_max_body_size 0` 
treated as a literal 0-byte quota on the chunked path.
   
   ### Temporary workaround
   
   Leaving the global limit at `0` still 413s **any** non-empty chunked POST. 
Setting a **non-zero** limit unblocks it.
   
   **Option A (what we used): route-level `client-control`** — ApisixRoute / 
Admin API, no APISIX restart:
   
   ```yaml
   plugins:
     - name: client-control
       enable: true
       config:
         max_body_size: 10485760   # 10MiB; must be != 0
   
   After this, the same webhook returned 200 and upstream_* was populated.
   
   Option B (global, as in this issue): non-zero client_max_body_size — 
requires rendering nginx.conf and restarting APISIX:
   
   nginx_config:
     http:
       client_max_body_size: 100m   # must be != 0; do not use 0
   We prefer A until a runtime image that includes api7/apisix-nginx-module#115 
is available.
   
   ### Question
   Which released APISIX / apisix-runtime image includes 
api7/apisix-nginx-module#115 so we can drop the route workaround?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to