5 ms·
> His reason for why HTTP/2 sucks is that it's not ambitious enough No, his reason (and everyone's reason) that HTTP/2 sucks is that it doesn't solve the probl
by copsarebastards 12y ago
> His reason for why HTTP/2 sucks is that it's not ambitious enough
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.
- youngtaff 12y agoWhether HTTP/2 sucks is a matter of opinion - yes it has some technical compromises but it delivers a faster experience for browsers (not always though) by overcoming some of the latency penalty inherent in modern web pages. 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.
- copsarebastards 12y ago> IETF had no option to but to start a standardisation process around HTTP/2 otherwise SPDY would have become a de-facto standard. 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.
- mike_hearn 12y agoNo, his reason (and everyone's reason) that HTTP/2 sucks is that it doesn't solve the problems it was intended to solve 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.
- copsarebastards 12y ago> 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.