Actually there are other pluses. For one the number of sockets will go down
dramatically to one since the data is multiplexed over one socket which the app
server people will really want. Also, there is header compression which for
mobile devices is very important since most of thier communication is small
such that header size affects performance. The data is now binary in the main
body which helps with the performance and secuirty aspect. Also, if an
organization has upgraded the firewalls and proxies with http/2 and thier
browsers support it and they have server side support then they can move
forward. But as you said the server side support is sparse but netty and jetty
support it now so if that is upgraded for web servers like apache then that
covers the server side fairly well. Servlet 4.0 will support http/2 in J2EE 8
but who knows when that will be released. With app servers, java ect getting
faster the network bottleneck is more the concern especially resources consumed
by all those cell phones and maybe tablets. What will push all this is cost
savings. For big companies it may be worth it if it is all internal planned
updates anyway. It will be a interesting year to see what IT does. Best
Regards,-Tony
On Tuesday, February 24, 2015 6:01 PM, Brett Ryan <brett.r...@gmail.com>
wrote:
Tony, HTTP/2 is 1.1 backwards compatible. If the client doesn't understand
HTTP/2 then it will not elect HTTP/2 features.
>From my understanding performance gains are only going to be noticed by the
>new push mechanism that allows the server serve up parts of the content that
>the server thinks the client needs to render the response.
While a client may understand HTTP/2, the server needs to also, AND so does the
application running on the server so that the application can manifest what
content should be served up with the main request.
With all this, considering that there's only a select few of servers supporting
HTTP/2, I think the HC project has a little time before HTTP/2 support is going
to be something a lot of developers are requiring.
> On 25 Feb 2015, at 11:43, Tony Anecito <adanec...@yahoo.com.INVALID> wrote:
>
> Good question. Simpler means no frameworks without all the features and focus
> on simple url type calls to take advantage of the performance to begin
> with.http 2.0 is mostly about performance. The question is what will be
> available this month and beginning next month and who will be early
> adopters.The amount of money saved for big sites is quite a bit. And network
> and app server folks will love it. Regards,-Tony
>
> On Tuesday, February 24, 2015 4:10 PM, Stefan Magnus Landrø
><stefan.lan...@gmail.com> wrote:
>
>
> What do you mean by simpler?
>
> Sendt fra min iPhone
>
>> Den 24. feb. 2015 kl. 20.46 skrev Tony Anecito <adanec...@yahoo.com.INVALID>:
>>
>> My guess is IT and developers will be pushed to quickly use the new standard
>> and bypass HC to use a simpler solution in the interim.
>> Regards,-Tony
>>
>>
>> On Tuesday, February 24, 2015 12:39 PM, Tony Anecito
>><adanec...@yahoo.com.INVALID> wrote:
>>
>>
>> Thanks Gary looks like discussions are happening but nothing is ever vary
>> fast.
>> -Tony
>>
>>
>> On Tuesday, February 24, 2015 12:08 PM, Gary Gregory
>><garydgreg...@gmail.com> wrote:
>>
>>
>> Please see https://marc.info/?l=httpclient-commons-dev&m=142434644830689&w=2
>>
>> Gary
>>
>> On Tue, Feb 24, 2015 at 10:56 AM, Tony Anecito <adanec...@yahoo.com.invalid>
>> wrote:
>>
>>> Hi All,
>>> Is there plans by Apache http components to support http 2.0?
>>> Thanks,-Tony
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
