On Fri, 2023-07-21 at 12:18 +0200, Konrad Windszus wrote: > 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. >
Why would we want to do that? The classic APIs serve an extremely important role of facilitating the migration from 4.x to 5.x. Moreover there are plenty of use cases where HTTP/1.1 works as well or even better than HTTP/2 (file resource upload / download like what Maven Wagon does being one). I understand this may inconvenience you but if you want to work with H2 only endpoints you should consider upgrading to the async APIs as described here: https://hc.apache.org/httpcomponents-client-5.2.x/migration-guide/index.html Oleg > 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 > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
