Return 413 when POST body exceeds post_copy_size during request buffering

[brbzull0]

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.

[brbzull0]

filter_body test seems to be failing. Invetigating. fine now.