Re: Support HTTP/2 protocol
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
Re: Support HTTP/2 protocol
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. > 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. 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
Re: Support HTTP/2 protocol
Thanks Oleg for your answer. Regarding JMeter, having to wait for Java 9 may not be feasible as we'll be just upgrading to Java 8 in next release but I think we'll have to support Java8 for at least 1 year or 2. Java9 will also most probably require some important work due to modules and adoption (not only for JMeter) may take some time. Regards On Thu, Jan 26, 2017 at 4:15 PM, Oleg Kalnichevskiwrote: > On Thu, 2017-01-26 at 14:32 +0100, Philippe Mouawad wrote: > > Hello , > > Oleg kindly proposed to help JMeter project in adding HTTP/2 support. > > > > We have started this thread to work on design. > > > > As per Andrei remark, it seems ALPN is not yet supported by current > > HTTPClient 5.x version. > > Is there some visibility on its support ? > > > > > ALPN will be supported as soon as it is supported by the Java platform > (which is not going to happen until Java 9). > > 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. > > Oleg > > > > > Thanks for your help. > > Regards > > > > On Thu, Jan 26, 2017 at 2:13 PM, Andrey Pokhilko wrote: > > > > > Hi, > > > > > > From my experiments, I see that lack of two specific features make > > > it > > > not useful. According to https://hc.apache.org/news.html: > > > > > > * No ALPN support yet > > > * no connection upgrade > > > > > > Especially ALPN part is crucial for protocol functioning. Is there > > > any > > > ETA from Oleg when it will become available? > > > > > > > > > In general, we can start designing the "synchronous way" solution. > > > From > > > my understanding, it is doable and will be good enough for the > > > beginning. > > > > > > > > > Andrey Pokhilko > > > > > > On 25.01.2017 23:38, Philippe Mouawad wrote: > > > > Hello > > > > I'd like to start a thread on this particular item for which an > > > > > > enhancement > > > > exists: > > > > > > > >- https://bz.apache.org/bugzilla/show_bug.cgi?id=59847 > > > > > > > > The aim of this thread is to discuss, throw ideas on how we could > > > > > > implement > > > > this in JMeter. > > > > > > > > Oleg K. from HttpComponents project has nicely proposed to help > > > > on it. > > > > > > > > I see at least 2 parts in this item: > > > > > > > >- The Sampler > > > >- The Recorder > > > > > > > > > > > > > > > > *Sampler:* > > > > We have 2 options: > > > > > > > >- build a usual "synchronous" sampler similar to HTTP: > > > > - Is this realistic ? > > > > - Does it perform well ? > > > > - + : It should not be too complex > > > >- build a new "Asynchronous sampler": > > > > - Is this realistic ? > > > > - + We could gain more performance > > > > - - It is a huge piece of work as we need to change JMeter > > > > model > > > > > > > > *Recorder:* > > > > > > > > I think we need to introduce a new more generic Recorder as the > > > > current > > > > Test Script Recorder is too tightly linked to HTTP 1.X protocol > > > > > > > > > > > > Regards > > > > Philippe M. > > > > @philmdot > > > > > > > > > > > > > > > -- Cordialement. Philippe Mouawad.
Re: Support HTTP/2 protocol
On Thu, 2017-01-26 at 14:32 +0100, Philippe Mouawad wrote: > Hello , > Oleg kindly proposed to help JMeter project in adding HTTP/2 support. > > We have started this thread to work on design. > > As per Andrei remark, it seems ALPN is not yet supported by current > HTTPClient 5.x version. > Is there some visibility on its support ? > ALPN will be supported as soon as it is supported by the Java platform (which is not going to happen until Java 9). 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. Oleg > Thanks for your help. > Regards > > On Thu, Jan 26, 2017 at 2:13 PM, Andrey Pokhilkowrote: > > > Hi, > > > > From my experiments, I see that lack of two specific features make > > it > > not useful. According to https://hc.apache.org/news.html: > > > > * No ALPN support yet > > * no connection upgrade > > > > Especially ALPN part is crucial for protocol functioning. Is there > > any > > ETA from Oleg when it will become available? > > > > > > In general, we can start designing the "synchronous way" solution. > > From > > my understanding, it is doable and will be good enough for the > > beginning. > > > > > > Andrey Pokhilko > > > > On 25.01.2017 23:38, Philippe Mouawad wrote: > > > Hello > > > I'd like to start a thread on this particular item for which an > > > > enhancement > > > exists: > > > > > > - https://bz.apache.org/bugzilla/show_bug.cgi?id=59847 > > > > > > The aim of this thread is to discuss, throw ideas on how we could > > > > implement > > > this in JMeter. > > > > > > Oleg K. from HttpComponents project has nicely proposed to help > > > on it. > > > > > > I see at least 2 parts in this item: > > > > > > - The Sampler > > > - The Recorder > > > > > > > > > > > > *Sampler:* > > > We have 2 options: > > > > > > - build a usual "synchronous" sampler similar to HTTP: > > > - Is this realistic ? > > > - Does it perform well ? > > > - + : It should not be too complex > > > - build a new "Asynchronous sampler": > > > - Is this realistic ? > > > - + We could gain more performance > > > - - It is a huge piece of work as we need to change JMeter > > > model > > > > > > *Recorder:* > > > > > > I think we need to introduce a new more generic Recorder as the > > > current > > > Test Script Recorder is too tightly linked to HTTP 1.X protocol > > > > > > > > > Regards > > > Philippe M. > > > @philmdot > > > > > > > > > - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Support HTTP/2 protocol
Hello , Oleg kindly proposed to help JMeter project in adding HTTP/2 support. We have started this thread to work on design. As per Andrei remark, it seems ALPN is not yet supported by current HTTPClient 5.x version. Is there some visibility on its support ? Thanks for your help. Regards On Thu, Jan 26, 2017 at 2:13 PM, Andrey Pokhilkowrote: > Hi, > > From my experiments, I see that lack of two specific features make it > not useful. According to https://hc.apache.org/news.html: > > * No ALPN support yet > * no connection upgrade > > Especially ALPN part is crucial for protocol functioning. Is there any > ETA from Oleg when it will become available? > > > In general, we can start designing the "synchronous way" solution. From > my understanding, it is doable and will be good enough for the beginning. > > > Andrey Pokhilko > > On 25.01.2017 23:38, Philippe Mouawad wrote: > > Hello > > I'd like to start a thread on this particular item for which an > enhancement > > exists: > > > >- https://bz.apache.org/bugzilla/show_bug.cgi?id=59847 > > > > The aim of this thread is to discuss, throw ideas on how we could > implement > > this in JMeter. > > > > Oleg K. from HttpComponents project has nicely proposed to help on it. > > > > I see at least 2 parts in this item: > > > >- The Sampler > >- The Recorder > > > > > > > > *Sampler:* > > We have 2 options: > > > >- build a usual "synchronous" sampler similar to HTTP: > > - Is this realistic ? > > - Does it perform well ? > > - + : It should not be too complex > >- build a new "Asynchronous sampler": > > - Is this realistic ? > > - + We could gain more performance > > - - It is a huge piece of work as we need to change JMeter model > > > > *Recorder:* > > > > I think we need to introduce a new more generic Recorder as the current > > Test Script Recorder is too tightly linked to HTTP 1.X protocol > > > > > > Regards > > Philippe M. > > @philmdot > > > > -- Cordialement. Philippe Mouawad.