Kestrel: Unlimited request body content-length if no content-length supplied

[Danielku15]

Hey folks. 👋

Kestrel seem to have a behavior regarding the Content-Length of a request body which is causing limitations in some streaming scenarios.

Very concrete my problem is here located here in Kestrel:

aspnetcore/src/Servers/Kestrel/Core/src/Internal/Http/Http1MessageBody.cs

Line 215 in 5e25f15

return keepAlive ? MessageBody.ZeroContentLengthKeepAlive : MessageBody.ZeroContentLengthClose;

It prevents any reading of the body even though there might be data which is not explicitly defined by a content length.

Looking at the HTTP spec, it is not 100% strictly defined whether there still could be a body even though the client does not send a Content-Length header. Clients should send the header but it's not a must.

https://www.rfc-editor.org/rfc/rfc9110.html#section-8.6

---

In my use-case this is exactly happening: A client streams a blob without specifying the length as it is not basically unlimited. Unfortunately in this domain (GNSS) this is a common practice and widely implemented in the clients. This is due to (IMO) poor application level protocol specs from the responsible consortium. Hence I cannot change the client side.

Unfortunately the logic of of handling the body stream is buried very deep in Kestrel, everything is internal and there are no obvious extension points. I was hoping to get some community/collaborator assistance here or even get the ball rolling for some adaptions in Kestrel.

Goal 1: I would like to reuse Kestrel as HTTP server in my ASP.net core app with all its networking and communication infrastructure.
Goal 2: I want to read the unlimited length request body using the BodyReader even though the client is using NEITHER chunked encoding, nor specifying a Content-Length header.

Problem 1: The whole HTTP protocol implementations are internal and there is no way to extend the related body creation using.
Problem 2: Compiling the whole kestrel library myself is not feasible due to the complexity in this project and patching out the related bit is not feasible from a maintenance perspective.
Problem 3: Patching the method with tools like Harmony seems very risky.

Idea 1: The easiest for me would be if Kestrel would allow reading of the body in such cases. e.g. it could simply use a new Http1ContentUnlimitedLengthMessageBody(context, keepAlive) which is similar to Http1ContentLengthMessageBody but without an upper limit (e.g. long.MaxValue).

Idea 2: Kestrel could provide some callback which allows me to modify the HttpRequestHeaders before constructing the body. I could simply inject long.MaxValue.

Idea 3: Kestrel could expose the HTTP protocol implementations (e.g. via separate package having the types public?) + a factory constructing the connections here.

---

My current, very ugly workaround is to obtain a reader to the underlying connection like this:

var http1ContentLengthMessageBody = typeof(Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpMethod)
    .Assembly.GetType("Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1ContentLengthMessageBody")!;
var httpRequestPipeReader = typeof(Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpMethod)
    .Assembly.GetType("Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestPipeReader")!;

var messageBody = Activator.CreateInstance(http1ContentLengthMessageBody,
    context.Features,
    long.MaxValue,
    false)!;

var reader = Activator.CreateInstance(httpRequestPipeReader)!;

var startAcceptingReads = httpRequestPipeReader.GetMethod("StartAcceptingReads", BindingFlags.Public | BindingFlags.Instance)!;
startAcceptingReads.Invoke(reader, [messageBody]);

var realReader = (PipeReader)reader;

return realReader;

Any help and feedback is highly appreciated.

[vst121]

Hi,
This is by design, and Kestrel is very unlikely to change here.

In HTTP/1.1, if a request has neither Content-Length nor Transfer-Encoding: chunked, the body length is defined as zero. Kestrel is enforcing that interpretation deliberately to avoid request smuggling and connection desync issues. Treating “connection close” as an implicit unlimited body is explicitly discouraged in RFC 9110, even if some clients do it in practice.

Kestrel isn’t being inflexible. It’s enforcing HTTP correctness and security. If the client can’t be changed, HTTP/1.1 + Kestrel is the wrong abstraction boundary for this scenario.

Practical options:

1. Fix the client to use Transfer-Encoding: chunked (this is the correct solution, even for “unbounded” streams).
2. Terminate HTTP elsewhere (custom TCP listener, proxy, or specialized server) and forward the stream into ASP.NET Core via another mechanism.
3. Use HTTP/2 or HTTP/3, where streaming without a predefined length is naturally supported.

