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

[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(grpc/grpc#19126) and nodeJs(nodejs/node#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

[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?

[brianquinlan]

package:cronet_http

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

Not in the short term. What's your use case @iapicca ?

[iapicca]

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

Not in the short term. What's your use case @iapicca ?

@brianquinlan
literally any attempt to build a backend in dart using http3

[brianquinlan]

@iapicca I meant:

1. do you need HTTP/3 for outbound connections, inbound connections or both?
2. what platform are you deploying to?
3. what HTTP/3 features to do you need e.g. server push?

And any other details that you can provide.

[iapicca]

@brianquinlan

1. do you need HTTP/3 for outbound connections, inbound connections or both?
2. what platform are you deploying to?
3. what HTTP/3 features to do you need e.g. server push?

1. both, I miss the value of a "one-direction" connection
2. AT THE VERY LEAST being able to build a http3 server in multi-stage linux container,
   but I don't see why we should intentionally sabotage flutter desktop and web
   not sure if anyone actually uses osx/win server anywhere (and why!?)
3. I would like for me and other developers to be able to build
   a backend and connect it to an app (whatever the platform)
   with ALL the http3 feature available

what I would NOT do

// ignore_for_file: double_negatives

• do not ignore flutter web with dart:io based implementation
• do not ignore flutter desktop with mobile based implementations
• do not ignore pure dart / backend use case with mobile based implementations

what would I do

• choose ONE implementation (not 25 different one)
  eg: why cupertino_http and cronet_http just for mobile? this isn't a flutter issue!
• choose the MOST portable implementation (
  eg. from the top of my head using dart:ffi or even better wasm
  that could be ported to ALL mobile, desktop and web* (*eventually)
  below some implementation that could play well with ffi/wasm
  • nghttp3
  • quiche
    • [proposal] Flutter plugin using dart:ffi cloudflare/quiche#799
• keep grpc in mind
  • [proposal] http/3 and QUIC support grpc/grpc-dart#374

[brianquinlan]

@iapicca

The reason why there are multiple HTTP client implementations is because there are multiple use cases. For example:

• on Android cronet does not support private keys from KeyStore
• on iOS, only Apple's native APIs support background downloads, VPN switching, cross application cookie sharing, etc.

The idea behind pluggable HTTP clients is that you can chose the client that best suites your needs and the client in dart:io is a lowest-common-denominator that is supportable everywhere (except the web) but reasonably simple.

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.

[iapicca]

The reason why there are multiple HTTP client implementations is because there are multiple use cases. [...]

@brianquinlan
I didn't mean to tell dart team what to implement and how,
I'm sure that there are good reason for the decisions that are taken

my point is solely that a mobile ONLY implementation is less than ideal
both for flutter development and backend development

lastly, an option that I haven't mention is a pure dart implementation
that doesn't require binding to existing native libraries
(I know it's a tall order, but should be taken in consideration as a option)

[Reprevise]

4 years and still no progress on this issue. HTTP/3 is growing in popularity and Dart needs to implement this. A http3 package solution is completely fine like what was done with http2.

Can we get an update from the Dart team? It's been 6 months since there's been any activity in this issue.

[mraleph]

@Reprevise

Can we get an update from the Dart team?

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 http3 implementation - I know this might sound disappointing but that's the reality we are living in right now.

We have tried to fill the client capabilities by providing pluggable HTTP clients, like package:cupertino_http and package:cronet_http (see @brianquinlan posts). As I understand it - these client libraries have HTTP/3 support.

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.

[a-siva]

Closing issue as not planned.

[vukitoso]

Who is using what solutions now as an HTTP/3 server and client?

[fisforfaheem]

Iot device s

[vukitoso]

Iot device s

What library do you use as an HTTP/3 dart server/client?

[ugran]

What about webtransport usecase?

[h3x4d3c1m4l]

I think a solution based on Flutter Rust Bridge and a proven HTTP library (e.g. reqwest) could provide a viable solution here for all platforms. The API could simply implement dart:io's HttpClient.

[fisforfaheem]

Nice to hear, But this should be endorced

[sabin26]

I think a solution based on Flutter Rust Bridge and a proven HTTP library (e.g. reqwest) could provide a viable solution here for all platforms. The API could simply implement dart:io's HttpClient.

https://pub.dev/packages/rhttp

[iapicca]

I think a solution based on Flutter Rust Bridge and a proven HTTP library (e.g. reqwest) could provide a viable solution here for all platforms. The API could simply implement dart:io's HttpClient.

https://pub.dev/packages/rhttp

it's a great idea, but it's "flutter-only"
at the time of writing doesn't allow to create a server

• Support Dart only Tienisto/rhttp#19

[vukitoso]

at the time of writing doesn't allow to create a server

For an HTTP3/QUIC server, it may be better to use more highly specialized software: nginx, haproxy, Tengine, Caddy, Traefik, Envoy, Angie. Add request proxying with any other settings, such as balancing, request filtering, etc. In addition, you can add larger services such as Cloudflare and others. Those. installing your HTTP3 server on an external connection is becoming less relevant.
This is just my opinion.

[Tienisto]

I agree that a backend (that receives requests) should mostly exposed indirectly with nginx or any other software in the middle. Especially when it comes to letsencrypt, it is so much easier and safer to work with nginx.

This does not solve the issue of making (not receiving) requests in backend though.

[khteh]

I disagree with the idea of terminating all the load balancer. Doesn't this end all the benefits that HTTP/2 or HTTP/3 brings about at the load balancer and the last-mile traffic suffers from the depreviation of those benefits and become the bottleneck, deceiving the end-users of "HTTP/2" / "HTTP/3" connectivity?

[vukitoso]

@khteh

the last-mile traffic suffers from the depreviation of those benefits and become the bottleneck

Here's a picture of how my proposed option works, where all servers are located on the same local network and in the same data center. Because Since all servers are located in the same data center, the delay between them will be minimal 1ms or less. You won't notice the difference at all. But users already communicate with the server via HTTP3/QUIC with all its advantages.
I don't see a bottleneck. Unless you show performance tests where this bottleneck is clearly visible. Without measurements it is difficult to talk about a narrow neck.