Mirror Windows behavior for managed HttpListener Content-Length

[iremyux]

This PR aligns managed HttpListener Content-Length parsing behavior with Windows behavior by rejecting out-of-range numeric values instead of treating certain overflow values as zero.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR changes the managed (System.Net.Managed) HttpListener request header parsing to treat out-of-range Content-Length values as invalid (i.e., parse failure) rather than accepting them and normalizing certain overflow cases to 0, aligning the managed behavior with the Windows implementation’s strict decimal parsing shape.

Changes:

• Updated managed Content-Length parsing to use long.TryParse(..., NumberStyles.None, InvariantCulture, ...) and reject parse failures.
• Moved coverage for overflow Content-Length values from “property returns 0” semantics to “invalid client request” semantics (400 Bad Request).
• Adjusted tests to keep the valid upper bound (long.MaxValue) case while removing the previous “overflow => 0” expectations.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/libraries/System.Net.HttpListener/tests/InvalidClientRequestTests.cs	Adds invalid-request cases asserting Bad Request for Content-Length values beyond long.MaxValue.
src/libraries/System.Net.HttpListener/tests/HttpListenerRequestTests.cs	Removes prior expectations that overflow Content-Length values are treated as 0.
src/libraries/System.Net.HttpListener/src/System/Net/Managed/HttpListenerRequest.Managed.cs	Switches to strict long.TryParse-based Content-Length parsing and rejects out-of-range values.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Net.HttpListener/src/System/Net/Managed/HttpListenerRequest.Managed.cs:223

• The comment asserts this is matching the Windows parser, but the Windows implementation in this repo (HttpListenerRequest.Windows.cs) handles Content-Length parse failure by treating it as an invalid boundary type (ContentLength64 returns 0) rather than rejecting the request in this layer. To avoid misleading future readers, consider rewording the comment to describe what this code actually does (strict decimal parsing + reject invalid values) without claiming Windows parity in this specific method.

                // Match the Windows parser shape: strict decimal parsing, and reject on parse failure.
                bool success = long.TryParse(val, NumberStyles.None, CultureInfo.InvariantCulture.NumberFormat, out long parsedContentLength);

[alinpahontu2912]

/ba-g failures do not seem related, I think this can be merged