Google dumps SPDY in favour of HTTP/2, any plans for nginx?

[Mark Mielke]

I think the ability to "push" content, and prioritize requests are examples
of capabilities that might require intelligence upstream, and therefore a
requirement to proxy HTTP/2 upstream. However, I expect much of this is
still theoretical at this point, and until there are actually upstream
servers that are providing effective capabilities here, HTTP/1.1 will
perform just as good as HTTP/2? I also expect that some of these benefits
could only be achieved if the upstream server knows it is talking to a
specific client, in which case it would make more sense to use an HAProxy
approach, where one client connection is mapped to one upstream
connection...


On Tue, Mar 17, 2015 at 6:37 PM, Rainer Duffner <rainer at ultra-secure.de>
wrote:

>
> > Am 17.03.2015 um 23:32 schrieb Valentin V. Bartenev <vbart at nginx.com>:
> >
> > On Tuesday 17 March 2015 09:49:04 alexandru.eftimie wrote:
> >> Will there be support for http/2 for upstream connections? I can't seem
> to
> >> find anything about this online ( either SPDY or HTTP/2 for upstream
> >> connections )
> >>
> >
> > The problems that SPDY (and HTTP/2) is trying to solve usually do not
> > exist in upstream connections, or can be solved more effectively using
> > other methods already presented in nginx (e.g. keepalive cache).
> >
> > Could you provide any real use case for HTTP/2 in this scenario?
> >
>
>
>
> My guess would be if your upstream is actually a „real“ internet-server
> (that happens to do http/2).
>
> Somebody trying to build the next „CloudFlare/Akamai/WhateverCDN“?
> ;-)
>
> Is a world possible/imaginable that only does http/2?
>
>
> Rainer
>
>
>
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>



-- 
Mark Mielke <mark.mielke at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150318/e04a8641/attachment.html>