Yair Halberstadt

> some of them have already been prototyped in the experimental project. I think it would be useful to have a description of what these are lacking before they can...

Ok. I'm going to start off real simple here. Firstly I agree System.Net is not a great representation - it's very heavy, and very opinionated. Also it's quite likely we'll...

Also, do we want to support streaming http? Because IMessageReader isn't a suitable abstraction for that at the top level - i.e. it requires the entire bytes for the message...

> You've designed what we did in Kestrel 😄. Here are the interfaces in ASP.NET Core: What is the reason we're not using this, and writing our own instead? I'd...

> ```csharp > public readonly struct HttpHeader > { > public ReadOnlySpan FieldName { get; } > public ReadOnlySpan FieldValue { get; } > } > ``` That [won't compile](https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA+ABATARgLABQhGAzAASwCGAJhAHYA2AnmQM4AuUArmO2QBLt2AB34waMKIQDehMvLKkyAJXHUA8oyYBlYZToAeYE3YwAfGQBiASxgNqAOUoBbGGWlkA5jHYBuMgC+cgpKqjSazLr6RibmVrb2AGqUDFxuHt5+gYQBQA)

> It's internal/pubternal unsupported. Any reason not to copy it and then develop as necessary though?

> IMessageParser IMessageReader? Thanks - that's enough information to get started for now!

The kestrel HttpParser doesn't seem to support line folding in headers. https://github.com/dotnet/aspnetcore/issues/13923 I presume we don't need to either? Also do we want to guarantee we'll throw on invalid data,...

@davidfowl I think the next step with Http1 is to create an Http1HeadersParser which parses all the headers in a message, and can be shared between the Request and the...

Option 1. Has the disadvantage of not being able to gain efficiency by removing the SequenceReader. Option 2. Has the disadvantage of requiring you to duplicate code. I suppose one...