Support HTTP/2 and HTTP/3 transport

[tamara-schmitz]

Preflight Checklist

• I could not find a solution in the existing issues, docs, nor discussions

Describe your problem

The SDK uses the http dart package, which according to its README uses IOClient on non-browser targets. This implementation only support HTTP/1.1.

HTTP/2 was ratified in 2015 and HTTP/3 in 2022 and widely used in the modern web. Both protocols provide real-world improvements to web and app use, especially on mobile wireless connections.

Describe your ideal solution

in lib/src/client.dart initializes a client if none exists which will use the http package's defaults and in particular IOClient on native platforms. Instead it would make more sense to change this to use a different package when a better implementation is available on the target platform. For example:

• rhttp which supports Android, iOS, macOS, Linux and Windows
• Android (CronetClient) / iOS (CupertinoClient) native clients which honor system and proxy settings

Only when neither option is available, there should be a fall back to the defaults.

As a user this would be great as it transparently improves performance for all users of the SDK.

Version

No response

Security requirements

No response

Additional Context

No response

[TheOneWithTheBraid]

Whereas I highly appreciate use of QUIC, I actually doubt this might be soon used in the matrix ecosystem.

At least about HTTP/2 : https://pub.dev/packages/http2 provides a Dart native HTTP/2 client implementation. One could easily adjust the Client constructor to use an HTTP/2 client implementation as drop-in replacement for the general purpose HTTP client. Please note that the Dart HTTP/2 client is obviously not supported on web since the HTTP requests are there dispatched by the browser.

[tamara-schmitz]

HTTP/2 and HTTP/3 are supported in browser Dart by FetchClient according to the http package defaults I linked above

[TheOneWithTheBraid]

I do not consider this as relevant SDK feature. The SDK uses a Client as argument. It's up to the users to provide an implementation with the parameters they want. E.g., in < polycule >, I use FetchClient on web (supporting HTTP/3 and keep alive) and on native platforms, I make use of package:rhttp (again, supporting both HTTP/3 and QUIC). As authors of the plugin, the behavior of enabling users to just provide a Client parameter and defaulting to Client() is exactly the correct behavior.

Even if ommitted, the Client can be overwritten per Isolate and Zone by executing the relevant parts of the application code in a runWithClient zone.

I do not see any need for Famedly to adjust their interface, one could maybe just consider adding some documentation about how the Client interface is meant to be used. But since the documentation is already part of package:http, I again do not see it as Famedly's task to educate users.

[krille-chan]

I agree here @TheOneWithTheBraid by offering the httpClient parameter, we let the consumer decide which client to use. We could write some tutorials how to use it though