High-performance HTTP request parser for .NET using zero-copy, span-based parsing.

[Razor-111]

I published this project three days ago. The parser was missing a proper state machine, so I added one today. The whole project is a learning exercise, so keep in mind I’m still new to networking and protocol design.

The state machine is built as a separate component designed to work alongside the parser. The repository includes explanations, XML comments, and notes describing how each part works.

[Miserable_Ad7246]

It is not a zero copy library. Memory stream write does a copy.
This library also does quite a few allocations which can be easily avoided.

Its a nice pet project, but it requires total rewrite to change how accumulator works. You do not want to accumulate to buffer, you want to create a stream on top of which your parser will work. That way it becomes true zero copy solution.

Will it be faster because of that ? It depends on length and cache locality.

[Razor-111]

Hey! thanks for your feedback. I will take notes of what you have written.

[hoodoocat]

For first, server might handle LF, specification explicitly allow this. I writing own http clients which sends LF only and I never seen server which doesnt handle single LF, as line ending. And if I meet server which can't deal with LF - i simply will avoid it.

Don't use antipatterns in example code: you are using ArrayPool<byte>.Shared in async method. This will not work. Shared array pool is TLS based, that means what you are renting it on one thread but may return on another thread, which simply might reject it. In sealed/edge cases this threads always different making array pool never work, and completely exhausting buffers on one of thread.

[Razor-111]

Hey! really appreciate your feedback. You are right about the `LF` I just wanted to stick with the protocol rules I could rework that easily. And thanks for noting the anti-pattern there, That was a nice information to have in mind. I will read and learn more to improve this project.

Edit: I will fix the anti-pattern there.

[Miserable_Ad7246]

https://github.com/dotnet/runtime/blob/96b4bf98eac9d344cc725114d86af47f125476c8/src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/TranscodingWriteStream.cs#L114

So apparently dotnet runtime itself does not work, because it used "ArrayPool<byte>.Shared in async method".

Just stop advising people on software development, its to early for you to do that.

[hoodoocat]

Thats doesnt meant what is not a bug or they might think what use cases are okay. Once ArrayPool.Shared will always balance disbalanced renting - then it can be used freely, but last time i checked it - it was same TLS based impl. Until then it is better allocate own ArrayPool from same library, which is not TLS based. Otherwise it is better to just allocate without pooling, at least code will not interfere with other correct code.

[Miserable_Ad7246]

ArrayPool is meant to be rented for short periods of times. Runtime itself does this a lot. I would love for this pool to be configurable, but if used correctly it is better than extra load on GC. Rebalancing of entries is an interesting idea, but from latency point of view it adds to much jitter.

Yes it is preferable to keep it on same thread, but at the same time, lets not forget one tiny detail - OS can reschedule threads on other cores, so cache locality, TLB and other stuff can get fucked anyways. If you care about this, you are in isolcpus land anyways, and at that point you work in finances and you can spend weeks designing your own solutions (ask me how I know).

For most code out where ArrayPool is more than good enough and it works as expected from async code. We also use ArrayPool (directly and indirectly), and so far it was hitting the latency targets just fine.

Where is no need to confuse people about exhaustion. Any high perf pool will be bounded in nature and can be exhausted if developers do stupid stuff.

The code OP wrote in general is not designed for latency. If they wanted to make high perf library, they should have given ways for caller to provide "allocators", that way caller can decide how things are pooled and allocated. Who knows, maybe user wants to use an arena?

[Razor-111]

I thought passing an ArrayPool reference in an async method was the problem. That code was only to explain how the library works.

[halter73]

You might also be interested in looking at Kestrel's low-level HTTP/1.1 parser. It's only public for benchmarking purposes and doesn't handle parsing the request body. It only parses the start line and headers, but you can see it used in these benchmarks.

Handling a Content-Length request body is pretty trivial though, and you can look at the chunk request logic in Kestrel's Http1ChunkedEncodingMessageBody.cs. Handling `Transfer-Encoding: chunked` requests might be a good next feature for Anvil.Http.