3 ms·

What's your point, though? Staying on 1.1 would guarantee we continue to lack tools to use HTTP/2. The MITM proxies, which seem to all be written by incompetent

What's your point, though? Staying on 1.1 would guarantee we continue to lack tools to use HTTP/2. The MITM proxies, which seem to all be written by incompetent software vendors, can strip out the HTTP/2 indicators and force their users back to 1. So if that's their goal, it's easy enough to achieve it. For everyone else, it's optional. 2 has mandatory TLS in browsers (that's how the browser vendors are making it), so random proxies and so on just remain ignorant to it. From an implementor's POV, 2 is easier to implement than 1. The new feature complexity is balanced by having sane parsing rules. And remember: We've (the Internet) have been using SPDY for a couple years now. That's a very long beta period and gave everyone plenty of time to play around, raise objections, write software, etc.

Silhouette 11y ago
The MITM proxies, which seem to all be written by incompetent software vendors, I'm not sure not spending time and money supporting a proprietary protocol created by an organisation with a reputation for dropping anything it doesn't like any more at short notice qualifies anyone as "incompetent". can strip out the HTTP/2 indicators and force their users back to 1. At which point anyone whose site was designed to be friendly to HTTP/2 in the ways described in the presentation will perform dramatically worse than it does under HTTP/1.1 if nothing is changed. 2 has mandatory TLS in browsers (that's how the browser vendors are making it), so random proxies and so on just remain ignorant to it. And you don't see a problem with that? We've (the Internet) have been using SPDY for a couple years now. Which Internet? A few high profile sites have been using it, but who else? Several major browsers haven't even supported SPDY until quite recently. Most don't support HTTP/2 fully yet. And in my search earlier, literally no-one was even talking about how to use some of the new capabilities to best effect server-side, never mind demonstrating server-side software that can actually do it. That's a very long beta period and gave everyone plenty of time to play around, raise objections, write software, etc. You must be joking. The kind of network monitoring and security devices I was talking about have 5-7 figure price tags in US dollars, sales cycles measured in months, purchasing cycles measured in years, and working lifetimes potentially measured in decades. Two years to understand, integrate, fully test, advertise, provide for evaluation, and ultimately sell support for a new protocol is nothing in this industry. Among the projects I have recently worked on, I think three different major web servers were used, a couple of different reverse proxies for load balancing, and assorted other proxies for caching and the like. As far as I'm aware, exactly none of them fully supports HTTP/2 as of today. And just to be absolutely clear, I'm talking about a collection of software that runs probably 90% of all web sites that exist today, if not more. Perhaps you would argue that the developers of all of these tools are also incompetent, in which case I refer the honourable gentleman to the answer I gave a few moments ago. It's true that there are some organisations that don't rely on mainstream networking hardware and standard software stacks any more. They really do literally design and build their own network infrastructure and write a lot of their own software stack instead of buying from the big brands. However, it's also true that I could probably count the number of such organisations in the entire world on my fingers. For everyone else, these issues do matter. Edit: Here's a handy survey of the adoption of HTTP/2 by various significant tools as of a couple of months ago. It seems broadly in line with my own experience. http://daniel.haxx.se/blog/2015/03/31/the-state-and-rate-of-http2-adoption/ http://daniel.haxx.se/blog/2015/03/31/the-state-and-rate-of-...
- MichaelGG 11y ago
  SPDY is used on about 4% of all websites, according to [1]. My assertions to MITM proxy vendors being incompetent have nothing to do with their SPDY support, and just takes into account their overall track record. I'm not sure what you're point is when you say you couldn't find many products with HTTP/2 support now. So what? They will come to market over time. Meanwhile, SPDY has more support, and is available in free software like nginx. I don't see a problem with TLS being required, and I don't really care for proxies being in the middle. Again, people that want this behavior can opt in by installing a cert and be MITM'd, and if a vendor can't get HTTP2 support, they can easily strip it until they do (and we'd hope this caching proxy is close to the user, so the perf penalty for downgrading is less). And, for a site, supporting users on crappy proxies that force a downgrade is little different than supporting older browsers that don't have SPDY or HTTP2. So they'll make a choice. What's the big deal? Who is being hurt? How could this possibly work any other way? At some point, no matter the procedure, the final version of HttpVNext would have been completed. And vendors not paying attention would be in the exact same place. 1: http://w3techs.com/technologies/details/ce-spdy/all/all http://w3techs.com/technologies/details/ce-spdy/all/all
  - Silhouette 11y ago
    What's the big deal? Who is being hurt? Anyone who for whatever reason is using HTTP/1.1 will have a much worse experience if sites start making the kinds of changes recommended in this presentation to work better with HTTP/2 today.

Silhouette 11y ago

The MITM proxies, which seem to all be written by incompetent software vendors, I'm not sure not spending time and money supporting a proprietary protocol created by an organisation with a reputation for dropping anything it doesn't like any more at short notice qualifies anyone as "incompetent". can strip out the HTTP/2 indicators and force their users back to 1. At which point anyone whose site was designed to be friendly to HTTP/2 in the ways described in the presentation will perform dramatically worse than it does under HTTP/1.1 if nothing is changed. 2 has mandatory TLS in browsers (that's how the browser vendors are making it), so random proxies and so on just remain ignorant to it. And you don't see a problem with that? We've (the Internet) have been using SPDY for a couple years now. Which Internet? A few high profile sites have been using it, but who else? Several major browsers haven't even supported SPDY until quite recently. Most don't support HTTP/2 fully yet. And in my search earlier, literally no-one was even talking about how to use some of the new capabilities to best effect server-side, never mind demonstrating server-side software that can actually do it. That's a very long beta period and gave everyone plenty of time to play around, raise objections, write software, etc. You must be joking. The kind of network monitoring and security devices I was talking about have 5-7 figure price tags in US dollars, sales cycles measured in months, purchasing cycles measured in years, and working lifetimes potentially measured in decades. Two years to understand, integrate, fully test, advertise, provide for evaluation, and ultimately sell support for a new protocol is nothing in this industry. Among the projects I have recently worked on, I think three different major web servers were used, a couple of different reverse proxies for load balancing, and assorted other proxies for caching and the like. As far as I'm aware, exactly none of them fully supports HTTP/2 as of today. And just to be absolutely clear, I'm talking about a collection of software that runs probably 90% of all web sites that exist today, if not more. Perhaps you would argue that the developers of all of these tools are also incompetent, in which case I refer the honourable gentleman to the answer I gave a few moments ago. It's true that there are some organisations that don't rely on mainstream networking hardware and standard software stacks any more. They really do literally design and build their own network infrastructure and write a lot of their own software stack instead of buying from the big brands. However, it's also true that I could probably count the number of such organisations in the entire world on my fingers. For everyone else, these issues do matter. Edit: Here's a handy survey of the adoption of HTTP/2 by various significant tools as of a couple of months ago. It seems broadly in line with my own experience. http://daniel.haxx.se/blog/2015/03/31/the-state-and-rate-of-http2-adoption/ http://daniel.haxx.se/blog/2015/03/31/the-state-and-rate-of-...

MichaelGG 11y ago
SPDY is used on about 4% of all websites, according to [1]. My assertions to MITM proxy vendors being incompetent have nothing to do with their SPDY support, and just takes into account their overall track record. I'm not sure what you're point is when you say you couldn't find many products with HTTP/2 support now. So what? They will come to market over time. Meanwhile, SPDY has more support, and is available in free software like nginx. I don't see a problem with TLS being required, and I don't really care for proxies being in the middle. Again, people that want this behavior can opt in by installing a cert and be MITM'd, and if a vendor can't get HTTP2 support, they can easily strip it until they do (and we'd hope this caching proxy is close to the user, so the perf penalty for downgrading is less). And, for a site, supporting users on crappy proxies that force a downgrade is little different than supporting older browsers that don't have SPDY or HTTP2. So they'll make a choice. What's the big deal? Who is being hurt? How could this possibly work any other way? At some point, no matter the procedure, the final version of HttpVNext would have been completed. And vendors not paying attention would be in the exact same place. 1: http://w3techs.com/technologies/details/ce-spdy/all/all http://w3techs.com/technologies/details/ce-spdy/all/all
- Silhouette 11y ago
  What's the big deal? Who is being hurt? Anyone who for whatever reason is using HTTP/1.1 will have a much worse experience if sites start making the kinds of changes recommended in this presentation to work better with HTTP/2 today.