[mkurz]

Summary

• Upgrades zstd-jni to 1.5.7-26. That version fails a zstd stream that is cut inside a frame that started in the same read as the end of the previous frame (Detect a truncated frame that starts in buffered input luben/zstd-jni#435).
• AHC no longer lets such a body complete, which closes the zstd gap from the Fail a compressed body that is cut off #2376 review (discussion).
• Adds a test for that cut and one for two complete frames in one chunk.
• Limits the note in the README and the Http1ContentDecompressor Javadoc to zstd-jni before 1.5.7-26, and recommends 1.5.7-26 or later.

Problem

Since #2376, a compressed HTTP/1.1 body that ends inside its compressed stream fails the request. One zstd case was documented as not noticed: a body of several frames completed when it was cut inside a frame that started in the same chunk as the end of the previous one.

zstd-jni set a flag when a frame finished and cleared it only on its next read from the source. A frame that started in input zstd-jni had already read was decoded with the flag still set, so the end of the input looked like a clean end at a frame boundary. AHC hands zstd-jni one chunk per read, so such a body completed and the rest of it was lost without an error.

Change

• zstd-jni.version goes from 1.5.7-25 to 1.5.7-26.
• Two new tests in Http1ContentDecompressorTest, with heap and direct buffers:
  • zstdBodyCutInAFrameThatStartedInTheChunkThatEndedThePreviousOneFails sends a first frame and half of a second. It uses three splits, each with the end of the first frame and the start of the second in the same chunk: all in one last chunk, all in one chunk followed by an empty last chunk, and a split inside the first frame. The Content-Length matches the bytes sent, so the HTTP body is complete and only the zstd stream is cut. The test expects a DecompressionException.
  • zstdFramesThatShareAChunkDecodeInFull sends both frames complete, with the same splits, and expects the whole body.
• README and Javadoc: the note now applies only to zstd-jni before 1.5.7-26. zstd-jni is an optional dependency, so the application's own version is the one used. The README therefore recommends 1.5.7-26 or later, and its example dependency shows that version (it showed 1.5.7-7).

The other gaps the README describes are unchanged:

• a snappy body cut between two of its chunks;
• HTTP/2 bodies;
• transfer codings;
• bodies decompressed as soon as they are read.

Dependabot's monthly update would bump the version as well; this PR adds the tests and the documentation change on top.

AI disclosure

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

Test plan

• Fail with zstd-jni 1.5.7-25 (-Dzstd-jni.version=1.5.7-25), pass with this PR:
  • zstdBodyCutInAFrameThatStartedInTheChunkThatEndedThePreviousOneFails, on JDK 11 (JNI) and JDK 25 (FFM). With 1.5.7-25, all 6 cases (3 splits, heap and direct) end normally without an error; with 1.5.7-26, all 6 fail with DecompressionException.
• Pass with both versions:
  • zstdFramesThatShareAChunkDecodeInFull, on JDK 11 and JDK 25.
• On JDK 25 the tests ran zstd-jni's FFM implementation: the test JVM loaded com.github.luben.zstd.ZstdBinding, which only exists in that implementation (checked with -Xlog:class+load).
• ./mvnw -B -ntp -Dgpg.skip=true clean verify on JDK 11: 1,996 tests, 0 failures, 0 errors, 11 skipped; Revapi passed. No test-skipping flags were used.