On Fri, Mar 11, 2016 at 3:58 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Fri, Mar 11, 2016 at 02:40:34PM +0000, Phil Lello wrote:
>
> > Hi,
> >
> > What's the best place to find details on planned features for HTTP/2
> > support?
> >
> > I've only been looking at HTTP/2 for a few days, so forgive me if this is
> > already covered.
> >
> > It seems pretty obvious to me that it provides an opportunity for
> > potentially significant performance gains if changes are made to the xCGI
> > model, and potentially web applications.
> >
> > Specifically, since there is a quasi-persistent [1] connection between a
> > browser and a server, serialisation of a session object between page
> > requests is no longer necessary, and it can become bound to the transport
> > layer - whilst this may seem to introduce possible race conditions
> between
> > pages, this is no different from concurrent requests on the same session
> > under HTTP/1.x.
>
> This is not going to work for multiple reasons, at least:
>
> - connections can be broken for unrelated reasons (network
> changes, server reloads, whatever);
>
> That's why I refer to it as a quasi-persistent connection; I'd expect
serialisation/deserialisation to still occur, and covered that in my
footnote.


> - transport layer is not guaranteed to be bound to a particular
> client, and can be used by many different clients instead (e.g.,
> when used by proxy servers);
>
> - there may be intermediate servers and different protocols
> involved, so from backend point of view there will be multiple
> different connections;
>

Given that the current state of HTTP/2 support in browsers seems to be
forcing the use of TLS, it seems that the opportunity for proxies to kick
in is relatively limited. Of course, it remains possible (or even likely)
that aggregation can/will occur at netowrk edges as/if SSL-offloading
converts h2 into h2c. As an aside, that's a concern, since in the absense
of readily available tools to test the h2c transport (e.g. a browser),
implementations are more likely to be buggy. More likely, if HTTP/2 is
widely used, we'll start seeing SSL-offloading become a means to control
access to real certificates, and organisation-local CA's or self-signed
certs being used on the backend. Which also makes me nervous, as once
organisation CA's are widely installed in a network, less ethical places
could decode/snoop/encode supposedly secure traffic. I've gone wildly
off-topic.

We've already seen how connection-oriented model [does not] work
> for Microsoft with their NTLM authentication scheme. Don't try to
> repeat their mistakes.
>
> I'll do some research on this, thank you for bringing it to my attention.


> > A secondary requirement is a mechanism to implement server-push, so that
> > <language-of-choice> can specify page dependencies, rather than requiring
> > inspection of content within the server.
> >
> > Is any work currently being done in this direction?
>
> No.
>

OK. So the question now becomes, if I start work in these areas, is it
likely to be rejected by core, or is it simply that no one else has had the
time and motivation?

I must admit though, the more I look at HTTP/2, the less appealing it
seems, for reasons that are adequately covered by multiple authors on the
HTTPWG list.

Phil
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx