mirror of
https://github.com/caddyserver/caddy.git
synced 2026-10-05 12:21:36 -04:00
c798d4c238
A request whose body has no length of its own — Transfer-Encoding: chunked, or HTTP/2 and HTTP/3 requests sent without the header — cannot be forwarded over FastCGI until it has been buffered in full, because CGI/1.1 requires CONTENT_LENGTH and php-fpm hangs when it is absent or wrong and the body is not empty. When request_buffers is too small to hold the whole body, the length stays unknown and the request is refused with 411. The refusal said none of that. RoundTrip passes r.ContentLength to Post, which is -1 for such a request, so the operator got a bare "411 Length Required" with either no error at all or strconv's "invalid syntax" on a value they never wrote. On #7386 that sent two people looking for the fault in their backend. The 411 now carries the reason and the remedy, and the unknown-length case is told apart from a genuinely malformed value. ParseUint becomes ParseInt plus an explicit negative check, which is strictly tighter: values above MaxInt64 used to be accepted and are unreachable anyway, since CONTENT_LENGTH is always FormatInt of an int64 by the time Do sees it. No status code changes. Every request that was refused before is still refused; raising request_buffers is still what makes a large chunked body work. Tests: the reachable path through Post, the unusable CONTENT_LENGTH values Do itself guards against, an integration test driving a chunked body through a fastcgi reverse_proxy over a unix socket at each side of the buffer boundary (including request_buffers -1, which succeeds at any size and is the remedy), and a boundary test recording that a body exactly the size of the buffer counts as partial. That last one is deliberately not changed here. Telling "exactly the limit" apart from "more to come" costs a read that a paused stream may never answer, and bufferedBody also backs response_buffers: measured against a body that delivers exactly the limit and stops, the current code hands the buffered prefix on immediately, while peeking one byte first delivers nothing at all. Co-authored-by: Aditya <205600203+Rohilalala@users.noreply.github.com> Co-authored-by: Zen Dodd <mail@steadytao.com>