[Danielku15]

In HTTP/1.1, if a request has neither Content-Length nor Transfer-Encoding: chunked, the body length is defined as zero.

Do you have a reference for this? I personally couldn't see the explicit definition of this restriction that the body must be treated as 0-length in this case.

Specifically NTRIP in combination with NMEA-183 GGA used in the GNSS domain is one application where it is the common practice that the client regularly signals to the server new information through the "body stream". I'm also not a big fan of the protocol details and how it is implemented by most devices but it is quite a big market ranging including but not limited to autonomous driving vehicles, UAVs, surveying equipment, GIS equipment, land and construction monitoring,...

NTRIP is the industry standard protocol in the GNSS domain. Unfortunately the RTCM 10410.1 standard definition is not freely available in the public so I cannot share it.

[vst121]

Here are the relevant references backing up the behavior discussed:

• The HTTP/1.1 specification (RFC 9110) clearly defines how request bodies are framed. Section 8.6 explains how Content-Length is used and that without a valid framing header (Content‑Length or Transfer‑Encoding) the message has no body per spec: https://www.rfc-editor.org/rfc/rfc9110.html#section-8.6 :contentReference[oaicite:5]{index=5}

• The original GitHub Discussion itself links to RFC 9110 to explain why Kestrel implements strict HTTP semantics here. :contentReference[oaicite:6]{index=6}

• Official ASP.NET Core documentation describes Kestrel as the default web server and provides basic context on its role and features: https://learn.microsoft.com/aspnet/core/fundamentals/servers/kestrel :contentReference[oaicite:7]{index=7}

• In .NET Core repo history (e.g., issue Content-Length and Transfer-Encoding conflicts #43523), it’s documented that Kestrel honors HTTP semantics like Transfer‑Encoding: chunked over Content‑Length to avoid request smuggling risks, consistent with RFCs: Content-Length and Transfer-Encoding conflicts #43523 :contentReference[oaicite:8]{index=8}

These should serve as credible references for the claim about Kestrel’s HTTP body handling.

[Danielku15]

Thanks for sharing, I hope with such clear sources I can wake-up the people from the related consortiums to consider some improvements on their standards. Its simply not enough to mention "yeah, we use HTTP/1.1 as base, read the specs in case of doubts". It just leads to everyone doing incomplete stuff that the market has to deal with 😭

Nevertheless: I understand the standpoint of the Kestrel defaults. What generates some frustration is the fact that so many things are implemented behind the scenes. Looking at the broader aspnetcore picture extensibility and custom behaviors (e.g. through DI) are a key-part of most solutions. While you can add complete custom protocols from scratch to Kestrel, there is not much available in the HTTP protocol implementations.

My usecase is specific but there would be multiple ways of allowing devs to utilize the amazing Kestrel Framework foundation for wider applications if there would be some extension points:

1. Very specific: Something like a IHttp1MessageBodyFactory to handle the body logic myself.
2. Fairly high but I could grab some code from Kestrel: A more "isolated" HTTP implementation that can be "copied/extended" for customizations.

   aspnetcore/src/Servers/Kestrel/Core/src/Internal/HttpConnection.cs

   Line 70 in d9712bb

   requestProcessor = _http1Connection = new Http1Connection<TContext>((HttpConnectionContext)_context);

   Internally all things are already extensible and designed for adaptions (to handle HTTP versions). Its a bit sad that if I want to build a custom proprietary "HTTP/1.2" I have to start from scratch at 0 if almost everything is there already.

[vst121]

Totally feel this. Kestrel is incredibly well-engineered, but a lot of that flexibility stops right at the internal boundary. From the outside it’s very much “here’s HTTP/1.1/2/3, take it or fork it”.

Your examples hit the nail on the head:

• Something like an IHttp1MessageBodyFactory would already unlock a whole class of advanced/custom scenarios without breaking the defaults.
• And given that Kestrel already cleanly abstracts between HTTP versions internally, it’s frustrating that building a “HTTP/1.x-ish but not quite” protocol means copy-pasting half of Internal and owning it forever.

I get why the team optimizes for safety, perf, and spec-compliance, but a few official, sharp extension points (even marked “expert only”) would let people build on Kestrel instead of around it. Right now, the choice is either black box or start from zero, which feels like a missed opportunity given how close everything already is.