Drop held input of a body cut off by the close - #2386

Summary

• Part of the second follow-up promised on fix(netty): stop inflating a suspended HTTP/1.1 response #2362 (discussion), output left over when the connection closes.
• When the connection closes while a suspended HTTP/1.1 response holds compressed input back, and the body has not ended, that input is now dropped instead of decompressed and handed on at once. That response cannot complete anyway. The same goes for a body whose last chunk could not be parsed; its failed end is still handed on, so the request fails with the parser's error.
• A body that has ended is handed on at the close as before. That is the case from the discussion, so this does not finish the follow-up; see "Still open" below.

Problem

Http1ContentDecompressor holds compressed input back while a response is suspended. When the connection closes, Netty tears the pipeline down in the same task, so on main everything held back is decompressed and handed on at once, bounded only by maxDecompressedResponseSize.

For a body that the close cut off, a Content-Length or chunked body that never reached its end, that is wasted work: the response cannot complete, and AHC fails the request (RemotelyClosedException) or retries it right after. A suspended handler still receives the whole remainder first.

Whether an orderly close by the server (a TCP FIN) is noticed while the response is suspended depends on the transport. A handler that suspends after its first part and never resumes, 16 MiB of zeros as gzip, and a server that closes the connection:

NIO honors auto-read, so it reads nothing, the close included, until a resume. epoll keeps reading after EPOLLRDHUP regardless of auto-read (EpollRecvByteAllocatorHandle.continueReading), io_uring behaves the same here, and so does kqueue (KQueueRecvByteAllocatorHandle.continueReading), so they read everything the server sent before its close. AHC selects epoll on Linux whenever the native library is on the classpath. A close on the client's side, for example when the client is closed, reaches the decompressor on every transport.

Change

• In channelInactive, the input held back is decompressed only if the body has ended successfully: a LastHttpContent with a successful decoder result, held with the input or queued behind it. That covers the end of a body delimited by the connection, which HttpObjectDecoder hands on just before the close. Otherwise the input is dropped with the rest of the response state.
• A last chunk that failed to parse is the end of a broken body. Its input is dropped too, and the failed end is still handed on, so that HttpHandler fails the request with the parser's error, without a retry.
• A dropped body is not decompressed first, so a corrupt or oversized remainder no longer fails it with a DecompressionException, which is never retried. A body that the close cut off is handled like any other whose connection closed before the end of its body: it is retried (maxRequestRetry, or an IOExceptionFilter that replays it) or fails with a RemotelyClosedException, and the IOExceptionFilters see a ChannelClosedException. As for a body without a content coding, the method does not decide whether it is retried, so a POST can be retried too.
• The Javadoc of ResponseBodyControl.suspend() and of the class say so. suspend() also says that after an orderly close by the server, epoll, io_uring and kqueue read what is left even while reads are suspended, so a body without a content coding that arrived before the close is delivered in full, and that NIO reads nothing until a resume.

Still open: a body that has ended, including one delimited by the connection, is still decompressed and handed on at once when the connection closes while its input is held back, on native transports, bounded by maxDecompressedResponseSize as the Javadoc already said. Keeping it to demand needs the input held back to outlive the close. Either the channel allows half-closure, so that the server's close only shuts its input down and the pipeline stays until the body has been delivered and the channel is closed, or the input held back is moved out of the pipeline before it is torn down. Either is a larger change, left for a separate PR. HTTP/2 is separate.

AI disclosure

Claude Code on behalf of Matthias Kurz. The commits include Co-Authored-By per AGENTS.md.

Test plan

• Fail on main, pass with this PR. The epoll tests were run against main's code, where all four cases fail with the size limit's DecompressionException. The unit tests use a test hook that main lacks, so they were checked with main's close handling put back:
  • Http1ContentDecompressorSuspensionTest.inputHeldBackOfABodyThatTheCloseCutsOffIsDropped (gzip, deflate, br, zstd, snappy): a body without its end, suspended after its first part, with a limit that decompressing the rest would exceed. 512 KiB of random bytes, so that input is also queued behind the input held back for every coding, which the test checks. At the close nothing more is handed on, no error, every input buffer released, and channelInactive passed on.
  • Http1ContentDecompressorSuspensionTest.inputHeldBackOfABodyWhoseLastChunkFailedIsDroppedAtTheClose (same five codings and payload): a failed last chunk queued behind the input held back. At the close nothing more is handed on, and the end is handed on with the parser's error.
  • Http1DecompressionSuspensionTest.aSuspendedBodyThatTheConnectionCutsOffFailsWithoutTheRestOfIt (Linux with epoll; a Content-Length and a chunked body, half of it sent, then closed; no retries): the handler gets 1 part, the request fails with RemotelyClosedException, and the IOExceptionFilter sees one ChannelClosedException.
  • Http1DecompressionSuspensionTest.aSuspendedBodyThatTheConnectionCutsOffIsRetried (epoll, a GET, default retries): the server sees 1 + maxRequestRetry requests, each delivers its first part only, and the request then fails with RemotelyClosedException.
  • Http1DecompressionSuspensionTest.aSuspendedBodyWhoseLastChunkCannotBeParsedFailsWithTheParsersError (epoll; half a chunked body, then zz as the chunk size line, then the close; 1 MiB limit, default retries): the handler gets 1 part, the request fails with the NumberFormatException from HttpObjectDecoder, and the server sees 1 request.
• Pass on main and with this PR:
  • Http1ContentDecompressorSuspensionTest.inputHeldBackOfABodyThatHasEndedIsHandedOnAtTheClose (gzip, zstd; the end of a body delimited by the connection): the whole body is handed on at the close, then the end.
  • channelClosureHandsOnHeldInputBeforeChannelInactive, aTruncatedBodyHeldWhenTheConnectionClosesFails and aHeldDirectInputIsReleasedWhenTheResponseEndsEarly, for a held last chunk.
• Each change breaks the tests it should:
  • counting a failed end as the end, as the first commit did: the two failed-chunk tests fail;
  • counting any queued message as the end: inputHeldBackOfABodyThatTheCloseCutsOffIsDropped fails for all five codings, and so do the epoll tests;
  • dropping a failed end instead of handing it on: the two failed-chunk tests fail.
• ./mvnw -B -ntp -Dgpg.skip=true clean verify on JDK 11: 2,009 tests, 0 failures, 0 errors, 11 skipped; Revapi passed. No test-skipping flags were used.
• The Http1ContentDecompressor*Test, Http2ContentDecompressorTest, Http1Decompression*Test and ResponseBodyControlTest classes compiled on JDK 11 and run on JDK 17, 21 and 25 (Maven Surefire's -Djvm): 140 tests each, 0 failures.