undefined | Better HN

0 pointsfpgeek11y ago0 comments

I agree the developing world wasn't an explicit consideration, but mobile most certainly was. And since better mobile performance and behavior is what developing world Internet clients most need from a new protocol, many of their concerns are being explicitly addressed.

As for whether "shaving a couple of bytes off of a header" makes a practical difference, you should consider the "Why do we need header compression?" answer here: http://http2.github.io/faq/ which references concrete evidence provided by an HTTP2 advocate. Personally, I find that more convincing than your apparently unsupported assertion.

Separately, it's nice to say websites should drop the eye candy and the Javascript frameworks (the hundreds of requests is addressed by HTTP2 multiplexing, I believe), but that's missing the point. As has been repeatedly demonstrated since the earliest days of WAP, mobile users don't want a stripped-down subset of the Internet, they want as much as they can get. From that perspective, raising the bar on what's possible (as HTTP2 tries to do) moves the ball far more than trying to convince websites to fit themselves into today's constraints (especially since the mobile user in the developing world has one of the strictest versions of those constraints).

0 comments

2 comments · 1 top-level

jacquesm11y ago· 1 in thread

You'd have to separate out the components in HTTP2 to make sense of the various advantages offered. As long as the cookie abomination persists the header compression makes sense, but if you were to really come up with an improved HTTP then you would get rid of cookies entirely and make HTTP a stateful protocol, since that's what we seem to be headed for anyway, or at a minimum get that session stuff under control.

So now we get this terrible mix, a binary protocol that pretends to be stateful but really isn't, carries over all that's wrong from the past and replaces it with a bunch of fixes that don't seem to address the root causes of the problems.

As for mobile users wanting the full experience, sure, that's why we want better mobile networks, and preferably un-metered ones. (Which is already happening, no limit contracts are making a come-back.)

Anyway, I'm sure that HTTP2 will be implemented because Google has found a way to ram its competitive advantage down our collective throats and we'll have to live with it but I don't think the minor advantages gained here are worth the retooling required. Think of it as a missed chance, if we're going to retool then let's do it well and not in a half-assed and fast-tracked manner like this.

Feel free to disagree.

fpgeekOP11y ago

Actually, I think I now understand where we disagree. It isn't exactly where I expected.

You want a New Improved Transport Protocol that is a sharp break with HTTP's past. I agree that would be a good thing. We both agree that HTTP2 isn't that.

Where we disagree is this: You want NITP to be called HTTP2. I think doing that would be the surest way to smother NITP in its crib. In my opinion, an HTTP2 that made a radical change like not supporting cookies wouldn't be a step forward, it would just be perceived as "breaking everything" and would never get adopted.

You can't just slap HTTP's brand on a radically different protocol and expect people to not notice or care about what's inside. If you want to do something really new, that's a much longer and harder path than what we see here. That's why things like HTTP2 (making improvements where practical while carrying forward the concepts and baggage of the past) are worth doing. Because while we're waiting for a bigger leap forward, we've accumulated a set of problems we can solve and that are worth solving.

j / k navigate · click thread line to collapse