[Epic] HTTP/3 support in ASP.NET Core
analogrelay opened this issue · 13 comments
This is a high-level tracking work item for HTTP/3 and QUIC support in ASP.NET Core. We'll add items to this as we go.
NOTE: We have no concrete plans on when we are shipping this experience yet.
(Rough) Child Items:
- Design how QUIC interacts with Bedrock (multiple streams, connection features, etc.)
- QUIC transport for Bedrock
- HTTP/3 frame parsing for Kestrel, built on top of QUIC
- #19972 Ramp up interop tests
- #19973 Define end-to-end scenarios for the preview phase
NOTE: Public APIs for QUIC are out-of-scope for this initial release in 5.0. They're still very much on our radar, but the spec is in flux and we want to focus on an end-to-end scenario that works.
This is really really cool!
Please also consider adding httpclient (or client support in general) to the prototype work, i think a really great use case for this is inter service communication in a micro service solution (as in not using a browser).
That's something i'd like to do at least :)
Putting this in 5.0.0 to represent the fact that we are doing work now, and that work definitely won't land in 3.1. Doesn't mean we're committing to anything real in 5.0 yet ;).
@tmds If the final impementation ends up being anything like the prototype it'll use native interop. https://github.com/dotnet/aspnetcore/tree/master/src/Servers/Kestrel/Transport.MsQuic
@tmds still figuring out the details. The work being done should still be considered a prototype; msquic is just what we're using now but that may change.
@tmds still figuring out the details. The work being done should still be considered a prototype; msquic is just what we're using now but that may change.
If possible, try to support a provider which is already available in popular distros. That makes it easier because .NET Core packages can use that as a dependency. And these packages may meet some required security qualification.
@anurse could you add an open child item to this issue for supporting an open-source quic provider?
That should go in dotnet/runtime. We'll be building a native HTTP/3 stack on top of some kind of QUIC implementation in dotnet/runtime. The MsQuic interop layer we built was just to enable our work on HTTP/3. It also went on to be the very first prototype version of System.Net.Quic, but it's part of dotnet/runtime now and so not directly in-scope here.
For ASP.NET Core it'll definitely be possible to provide an alternate transport (much like the existing linux-native transport: https://github.com/redhat-developer/kestrel-linux-transport) using any library you want and get the full fidelity of Kestrel's HTTP/3 implementation on top of it.
@tmds We'd definitely be very interested in your thoughts here though. I'm not aware of any QUIC provider in a distro today, but I may be wrong. It would be great if you could file something in dotnet/runtime with your suggestions so we have them captured.
Create dotnet/runtime#2333 for open-source QUIC provider support.
Moving this to 6.0; we have experimental support for HTTP/3 in .NET 5, but this will finished in 6.
Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Closing this epic. HTTP/3 support is going to be available as a preview feature in .NET 6!