should support HTTP/2 about async-http-client

[fabianfett]

Work on this has started...

[Lukasa]

I think we should consider plaintext HTTP/2 (h2c) negotiation to be a non-goal. The IETF is considering removing h2c entirely from the next revision of the HTTP/2 RFC as it's essentially non-implemented. Plaintext HTTP/2 is supported, but only in the form of "prior knowledge" negotiation.

I think we should be able to achieve the simpler goal with the current architecture. Is this viable?

Yes.

How many concurrent h/2 connections do we want to support to a host? Only one? What do we want to do with EventLoopPreferences?

Only one. The RFC strongly encourages that we do so:

Clients SHOULD NOT open more than one HTTP/2 connection to a given host and port pair, where the host is derived from a URI, a selected alternative service, or a configured proxy.

What shall happen if an HTTP/2 connection already has the maximum number of concurrent requests running? SETTINGS_MAX_CONCURRENT_STREAMS (Especially important for something like sending push notifications)

Queue until a stream becomes available. swift-nio-http2 already has this ability.

Do we want to rename the HTTP1ConnectionProvider to HTTPConnectionProvider and save in the ConnectionsState whether this provider supports connections over HTTP/1.1 or HTTP/2? We should know after the first successful TLS connection.

TBD. Something somewhere needs to know the difference at some point, but whether it's encoded in the type system or not is a decision that needs to be made when we have a more detailed design.

[weissi]

apart from the obvious use-case -- to connect to HTTP/2 web servers -- this library could/should then also be used for swift-nio-apns.

[weissi]

@artemredkin / @ianpartridge / @tanner0101 should we pull this into the 1.0.0 milestone? I think it would be important to verify that the API actually works for HTTP/2. I don't foresee any issues but it'd be good to validate.
Obviously mostly useful together with a connection pool but ... @Lukasa what do you think?

[ianpartridge]

I think we can ship 1.0 without HTTP/2. Adding connection pooling and HTTP/2 sounds like a great set of 2.0 features and we can make any necessary API changes then.

[Lukasa]

I’m inclined to agree: it seems more important to enable users to start using the library than to throw HTTP/2 support into the client.

[artemredkin]

Same here

[fabianfett]

Hi,

I took some time and looked into this the last days... I haven't started programming or anything, but I think I should at least document the open questions/ideas I ran into:

I think we should go the lazy route (like most browsers except Safari) and first only support http/2 over TLS. The protocol negotiation should be fairly easy this way and we know before sending the first HTTP request, if we will talk HTTP1 or HTTP2 on this connection.

I think we should be able to achieve the simpler goal with the current architecture. Is this viable?

Further Questions

• How many concurrent h/2 connections do we want to support to a host? Only one? What do we want to do with EventLoopPreferences?
• What shall happen if an HTTP/2 connection already has the maximum number of concurrent requests running? SETTINGS_MAX_CONCURRENT_STREAMS (Especially important for something like sending push notifications)
• Do we want to rename the HTTP1ConnectionProvider to HTTPConnectionProvider and save in the ConnectionsState whether this provider supports connections over HTTP/1.1 or HTTP/2? We should know after the first successful TLS connection.

If you have any other design thoughts in the back of your heads, I'd be happy to know them. 😉

[fabianfett]

Fixed by #473