Add HTTP/3 support

[AlvaroVasconcelos]

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.

[iapicca]

@Irhn given that

• http/3 draft has been published last month
• chrome is deploying it
• on safari is even enabled by default (source)

What are the plans for Dart's implementation? Will it be a separate package like http2 or grpc? Any timeline for a release?

[mraleph]

There are currently no plans (or bandwidth) to implement HTTP/3 support as either builtin dart:io feature or even as a package.

@lrhn do you think we should maybe close this as not planned to reflect the current thinking around dart:io and networking package priorities?

/cc @mit-mit @a-siva

[lrhn]

Not sure closing is the right thing to do. When HTTP/3 becomes a stable standard, we will most likely have to implement it. We are just not going to be riding the bleeding edge and implement the draft specification. It's unlikely that there will be any clients or back-ends which will be HTTP/3 only, so falling back on HTTP/2 is a valid option.

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. It's a non-trivial piece of networking code, especially for the server code, so we'll have to ensure we have someone qualified to implement it when the time comes. At that time, we can figure out whether we want it in a separate package or not.

[gargakshit]

What about the quic protocol in general, apart from HTTP/3?

[lovung]

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.

[iapicca]

@lrhn this feature request could help implementing the feature

[flawnn]

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?

[mraleph]

@flawnn

Nothing has changed since https://github.com/dart-lang/sdk/issues/38595#issuecomment-712857906

If you want to use QUIC just bind to a library that implements it (e.g. cronet, see https://github.com/google/cronet.dart).

[Mehmetyaz]

@lrhn @mraleph

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.

[zs-dima]

@lrhn @mraleph It is good time to introduce HTTP/3 support for the Dart and Flutter

[mraleph]

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.

[esenmx]

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(https://github.com/grpc/grpc/issues/19126) and nodeJs(https://github.com/nodejs/node/issues/38478) on the way, I think it's time to increase priority for this feature. Also, probably very few people in community has network programming experience since Flutter itself is an UI framework, some internal wiggling from Google would be very nice, otherwise chances are high we won't have this feature for a long time.

[a-siva]

/cc @brianquinlan

[robbecker-wf]

HTTP/3 was standardized as RFC 9114. Already supported in Edge, Firefox, and Chrome in version 101. And the best news Amazon CloudFront is scheduled to be the first AWS service to integrate s2n-quic with its support for HTTP/3 in 2022.

[khteh]

+1

[marwenbk]

it's sad to see Flutter which is known for "Cutting edge technology" be one of the last framework to join the QUICK protocol

[aospiridonov]

@marwenbk Just now, have cronet (https://pub.dev/packages/cronet) but they have bug, but if the authors update the version, then the rules will be. I hacked with rebuilding what was needed.

Additional pub cronet with grpc (https://pub.dev/packages/grpc_cronet)

[brianquinlan]

cupertino_http is a new experimental Flutter plugin that provides access to Apple's Foundation URL Loading System - which has HTTP/3 support

cupertino_http has the same interface as package:http Client so it is easy to use in a cross-platform way. For example:

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 cupertino_http out.

Comments or bugs in the cupertino_http issue tracker would be appreciated!

[brianquinlan]

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!

[Jure-BB]

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!

• QUIC to improve response times when requesting resources over larger geographic distances and less reliable networks
• 0-RTT QUIC to lower the number of round trips required to establish a secure TLS connection with the server

[nicoroy2561]

I understand it would be a bigger undertaking than "just" http/3, but webtransport support would be awesome for any real-time game/application. It could make sense since Flutter's been pushing games - and I say this as a Flutter game dev.

Otherwise yes, 0-RTT quic support would be great.

[nicoroy2561]

I thought I'd mention the following too, since the original response was that "there's not enough bandwidth to work on this": you could leverage the work done at https://github.com/google/cronet.dart too.

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. I'm only mentioning this because you might be interested in leveraging the work being done on Cronet instead of rolling and maintaining your own networking stack.

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.

[iapicca]

@marwenbk Just now, have cronet (https://pub.dev/packages/cronet) but they have bug, but if the authors update the version, then the rules will be. I hacked with rebuilding what was needed.

Additional pub cronet with grpc (https://pub.dev/packages/grpc_cronet)

wait is cronet flutter only?! why?

[dhikshith12]

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!

• QUIC to improve response times when requesting resources over larger geographic distances and less reliable networks
• 0-RTT QUIC to lower the number of round trips required to establish a secure TLS connection with the server

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.

[techwn]

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 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.

[brianquinlan]

FWIW, package:cronet_http is also available on Android and supports HTTP/3.

The API is the same as package:cupertino_http so it is possible to use cupertino_http on macOS/iOS and cronet_http on Android.

[iapicca]

package:cronet_http

@brianquinlan is there any plan for a non-flutter implementation?

[SamuelMauricioL]

Are there plans to support http3?

[fisforfaheem]

Any updates on plans to support QUIC protocol HTTP/3

[CristovoXDGM]

Are there plans to support http3?