> No? My understanding is a whole lot of sites have deployed SPDY because it solves real problems for them, and HTTP/2 is largely the same thing. Or am I wrong?

> No? My understanding is a whole lot of sites have deployed SPDY because it solves real problems for them, and HTTP/2 is largely the same thing. Or am I wrong? Lots of sites have deployed SPDY because it is expected to result in HTTP/2 and people want to be using up-to-date technologies. I'm not sure which problems it's actually addressing, though. The changes which it actually implements so far, such as HTTP header data compression and TCP parallelism, are nice-to-haves but are frequently sidestepped by other means which are more mature. The only real benefit to the new standard seems to be some performance enhancements, many of which were possible to implement without the standard. > Leaving a giant security gap? Which gap? You must be referring to either SSL or cookies, and calling cookies a "giant security gap" is .... unhelpful, at best. Lack of defense against pervasive monitoring. There are a number of opportunistic encryption schemes which have been proposed and which have not gained traction because of various issues they cause with existing SPDY design. This is actually even worse, because HTTP/3 will almost certainly also be burdened by these same design issues because of reverse compatibility concerns. An HTTP/2 standard which doesn't include encryption may actually mean that we may have to break reverse-compatibility to get adequate encryption, or worse, that we may never get an encrypted-by-default HTTP standard. > Sigh. I've being writing software for the last 15 years, with nearly 8 of them spent at one of the worlds biggest websites. I think I'm allowed an opinion on HTTP. I agree: you should be allowed an opinion. My point was not that you shouldn't be allowed an opinion. My point was that you can't discard PHK's opinion simply because Varnish doesn't fully support HTTP/1.1. > From what I can tell by half following this debate, phk wants HTTP/2 to be even more ambitious than it already is, and the reason for not doing that is to try and ensure it actually gets deployed, implemented and the IETF stays relevant with what real deployments are actually doing. If all the standard does is define what people are already doing, then it's not relevant. It's descriptive, not prescriptive. We don't need an organization to describe what people are doing: there are plenty of blogs on the internet that do a more thorough job of that. The role of the IETF, as I see it, is to prescribe best practices for the industry, not to describe practices that are already occurring. If all that is required for an IETF standard is that a bunch of people have already done something, then the IETF has already lost relevance.