dotnet / dotnet/aspnetcore

Deprecate support for manual chunking

Open
#51,529 0 comments 0 reactions 0 assignees View on GitHub
area-networking breaking-change
Dominant language
C#
Stars
38.4k
Forks
10.9k
Avg merge
2d 10h
Merged PRs (30d)
281

Description

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Describe the bug

It's common for apps to proxy a request and response, including the headers. While there are some connection/protocol headers that shouldn't be proxied, they tend to be ok in the common case. However, there is one that consistently causes major issues, `Transfer-Encoding: chunked`.

Kestrel (and our other servers?) have a `feature` where if you set the `Transfer-Encoding: chunked` header they assume you're doing the chunking yourself and do not do it for you. If you were proxying a pre-chunked stream that would make sense, but HttpClient strips out the chunk framing and that's the primary client used when proxying. The result is a malformed response where the client interprets the data as chunked framing and either hangs or throws.

I have never seen the manual chunking scenario used, but I have seen it frequently break the proxying scenario.

### Expected Behavior

The server should provide chunked framing even when the `Transfer-Encoding: chunked` response header is specified. This is mostly backwards compatible because applications currently work around this by removing the header.

Should there be a way to opt out? Does anyone actually use the manual chunking feature?

### Steps To Reproduce

_No response_

### Exceptions (if any)

_No response_

### .NET Version

_No response_

### Anything else?

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.