His reason for why HTTP/2 sucks is that it's not ambitious enough, yet when the WG chair says "v2 isn't perfect but we can always do a v3" he also gets upset.
Apparently this guy's hobby is boiling oceans. I think we can give it a rest. There's no real controversy or drama here. There's just one guy who is very vocal.
No, his reason (and everyone's reason) that HTTP/2 sucks is that it doesn't solve the problems it was intended to solve. This isn't even a topic of debate within the working group. The argument at this point is not whether or why HTTP/2 sucks, it's how to deal with that fact. The approach supported by the majority seems to be to just hurry through HTTP/2 so they can start working on HTTP/3, but PHK is arguing that they should treat current HTTP/2 code as a prototype and scrap it.
Given that supporting HTTP/2 will cost the entire industry billions of dollars while still leaving a giant security gap, I tend to agree with PHK.
> whose HTTP cache software doesn't even implement HTTP/1.1 fully.
And you've done what? You think writing BitcoinJ qualifies you to talk about HTTP/1.1? PHK was committing solid code to FreeBSD when you were still in diapers. He invented the term "bikeshedding". If we are going to discard his opinion because Varnish doesn't support HTTP/1.1 fully, we should definitely discard your opinion.
Maybe don't attack people based on their qualifications when they're more qualified than you.
IETF had no option to but to start a standardisation process around HTTP/2 otherwise SPDY would have become a de-facto standard.
The IETF have been trying to come up with the next version of HTTP for years and didn't get anywhere so perhaps Google and others forcing their hands is a good thing.
PHK has been telling everyone what's wrong with the current HTTP/2 approach since he beginning but with the exception of his session stuff has never really come up with any detail on what should be done different.
It's easy to kick HTTP/2 but the reality is it delivers many good things, not least a way for us to upgrade from it in the future.
As is SPDY is becoming the de-facto standard. If this is the role the IETF wants to relegate itself to, just slapping an "Approved" sticker on existing de-facto standards, then the IETF is already irrelevant.
I think a better role for the IETF would be to define best practices for the industry to work toward rather than simply describing what has already happened.
> PHK has been telling everyone what's wrong with the current HTTP/2 approach since he beginning but with the exception of his session stuff has never really come up with any detail on what should be done different.
Opportunistic encryption. AFAIK PHK hasn't said anything about this, but only because he doesn't need to: it's the obvious giant hole in the standard. A few people have already proposed solutions.
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?
Given that supporting HTTP/2 will cost the entire industry billions of dollars while still leaving a giant security gap
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.
And you've done what? You think writing BitcoinJ qualifies you to talk about HTTP/1.1?
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.
That said, working on Bitcoin has given me more than my fair share of debates about perfection vs pragmatism when it comes to security and privacy.
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. Those seem like laudable goals. If Varnish implemented HTTP/1.1 plus a load of extensions that had support from major browsers and sites, as opposed to a subset of it, then a position of "we must be more ambitious" would seem a lot more reasonable to me.
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.
The role of the IETF is to provide a neutral forum in which protocols can be developed. That means SPDY -> HTTP/2 is an improvement, because now development will be driven via the normal IETF process and forums. But if a committee went off and designed some dream protocol and browser makers/site operators did their own thing, it'd be for naught.
Re: opportunistic SSL, I'd like to see this too, but it's a complex issue and I defer to the judgement of browser developers on that. It isn't something someone who isn't implementing should try and force on industry de jure.
Isn't that how tech-centered controversies work? Especially in cryptography.