MultipartReaderStream ignores offset using Read

[StefanHolst]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When using MultipartReader to parse multipart/form-data uploads, the Read method on the section’s Body stream does not respect the offset parameter. This causes issues when attempting to read data into a specific position in a buffer.

Possible Cause

This issue appears to have been introduced in PR #51815. Specifically, the optimization in this code section seems to create a span starting from the beginning of the input buffer, instead of the offset parameter.

Expected Behavior

The Read method should respect the offset parameter, writing data into the buffer starting at the specified position.

Steps To Reproduce

1. Create a new ASP.NET Core project.
2. Add a controller with an upload endpoint.
3. Implement the DisableFormValueModelBindingAttribute (see reference to disable default model binding).
4. Use a MultipartReader to parse the request, then call ReadNextSectionAsync to get the next MultipartSection.
5. Start reading the section’s Body stream into a large buffer using Stream.Read or Stream.ReadAsync, specifying a non-zero offset.
6. Upload a file larger than 4096 KB to trigger multiple reads.

Observed Behavior

On the second and subsequent reads, the MultipartReaderStream incorrectly writes data starting at offset 0 of the buffer, overwriting previously written data, instead of respecting the specified offset.

Reproduction Project

I have created a small asp project that reproduces the issue here: https://github.com/StefanHolst/MultipartReaderStreamIssue.

Exceptions (if any)

No response

.NET Version

9.0.100

Anything else?

IDE

JetBrains Rider 2024.3

dotnet Version

dotnet --info:

.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.3068a692
 MSBuild version:   17.12.7+5b8665660

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  15.1
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /usr/local/share/dotnet/sdk/9.0.100/

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: arm64
  Commit:       9d5a6a9aa4

.NET SDKs installed:
  8.0.404 [/usr/local/share/dotnet/sdk]
  9.0.100 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.11 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.11 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Environment variables:
  DOTNET_ROOT       [/usr/local/share/dotnet]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

[BrennanConroy]

Whoops 😅 Seems like we just need to change the 0 to offset?

I'll get around to this later this week or next, unless you want to contribute a fix?
Tests would go somewhere in https://github.com/dotnet/aspnetcore/tree/main/src/Http/WebUtilities/test

[StefanHolst]

Whoops 😅 Seems like we just need to change the 0 to offset?

I'll get around to this later this week or next, unless you want to contribute a fix? Tests would go somewhere in https://github.com/dotnet/aspnetcore/tree/main/src/Http/WebUtilities/test

Would love to, but I'm not allowed for copyright reasons. And getting permissions might take longer than you getting around to it.

[BrennanConroy]

Ok no worries 😃