On Mon, 2017-01-30 at 08:43 -0700, Shawn Heisey wrote: > On 1/26/2017 8:15 AM, Oleg Kalnichevski wrote: > > ALPN will be supported as soon as it is supported by the Java > > platform > > (which is not going to happen until Java 9). > > I see evidence that the other Java http implementations have ALPN > support already ... but those systems implement both server and > client. > Could it be that those ALPN implementations are server-side only? I > can't seem to easily locate anything saying for sure. >
No, it could not. HttpCore also implements both server and client side transports. Please take a closer look at the existing ALPN implementations, for instance, that provided by Jetty. It requires a custom agent that works with specific versions of OpenJDK only. If one does not have a problem going that route there is nothing stopping them from using Jetty ALPN agent to build a custom protocol negotiator for HttpClient. > > ALPN can be used to advertise server protocol capabilities at the > > time > > of SSL handshake and allow clients to pick the desired protocol > > from > > the list of supported protocols. If one knows supported protocols > > beforehand ALPN is completely useless. Clients can go straight to > > using > > HTTP/2 if the server is known to support it. > > > > In the next release of HttpCore I would like to add protocol > > detection > > logic to enable endpoints to detect HTTP protocol version by > > examining > > the first packet received from the opposite endpoint. This in my > > opinion would be a much more practical feature. ALPN presently is > > very > > low on my priority list. > > > > Having said that ALPN support contribution would be welcome if > > someone > > is willing to develop it. > > Knowing in advance that HTTP/2 support is available may be > problematic. > I can imagine a situation where servers are upgraded gradually, and > the > client may not know whether the one it's connecting to can support > the > new protocol. Can HTTP/2 detection be reliable without ALPN, even in > situations where connecting to the same host/port may support HTTP/2 > on > one connection, but not the next? TCP load balancing is relatively > common with SSL. If such detection can be reliable, then there won't > be > anything to worry about. > I see no reason why it could not, given that HTTP/2 connection preface message is essentially a specially crafted HTTP/1.1 compatible request message. Oleg > For my webserver installations, I am hoping to get HTTP/2 support > enabled in the load balancer and worry about support on the back end > later. I'm expecting the back-end LAN to be fast enough that > multiple > connections can easily be established while the Internet-facing side > works through the inherent packet latency. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org