dotnet / dotnet/aspnetcore

Allow custom response body streaming of HTTP Responses without Transfer-Encoding or Content-Length set

Open
#59,055 0 comments 1 reaction 0 assignees View on GitHub
area-networking
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

### Is your feature request related to a problem? Please describe the problem.

I am trying to do a plain HTTP response streaming without chunked HTTP encoding but using an own framing logic. Unfortunately Kestrel automatically switches to chunked encoding based on whether a custom `Transfer-Encoding` or `Content-Length` is set.

https://github.com/dotnet/aspnetcore/blob/6359c76dfb4038bfd76bb4c327d472e8b1b8a450/src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.cs#L1198-L1228

Setting the Transfer-Encoding to something custom (e.g. the outdated `identity`) breaks compatibliity with reverse proxies like Traeffik. Hence I want to be able to "stream" an endless (no Content-Length known) raw byte response without setting a Transfer-Encoding header.

### Describe the solution you'd like

Kestrel should give some control on whether the automatic switch to chunked encoding is done or not allowing me to disable it. This could happen either via a new `IFeature` or as extension to an existing feature.

### Additional context

While this automatic switching might be OK for most standard browser use-cases, it breaks any usecases where HTTP is used as foundation for alternative communication systems. The HTTP/1.1 spec mentions that Transfer-Encodings need to be registered in the [HTTP Transfer Coding Registry
](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#transfer-coding) so it is better to not send anything than an wrong/unsupported value.

My main real-world usecase is:

* Networked Transport of RTCM via Internet Protocol (NTRIP)

Contributor guide

Open the contributing guide

Research direction

Start in src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.cs around lines 1198-1228, where automatic transfer framing is selected. Review the linked HTTP/1.1 and IANA transfer-coding context, then determine the appropriate feature or extension; done means an endless raw response can stream without Kestrel adding chunked encoding or requiring a custom Transfer-Encoding value.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
backend, networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.