You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Konrad Windszus <kw...@apache.org> on 2023/07/20 13:13:07 UTC
HTTP/2 Support with HttpClient Classic API
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
Re: HTTP/2 Support with HttpClient Classic API
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <kw...@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-unsubscribe@hc.apache.org
> > > For additional commands, e-mail:
> > > httpclient-users-help@hc.apache.org
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: HTTP/2 Support with HttpClient Classic API
Posted by Konrad Windszus <kw...@apache.org>.
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 <kw...@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-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>
Re: HTTP/2 Support with HttpClient Classic API
Posted by Konrad Windszus <kw...@apache.org>.
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-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
Re: HTTP/2 Support with HttpClient Classic API
Posted by Oleg Kalnichevski <ol...@apache.org>.
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-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org