Hi Oleg, Thanks for the quick answer. I am no expert but there are some other aspects apart from performance which may make HTTP/2 preferable, e.g. Header Compression or Connection Pooling (other means of detecting closed connections). Maybe in the future there are also endpoints that exclusively support HTTP/2.
Although I do agree that the full power of HTTP/2 can only be unleashed with an asynchronous API I still think that for simple use cases the blocking APIs should also support HTTP/2. I cannot really judge how complex such an implementation would be. In order to track this, I have opened https://issues.apache.org/jira/browse/HTTPCLIENT-2286. Thanks, Konrad > On 20. Jul 2023, at 20:59, Oleg Kalnichevski <ol...@apache.org> wrote: > > On Thu, 2023-07-20 at 15:13 +0200, Konrad Windszus wrote: >> Hi, >> Currently from reading >> https://hc.apache.org/httpcomponents-client-5.2.x/ it seems that >> there are no limitations with support of HTTP/2, on the other hand >> only Async API has explicit HTTP/2 examples mentioned in >> https://hc.apache.org/httpcomponents-client-5.2.x/examples-async.html >> . >> Does the classic (blocking) API also support HTTP/2 protocol or only >> 1 and 1.1? >> >> Can you maybe clarify that a bit on the website? >> Thanks in advance, >> Konrad > > Hi Konrad > > The classic i/o based transport presently supports HTTP/1.1 only and > this is not likely to change in the foreseeable future. > > The truth is that there is no reasonable way in terms of functionality > and performance (I know of) to implement the requirements of the HTTP/2 > protocol using Java classic (blocking) i/o. HTTP/2 connections work in > a fully multiplexing mode which can only be implemented with the > classic i/o by using multiple (at least two) concurrent threads > involving complex synchronization between those threads. It just does > not work well, does not scale and does not perform well. I did try. > > What other libraries do is they emulate the InputStream / OutputStream > APIs on top of NIO, which does provide the end user with APIs > compatible with the classic i/o but at the substantial cost in terms of > complexity and performance. I do not think we should follow the same > approach, at least not short- or mid-term. > > In my personal opinion the use of HTTP/2 at its full potential requires > event driven (async) programming interface incompatible with the > InputStream / OutputStream based APIs. > > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org >
