jrudolph commented on issue #484:
URL: https://github.com/apache/pekko-http/issues/484#issuecomment-2056413441

   > I think we can proceed as follow
   
   I don't think we should do it like this. Especially, we don't want another 
entry point like `Http2()`. If we want to allow HTTP2 to be integrated more 
deeply, it should be done transparently using the existing APIs.
   
   In theory, all existing APIs can be supported by "just" allowing 
`PoolInterface` to deal with HTTP/2. This might not be a trivial task because 
of assumptions between the `PoolInterfaceStage` and `NewHostConnectionPool`. 
Let's say, we ignore automatic negotiation for now and require that you need to 
configure whether you want to connect to a host via HTTP/1.1 or HTTP/2 (i.e. a 
new setting in host-connection-pool`). 
   
   What needs to be done when HTTP/2 is selected is to replace the code at 
`PoolInterface.apply`, to create an alternative connection flow that uses a 
single managed persistent HTTP/2 connection instead of the pool of HTTP/1.1 
connections.
   
   
https://github.com/apache/pekko-http/blob/87f55da5817b20be224b96d87e984bdfbf883f79/http-core/src/main/scala/org/apache/pekko/http/impl/engine/client/PoolInterface.scala#L76-L79
   
   On the surface, it might be enough to switch out those two lines with the 
HTTP/2 equivalent. I wouldn't surprised if there are some subtle issues/bugs 
remaining in `managedPersistentHttp2` which was a late addition to HTTP/2 
support in akka-http.
   
   #### Some notes on automatic negotiation:
   
   You can do protocol negotiation, either by being told that HTTP/2 protocol 
is available using the `alt-svc` HTTP header, or by participating in TLS / ALPN 
negotiation. In any case, you only get told that HTTP/2 is available relatively 
late in the connection setup. Since the flows for HTTP/1.1 and HTTP/2 need to 
be wired differently, it is hard to negotiate on-the-fly and then wire things 
correctly in a pool setup. That means, you need to run a pre-flight request to 
figure out whether a certain host would support HTTP/2 and keep that 
information around for the rest of the session / application runtime. I would 
see that as an additional future feature. We could keep the http2 selection 
setting in `host-connection-pool` as selecting from `http1` / `http2` and then 
later add `auto` or `preflight`.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to