Use PipeReader JsonSerializer overloads by BrennanConroy · Pull Request #62895 · dotnet/aspnetcore (original) (raw)
Includes: MVC, Actions and Controllers, Localization, CORS, most templates
label
Copilot AI review requested due to automatic review settings
Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc
label
This was referenced
Jul 24, 2025
jeffhandley pushed a commit to dotnet/runtime that referenced this pull request
Backport of #118041 to release/10.0
/cc @BrennanConroy
Customer Impact
- Customer reported
- Found internally
Reported in dotnet/aspnetcore#64323. Customers using request buffering (or similar seekable streams) and reading through the request before framework/app code processes the request are now getting empty data or errors in the app/framework code.
The expectation is that if using a seekable stream and doing some (pre-)processing of the request before letting application code see the request, then the application code should be able to read from the stream and get the full request as if no (pre-)processing occurred.
Regression
- Yes
- No
StreamPipeReader didn't regress, but ASP.NET Core used it in more
places in 10.0 which caused a regression in ASP.NET Core.
dotnet/aspnetcore#62895 added PipeReader
support for Json deserialization to most of ASP.NET Core's json parsing
code which meant the StreamPipeReader ended up getting used during
json deserialization where previously it was using the Stream.
Testing
Verified that the original issues described in
dotnet/aspnetcore#64323 were fixed with this
change. (both MVCs IAsyncResourceFilter and Minimals
IEndpointFilter)
Also verified skipped test
https://github.com/dotnet/aspnetcore/blob/1a2c0fd99c05db9f9ef167165386d14d3e24c9b4/src/Http/Http.Extensions/test/RequestDelegateGenerator/RequestDelegateCreationTests.BindAsync.cs#L257-L258 was fixed by this change.
Risk
Low;
This could cause a regression if someone was reading from a Stream
after it had returned 0 (exceptions below). This is not a common
pattern as most code would exit the read loop or be done processing the
Stream at that point.
Scanned a few dozen Stream implementations to verify that calling read
after a previous read returned 0 does not throw. Most code that calls
read after a previous read returned 0 are either seeking (rewinding)
or doing zero-byte reads.
Co-authored-by: Brennan brecon@microsoft.com Co-authored-by: Copilot 175728472+Copilot@users.noreply.github.com
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})