samueleresca commented on issue #484: URL: https://github.com/apache/pekko-http/issues/484#issuecomment-2068066296
@jrudolph Thanks for the steering. > 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. ACK on the above. So the apporach you are suggesting is to skip the initialization of the `NewHostConnectionPool` in case http2 is specified and to use directly the flow coming from `managedPersistentHttp2` for constructing the `PoolInterface`? > Which is not quite the case right now. NewHostConnectionPool is Flow[RequestContext, ResponseContext] while managedPersistentHttp2 is Flow[HttpRequest, HttpResponse]. That's probably not a blocker, it's more an artifact of the HTTP/1.1 low-level impl not (yet) supporting the more general RequestResponseAssociation protocol to associated requests with responses that HTTP/2 supports. What is your recommendation here? I'm seeing that `[Request|Response]Context` is a case class wrapping a `Http[Request|Response]`. Should I create a new `PoolInterfaceStage` implementation that handle `Flow[HttpRequest, HttpResponse]` instead of `Flow[RequestContext, ResponseContext]`? -- 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: notifications-unsubscr...@pekko.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org For additional commands, e-mail: notifications-h...@pekko.apache.org
