Live data from Hacker News

The 7-bit Internet

blog.tabini.ca

21–30 of 162 posts

Re: The 7-bit Internet

#21
post #4

I don't understand why SPDY / HTTP 2.0 is being framed as "fitting the needs of a few major players". Google is not the only one who benefits from reduced latency, fast page loads, efficient use of SSL sessions, and server pushed resources. If anything, the people who benefit the most are those who _can't_ afford massive forward deployed CDN networks, large servers, and fat network pipes.

The mind-bending complexity of the proposed HTTP 2.0 does very little to gain the little guy, or a young generation exploring the web: in fact it shuts them out.

If the internet should have taught us one thing so far, it is that it's the open technologies which are built to be easy to understand and explore for humans which have driven the net forward.

HTTP 2.0 is massive step backwards in that respect, and the only thing we're getting in return is slightly shorted response times.

You know what? We can deal. We're getting better and better bandwith. We're getting more and more computing power. A few milliseconds doesn't hurt anyone.

Let's not create a shit protocol violating everything the internet was built on, just because we're all of a sudden feeling resource-constrained. Now, of all times.

rolls eyes

Re: The 7-bit Internet

#22
post #12

Oh sure, let's keep buffer bugs, waste tons of bandwidth and storage, burn millions of CPU hours in parsing computer-generated text, completely ban encryption and screw it for all non-en_US-speakers so that it could be debugged via misuse of a protocol from 1983 that no one sane uses.

I watched simple text-based internet protocols eat the efficient, ASN.1 OSI protocols for breakfast. From the OSI side of the fence.

You can talk about efficiency until you're blue in the face, but human-readability is very useful.

I used to be able to pretty much parse a hexdump of an X.400 P1 PDU by eye (certainly if I could reformat in a text editor), but even today I found it useful to eyeball a recalcitrant programs's HTTP request/response cycle by simply catching it under strace and grepping for "HTTP".

It's a massive reduction of friction to have human-readable protocols. I used to make the argument that it didn't matter and I was wrong.

Re: The 7-bit Internet

#23
post #20

For some reason, I feel as though the people in this thread against text-based protocols have never used telnet to inspect or debug an HTTP request/response. Or used telnet to help develop a client for something like memcached. The ease of discoverability of a protocol should not be underrated.

Yeah. For some things seeing truly is believing.

I guess if you've never had that moment where it all clicked for you, just by looking at traffic, the significance of human-readable protocols is easy to underestimate.

But hey, Google says that with binary-compressed headers of sorts, they can fit all their tracking cookies in one TCP-packet and that means you wont feel inconvenienced by the tracking payload they are throwing at you everywhere you go on the internet.

You know what? I want that huge bag of tracking cookies to hurt. If you violate my privacy, that should come at a cost.

Google: You can take your SPDY and keep nice, old HTTP alone.

Re: The 7-bit Internet

#24
post #5

I agree with most of the article, but would strongly argue against any use of the 'robustness principle'. There have been huge security vulnerabilities because systems disagree with each other about what is a valid request and response.

> but would strongly argue against any use of the 'robustness principle'.

It's useful for humans talking to each other. Apart from that I agree with you.

Re: The 7-bit Internet

#25
While I agree that it sucks to lose text based protocols, we already have an underlying protocol that is completely binary in nature and requires tools to look at it (TCP). Same can be said for IP. We've survived a long time with those technologies and we have some awesome tools for working with them. While it's not as easy as ascii based protocols, it's more space efficient, which I'm fine with.

Re: The 7-bit Internet

#26

If you're tempted to argue against this by pointing out that very simple tools can make irrelevant the change to a non-textual protocol -- then you are, I suspect, missing the point. There's a real psychological difference between debugging something that is, at bottom, human-readable versus one that isn't. I'm willing to concede that it isn't really that big of a difference. For the sake of argument I'm even willing…

HTTP 2.0 is not a deprecation of HTTP 1.1/1. You can have your cake and eat it too.

Never thought that it was. This is just another reason why HTTP 2.0 adoption is going to be an uphill battle.

Re: The 7-bit Internet

#27
Am I the only one who thinks its ironic that the title references 7-bits? This shows that you're already binary encoded enough that your terminal has to parse it out. Why not just have a dumber terminal?

Plus, it's SSL based. SSL means you're already used to not looking at things through telnet. Are you really saying we shouldn't use SSL because "it's not just 7-bit plaintext"? That's the point, after all...

Re: The 7-bit Internet

#29
"I’ve been in this business for two decades, and the only way I know to hand-debug a SOAP transaction is with a hammer and a straitjacket2. Heck, I’ll take an old-school EDI transaction over SOAP any day."

SOAP? You lucky. It's 2013 and I'm still knee deep in RMI-IIOP sometimes. Wireshark with GIOP dissector helps, but I’ll take SOAP over CORBA any day:-).

Seriously: Your post summarized very well what I was thinking when reading the recent HTTP 2.0 posts. Full Ack.

Re: The 7-bit Internet

#30
post #4

I don't understand why SPDY / HTTP 2.0 is being framed as "fitting the needs of a few major players". Google is not the only one who benefits from reduced latency, fast page loads, efficient use of SSL sessions, and server pushed resources. If anything, the people who benefit the most are those who _can't_ afford massive forward deployed CDN networks, large servers, and fat network pipes.

> If anything, the people who benefit the most are those who _can't_ afford massive forward deployed CDN networks, large servers, and fat network pipes.

You win some, you lose some. The benefit of cutting down on some infrastructure should be weighed against the mind-boggling complexity of HTTP 2.0 and the added difficulty in debugging.

Post reply on HN