Description
Is there an existing issue for this?
- 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