-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add HTTP/3 support #38595
Comments
@irhn
What are the plans for Dart's implementation? |
Not sure closing is the right thing to do. When HTTP/3 becomes a stable standard, we will most likely have to implement it. So, keeping this open as a place where people needing the feature can weigh in, but with no near-time plans to do an implementation in Dart. |
What about the quic protocol in general, apart from HTTP/3? |
There have already had https://tools.ietf.org/html/draft-ietf-quic-transport-32. It's a really nice package that the Dart SDK should have. |
@lrhn |
Any update on this? I'd really want to use QUIC with my application. Isn't it a bit overdue for such a cutting-edge framework like Flutter to implement this? |
Nothing has changed since #38595 (comment) If you want to use QUIC just bind to a library that implements it (e.g. cronet, see https://github.com/google/cronet.dart). |
I see there is no update. I'm developing a back-end framework (There is not enough documentation yet. Sorry about that). Also, a library with various easy codes for Flutter (or any client). Not ready yet. But I want to offer http2 and http3 support when ready. In this context, when I examine the drafts, I think I can do it with native dart even if it takes a long time (a quic and an http3 package). For this, I will need to find developers I can collaborate with. Knowing whether the Dart team will be working on http3 in the current or (short or medium term) future is important so that my efforts are not wasted. |
I believe that nothing has changed here: we still have no bandwidth to provide http/3 implementations in the core SDK. I strongly believe that HTTP3 protocol implementation should be implemented in package, contributed and maintained by the community. |
Since http3 support for gRPC(grpc/grpc#19126) and nodeJs(nodejs/node#38478) on the way, I think it's time to increase priority for this feature. |
/cc @brianquinlan |
HTTP/3 was standardized as RFC 9114. |
+1 |
it's sad to see Flutter which is known for "Cutting edge technology" be one of the last framework to join the QUICK protocol |
@marwenbk Additional pub cronet with grpc (https://pub.dev/packages/grpc_cronet) |
late Client client;
if (Platform.isIOS) {
final config = URLSessionConfiguration.ephemeralSessionConfiguration()
# Do whatever configuration you want.
..allowsCellularAccess = false
..allowsConstrainedNetworkAccess = false
..allowsExpensiveNetworkAccess = false;
client = CupertinoClient.fromSessionConfiguration(config);
} else {
client = IOClient(); // Uses an HTTP client based on dart:io
}
final response = await client.get(Uri.https(
'www.googleapis.com',
'/books/v1/volumes',
{'q': 'HTTP', 'maxResults': '40', 'printType': 'books'})); I would really appreciate it if you can try Comments or bugs in the |
Hey, would those of you who want HTTP/3 support briefly explain what HTTP/3 features are important to you e.g. QUIC (to provide better multiplexing), better header compression, etc.? Thanks! |
|
I understand it would be a bigger undertaking than "just" http/3, but webtransport support would be awesome for any real-time game/application. Otherwise yes, 0-RTT quic support would be great. |
I thought I'd mention the following too, since the original response was that "there's not enough bandwidth to work on this": Now that Cronet is available on every major OS supported by Flutter, you could use this by relying on it for the networking stack. Being Chromium/Chrome's networking stack means by integrating it into Dart you wouldn't need to worry much about integrating any new features in the future - it'd be simply about updating the Cronet version you'd boundle with Dart and exposing the relative APIs. I don't mean to disrespect anyone - I think the Dart networking stack works totally fine and has served its purpose well so far. This would give developers access to bleeding edge technologies with one of the best implementations available, while making it potentially easier for the Dart developers to integrate them. |
wait is cronet flutter only?! why? |
HTTP3 solves TCP Head of the line blocking by using QUIC which combines both layer 3 and layer 4 avoid tcp, into one single layer, HTTP/2 was introduced to make multiple http requests with in the same tcp connection since tcp connection is resource intensive and stateful the idea of streams was introduced in HTTP/2, but that means if there was one missing packet whole fleet of requests keep waiting until we get back that packet. and also QUIC solves other issues like switching from wifi to mobile network ig. |
I like the connection migration feature, which means when you walk outside, from one BTS to another, the connection will not be reset, or maybe you just walk to home, the net changed from 5G to WIFI, your connection to server will keep with the same connection id. |
FWIW, The API is the same as |
@brianquinlan is there any plan for a |
Are there plans to support http3? |
Any updates on plans to support QUIC protocol HTTP/3 |
Are there plans to support http3? |
Not in the short term. What's your use case @iapicca ? |
@brianquinlan |
@iapicca I meant:
And any other details that you can provide. |
what I would NOT do// ignore_for_file: double_negatives
what would I do
|
The reason why there are multiple HTTP client implementations is because there are multiple use cases. For example:
The idea behind pluggable HTTP clients is that you can chose the client that best suites your needs and the client in Also, if we build nghttp3/cronet/quiche into the Dart VM, then every Dart user will pay the price in terms of disk usage. I also thing that this model is pretty common - Python, Java, Node, etc. have multiple HTTP client implementations. Even the official android documentation points to multiple implementations. |
@brianquinlan my point is solely that a mobile ONLY implementation is less than ideal lastly, an option that I haven't mention is a pure dart implementation |
4 years and still no progress on this issue. HTTP/3 is growing in popularity and Dart needs to implement this. A Can we get an update from the Dart team? It's been 6 months since there's been any activity in this issue. |
The update is the same as before: the core team bandwidth is severely limited and we encourage community to step up and own pieces like this. If nobody steps up then most likely there will never be a We have tried to fill the client capabilities by providing pluggable HTTP clients, like We have currently neither plans nor bandwidth to provide a HTTP/3 server implementation. With native assets feature coming together it will become easy to create and distribute cross-platform Dart packages which depend on native libraries. |
Closing issue as not planned. |
Who is using what solutions now as an HTTP/3 server and client? |
Iot device s |
What library do you use as an HTTP/3 dart server/client? |
I searched for an issue to track progress of implementing HTTP/3 in the standard library but couldn't find one, so I'm opening this new issue to track this (presumably inevitable) effort.
The text was updated successfully, but these errors were encountered: