<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 11, 2016 at 3:58 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span><br>
On Fri, Mar 11, 2016 at 02:40:34PM +0000, Phil Lello wrote:<br>
<br>
> Hi,<br>
><br>
> What's the best place to find details on planned features for HTTP/2<br>
> support?<br>
><br>
> I've only been looking at HTTP/2 for a few days, so forgive me if this is<br>
> already covered.<br>
><br>
> It seems pretty obvious to me that it provides an opportunity for<br>
> potentially significant performance gains if changes are made to the xCGI<br>
> model, and potentially web applications.<br>
><br>
> Specifically, since there is a quasi-persistent [1] connection between a<br>
> browser and a server, serialisation of a session object between page<br>
> requests is no longer necessary, and it can become bound to the transport<br>
> layer - whilst this may seem to introduce possible race conditions between<br>
> pages, this is no different from concurrent requests on the same session<br>
> under HTTP/1.x.<br>
<br>
</span>This is not going to work for multiple reasons, at least:<br>
<br>
- connections can be broken for unrelated reasons (network<br>
  changes, server reloads, whatever);<br>
<br></blockquote><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- transport layer is not guaranteed to be bound to a particular<br>
  client, and can be used by many different clients instead (e.g.,<br>
  when used by proxy servers);<br>
<br>
- there may be intermediate servers and different protocols<br>
  involved, so from backend point of view there will be multiple<br>
  different connections;<br></blockquote><div> </div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We've already seen how connection-oriented model [does not] work<br>
for Microsoft with their NTLM authentication scheme.  Don't try to<br>
repeat their mistakes.<br>
<span><br></span></blockquote><div>I'll do some research on this, thank you for bringing it to my attention.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> A secondary requirement is a mechanism to implement server-push, so that<br>
> <language-of-choice> can specify page dependencies, rather than requiring<br>
> inspection of content within the server.<br>
><br>
> Is any work currently being done in this direction?<br>
<br>
</span>No.<br></blockquote><div><br></div><div>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?<br><br>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.<br><font color="#888888"><br></font></div><div><font color="#888888">Phil<br></font></div></div></div></div>