ContentLengthError raised despite all bytes received: paused parser drops on_message_complete when server closes early (3.14 regression)

[Odacchi]

Describe the bug

Since aiohttp 3.14.0, a client that consumes a large Content-Length response slowly
(e.g. application-level bandwidth throttling with asyncio.sleep between
iter_chunked() reads) fails with a contradictory error when the server sends the
whole body quickly and then half-closes the connection (as Amazon S3 does):

aiohttp.client_exceptions.ClientPayloadError: Response payload is not completed:
<ContentLengthError: 400, message='Not enough data to satisfy content length header
(received 19292859 of 19292859 bytes).'>

Note received == expected — every byte of the body was received and fed to the
parser, yet ContentLengthError is raised.

Root cause analysis (source inspection of 3.14.3)

The regression was introduced by the parser pause machinery added in #11966
(3.14.0). Sequence of events:

1. The application consumes the StreamReader slowly, so the buffer exceeds the
   high-water mark and flow control pauses reading:
   StreamReader → protocol.pause_reading() → the (C) parser sets
   _paused = True.
2. In _http_parser.pyx, cb_on_body feeds the final chunk to the payload and
   then returns HPE_PAUSED because pyparser._paused is set. llhttp stops
   before on_message_complete fires, even though content_length has been
   fully consumed. self._payload therefore stays active.
3. The server (S3) already sent the whole body and half-closed; once the
   transport delivers the close, client_proto.connection_lost() calls
   parser.feed_eof().
4. feed_eof() in _http_parser.pyx only checks the F_CONTENT_LENGTH flag
   and raises unconditionally. At that point cparser.content_length == 0, so
   the message reads "received N of N bytes".

The key asymmetry: the read-until-EOF branch of feed_eof() has an
_eof_pending mechanism that defers EOF handling while the parser is paused,
but the content-length (and chunked) branches do not. The pure-Python parser
(http_parser.py, HttpPayloadParser.feed_eof) has the same asymmetry.

3.13.5 is not affected: its parser has no pause state, so the fully-fed body
completes the message immediately.

To Reproduce

Deterministic self-contained reproduction (verified: fails on 3.14.3, completes
on 3.13.5). TLS is required — with plain TCP the paused transport defers the
EOF, but SSLProtocol keeps delivering already-buffered decrypted data and the
close while the application-level transport is paused, which is exactly the S3
situation. A large SO_SNDBUF lets the server hand the whole body to the
kernel and close immediately (early close, like S3).

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 1 \
  -nodes -subj "/CN=127.0.0.1"
python repro.py

# repro.py — aiohttp 3.14.3: ClientPayloadError/ContentLengthError
#            aiohttp 3.13.5: prints "done 6000000"
import asyncio
import pathlib
import socket
import ssl

import aiohttp

HERE = pathlib.Path(__file__).parent
SIZE = 6_000_000
THROTTLE_BPS = 200_000  # slow consumer -> flow-control pause


async def serve(reader: asyncio.StreamReader, writer: asyncio.StreamWriter) -> None:
    sock = writer.get_extra_info("socket")
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 8 * 1024 * 1024)
    await reader.readline()
    writer.write(b"HTTP/1.1 200 OK\r\nContent-Length: %d\r\n\r\n" % SIZE + b"x" * SIZE)
    await writer.drain()
    writer.close()  # close right after the last byte reaches the kernel, like S3


async def main() -> None:
    server_ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
    server_ctx.load_cert_chain(HERE / "cert.pem", HERE / "key.pem")
    server = await asyncio.start_server(serve, "127.0.0.1", 8443, ssl=server_ctx)
    async with server:
        async with aiohttp.ClientSession(
            connector=aiohttp.TCPConnector(ssl=False)
        ) as session:
            async with session.get("https://127.0.0.1:8443/") as resp:
                n = 0
                loop = asyncio.get_running_loop()
                start = loop.time()
                async for chunk in resp.content.iter_chunked(64 * 1024):
                    n += len(chunk)
                    expected = n / THROTTLE_BPS
                    elapsed = loop.time() - start
                    if expected > elapsed:
                        await asyncio.sleep(expected - elapsed)
                print("done", n)


asyncio.run(main())

Originally observed downloading ~19 MB objects from S3 via presigned HTTPS URLs
with 3 concurrent throttled downloads (41.7 KB/s each): the first download to
enter the "server finished sending, client still draining" state failed nearly
every cycle.

Expected behavior

The response completes successfully: all bytes were received; a paused parser
receiving EOF after the body is fully fed should complete the message (or defer
EOF like the read-until-EOF branch does) instead of raising ContentLengthError.

Logs/tracebacks

aiohttp.client_exceptions.ClientPayloadError: Response payload is not completed:
<ContentLengthError: 400, message='Not enough data to satisfy content length header
(received 19292859 of 19292859 bytes).'>

Python Version

3.12 / 3.14 (reproduced on both)

aiohttp Version

3.14.3 (regression introduced in 3.14.0; 3.13.5 unaffected)

Related

• Allow decompression to continue after exceeding max_length #11966 (pause machinery introduction, 3.14.0)
• Improve ContentLengthError messages to show expected vs received bytes #12753 (added received/expected bytes to the error message, which is how the
  contradictory "received N of N" became visible)
• sock_read timeout is re-armed on a keep-alive connection after it returns to the pool, poisoning it (regression in 3.14) #12953, DeflateBuffer.feed_data raises IndexError on empty chunks #12994, Fix segfault when decompression fails while draining pending data #13249 (other 3.14 issues in the same pause/drain machinery)

OS

Linux (Raspberry Pi OS / Debian), also reproduced on macOS

Additional context

Workarounds we found: pin aiohttp<3.14, avoid long draining windows
(range-split downloads), or raise read_bufsize above the object size so flow
control never pauses.

[adityaanikam]

Traced both parsers on current main and the asymmetry is exactly as you found it. In _http_parser.pyx::feed_eof (~line 598) the F_CONTENT_LENGTH branch raises unconditionally using self._cparser.content_length, with no self._paused check at all, while the fallback branch a few lines down has the full _paused deferral loop. Same shape in http_parser.py's HttpPayloadParser.feed_eof: PARSE_LENGTH raises immediately while PARSE_UNTIL_EOF defers. I think the fix is applying the same deferral pattern to the length/chunked branches: if self._paused when EOF arrives, don't raise yet, let it resume via feed_data(b"") like the other branch already does, and only raise if it's still incomplete after that. Want me to take a pass at this in both parsers, or would you rather scope it further first given it touches the C-extension?