One more aspect on this: Currently the documentation mentions all 3 APIs (Classic, Async, Reactive) in parallel (https://hc.apache.org/httpcomponents-client-5.2.x/) with no mentioning of any deprecation. But that means for all consumers that decide for Classic API, they will (probably) never be able to connect to HTTP/2 only endpoints, so this seems kind of like a dead end street. Do you consider Classic API legacy and do you recommend everyone (no matter which HTTP protocol version) to adopt async? If so, why not clearly mark it as deprecated then in javadoc and documentation.
I think this deserves some more clarity for consumers. Thanks, Konrad > On 21. Jul 2023, at 12:00, Konrad Windszus <k...@apache.org> wrote: > > 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 >> >
