Test failure: GetAsync_Chunked_VaryingSizeChunks_ReceivedCorrectly fails with 'invalid chunk line ending' on all platforms (regression from #131138)

[rzikm]

Test failure

System.Net.Http.Functional.Tests — GetAsync_Chunked_VaryingSizeChunks_ReceivedCorrectly is failing across all platforms in outerloop, starting 2026-08-06.

Affected variants (all fail with the same error):

• SocketsHttpHandler_HttpProtocolTests.GetAsync_Chunked_VaryingSizeChunks_ReceivedCorrectly
• SyncHttpHandler_HttpProtocolTests.GetAsync_Chunked_VaryingSizeChunks_ReceivedCorrectly
• SocketsHttpHandler_HttpProtocolTests_Dribble.GetAsync_Chunked_VaryingSizeChunks_ReceivedCorrectly
• SyncHttpHandler_HttpProtocolTests_Dribble.GetAsync_Chunked_VaryingSizeChunks_ReceivedCorrectly

Error message

System.Net.Http.HttpIOException : Received an invalid chunk line ending. Chunked encoding lines must be terminated by CRLF. (InvalidResponse)

Frequency

~19 builds per variant (76 total) on main over the past 7 days, all 17 CI queues (Windows, Linux, macOS, Alpine, Android). Sharp onset on Aug 6; zero occurrences before.

Root cause

This is a test bug, not a product regression. It is the direct, expected consequence of PR #131138 ("Strictly require CRLF when parsing HTTP/1.1 chunked encoding lines", merged Aug 5), which per RFC 9112 made SocketsHttpHandler reject a lone LF as a chunk line terminator.

The failing test drives a loopback test server that deliberately emits chunk framing using a parameterized line ending, and one of the parameter values is a bare LF:

src/libraries/Common/tests/System/Net/Http/HttpProtocolTests.cs

public static IEnumerable<object[]> GetAsync_Chunked_VaryingSizeChunks_ReceivedCorrectly_MemberData()
{
    foreach (int maxChunkSize in new[] { 1, 10_000 })
        foreach (string lineEnding in new[] { "\n", "\r\n" })   // <-- "\n" (bare LF)
            foreach (bool useCopyToAsync in new[] { false, true })
                yield return new object[] { maxChunkSize, lineEnding, useCopyToAsync };
}

The loopback server then writes chunk-size lines and chunk terminators using that lineEnding:

await connection.WriteStringAsync($"{bytesToSend:X}{lineEnding}");   // chunk-size line
await connection.Stream.WriteAsync(...);
await connection.WriteStringAsync(lineEnding);                       // chunk data terminator
...
await connection.WriteStringAsync($"0{lineEnding}");                 // last chunk
await connection.WriteStringAsync(lineEnding);

For the lineEnding == "\n" cases the server now produces chunk framing that #131138 intentionally rejects, so the client throws HttpIOException: ... must be terminated by CRLF. The "\r\n" cases still pass.

Suggested fix

Update the test to match the new, stricter (and correct) parser behavior:

• Remove "\n" from the lineEnding set so the test only exercises valid CRLF chunk framing, or
• Split the bare-LF cases into a separate negative test that asserts HttpIOException is thrown (mirroring the assertions added in SocketsHttpHandlerTest.cs by Strictly require CRLF when parsing HTTP/1.1 chunked encoding lines #131138).

Note the loopback server continues to legitimately use "\n" for the status line and headers, where lone-LF is still permitted; only the chunked-data lines are affected.

Sample console log

https://helixr1107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-heads-main-4476e53b55d340a79f/System.Net.Http.Functional.Tests/3/console.49294fc0.log?helixlogtype=result

Known issue error message

Fill the error message using known issues.

{
  "ErrorMessage": "Received an invalid chunk line ending. Chunked encoding lines must be terminated by CRLF.",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1546590
Error message validated: [Received an invalid chunk line ending. Chunked encoding lines must be terminated by CRLF.]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 8/11/2026 9:10:40 AM UTC

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.