Add HTTP/3 support - Githubissues

AlvaroVasconcelos commented 4 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

lovung commented 3 years ago

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 commented 3 years ago

@lrhn this feature request could help implementing the feature

flawnn commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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

mraleph commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

/cc @brianquinlan

robbecker-wf commented 2 years ago

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 commented 2 years ago

+1

marwenbk commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

dhikshithrm commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

package:cronet_http

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

SamuelMauricioL commented 1 year ago

Are there plans to support http3?

fisforfaheem commented 1 year ago

Any updates on plans to support QUIC protocol HTTP/3

CristovoXDGM commented 1 year ago

Are there plans to support http3?

brianquinlan commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@iapicca I meant:

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

And any other details that you can provide.

iapicca commented 1 year ago

@brianquinlan

do you need HTTP/3 for outbound connections, inbound connections or both?

what platform are you deploying to?

what HTTP/3 features to do you need e.g. server push?

both, I miss the value of a "one-direction" connection
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!?)
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
- https://github.com/cloudflare/quiche/issues/799
- keep grpc in mind
- https://github.com/grpc/grpc-dart/issues/374

brianquinlan commented 1 year ago

@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 commented 1 year ago

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 commented 8 months ago

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 commented 8 months ago

@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 commented 4 months ago

Closing issue as not planned.

vukitoso commented 1 month ago

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

fisforfaheem commented 1 month ago

Iot device s

vukitoso commented 1 month ago

Iot device s

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

dart-lang / sdk

Add HTTP/3 support #38595

what I would NOT do

what would I do