brbzull0 opened a new pull request, #12817: URL: https://github.com/apache/trafficserver/pull/12817
While fixing another issue I came across the following crash: ``` Fatal: /users/me/git/trafficserver/src/proxy/http/HttpSM.cc:6017: failed assertion `_ua.get_entry()->vc == _ua.get_txn()` NOTE: using the environment variable TS_RUNROOT [Jan 15 11:05:27.273] traffic_crashlo NOTE: crashlog started, target=223449, debug=false syslog=true, uid=1000 euid=1000 [Jan 15 11:05:27.273] traffic_crashlo NOTE: logging to 0x7674e0 [Jan 15 11:05:27.465] traffic_crashlo ERROR: wrote crash log to /tmp/_snbx-tcl/post-body-too-large-413/ts/log/crash-2026-01-15-110527.log traffic_server: received signal 6 (Aborted) traffic_server - STACK TRACE: /tmp/_snbx-tcl/post-body-too-large-413/ts/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xce)[0x90db1d] /lib64/libc.so.6(+0x3e9a0)[0x7f760085c9a0] /lib64/libc.so.6(+0x90834)[0x7f76008ae834] /lib64/libc.so.6(raise+0x1e)[0x7f760085c8ee] /lib64/libc.so.6(abort+0xdf)[0x7f76008448ff] ``` and it happens when a request body exceeded `proxy.config.http.post_copy_size` during buffering, as the above ATS would crash or _maybe_(couldn't get this) return incorrect error responses (403??). So, after some(heavy) back and forth with `Claude(AI)` we came across this fix. **My main question here is, does it make sense to try to respond `413` in this case as earlier as possible?** ### Summary This PR fixes the handling of oversized POST request bodies when `proxy.config.http.request_buffer_enabled` is true. ### Problem When request buffering is enabled, ATS buffers the POST body . If the body exceeds post_copy_size: - Chunked requests: ATS would trigger VC_EVENT_ERROR in the tunnel, causing state corruption and either a crash (_ua.get_entry()->vc == _ua.get_txn() assertion) or a 403 Forbidden response. - Requests with Content-Length: The size wasn't checked upfront, so ATS would start buffering only to fail mid-stream. - Requests with Expect: 100-continue: ATS would send "100 Continue" before checking the body size, causing clients to transmit oversized bodies that would ultimately be rejected—wasting bandwidth. ### Solution For requests with known Content-Length: - Check Content-Length against post_copy_size upfront in HttpTransact::HandleRequest() - For Expect: 100-continue requests, check before sending "100 Continue" in state_read_client_request_header() For chunked requests (size unknown upfront): - Detect overflow during buffering in HttpTunnel - Set request_body_too_large flag and use HTTP_TUNNEL_EVENT_PRECOMPLETE for graceful tunnel completion - HttpSM::tunnel_handler_post() checks the flag and calls HttpTransact::PostBodyTooLarge() to send 413 __NOTE__: I've changed `post_slow_server.test.py` so it runs in CI, it does ok locally, but just in case. I will be removing it after it runs. -- 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]
