HTTP/2 roadmap

Server NGINX
1

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.

A secondary requirement is a mechanism to implement server-push, so that
can specify page dependencies, rather than
requiring
inspection of content within the server.

Is any work currently being done in this direction?

Phil

[1] Since there needs to be periodic SSL renegotiation which would cause
reconnects, as well as sub-optimal network conditions on wireless and
mobile networks (and indeed, devices flip-flopping between the two).
draft-bishop-support-reneg-00 if adopted should address this in optimal
network conditions.

2

Hello!

On Fri, Mar 11, 2016 at 02:40:34PM +0000, Phil L. wrote:

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);

  • 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;

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.

A secondary requirement is a mechanism to implement server-push, so that
can specify page dependencies, rather than requiring
inspection of content within the server.

Is any work currently being done in this direction?

No.

–
Maxim D.
http://nginx.org/

3

Hello!

On Sat, Mar 12, 2016 at 01:09:41PM +0000, Phil L. wrote:

[…]

likely to be rejected by core, or is it simply that no one else has had the
time and motivation?

Well-designed server push mechanism is likely to be accepted.
Making things connection-oriented doesn’t really make sense for
the reasons outlined in the previous message.

–
Maxim D.
http://nginx.org/

4

On Sat, Mar 12, 2016 at 2:09 PM, Phil L. [email protected]
wrote:

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.

​Why could not proxies​

​be used with HTTP/2? Why would you expect the existing one to suddenly
be
removed?​

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?

Whatever others’ stance on that matter, you could always prepare some
module of your own and make it publicly available. If nginx rejects your
work for whatever reasons, people would still be able to use it in their
setup.

B. R.

5

On Fri, Mar 11, 2016 at 3:58 PM, Maxim D. [email protected]
wrote:

already covered.
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
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