Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The 7-bit Internet

blog.tabini.ca

Post reply on HN
Print view View original

131–140 of 162 posts

Re: The 7-bit Internet

#131

Post by archivator »

msds wrote: post #93
MichaelGG wrote: post #91

Earlier quoted context omitted.

I've written a couple parsers and stacks for SIP, a HTTP-derived protocol. The text-based aspect isn't bad in and of itself. It's the crazy moronic rules and pointlessly flexible syntax that makes it bad. It's the fact that "text-based" is often taken to mean "should allow humans to be flexible in writing it", instead of "uses ASCII". Oh, and UTF8 if you're lucky. If you dare want a non-ASCII value that needs to go i…

> Protocols are not programming languages. They don't need flexible syntax. Or, as the langsec crowd claims, protocols don't need flexible syntax, lest they actually become programming languages.

Relevant talk: Meredith Patterson on Turing-complete protocols and weird machines - https://www.youtube.com/watch?v=3kEfedtQVOY

Re: The 7-bit Internet

#132

Post by mkohlmyr »

jpatokal wrote: post #118
cmccabe wrote: post #117

Marco claims that HTTP 2.0 is overly complex, but never gives any reasons why. He claims that text protocols are better than binary, but never really gives any reason for that either. Nostalgia for the days of telnet and gopher is not a reason. Then he goes off to talk about SOAP, which he hates, because "the only way [he] know[s] to hand-debug a SOAP transaction is with a hammer and a straitjacket." But SOAP is text…

SOAP is to REST as XML is to JSON. They're all technically 7-bit and notionally human-readable, but SOAP/XML are (well, can be) so verbose as to be near-impossible to parse by hand. Comparing the "Hello World"-style simple examples on Wikipedia is instructive: REST http://example.com/resources/item17 SOAP " rel="nofollow">http://www.w3.org/2003/05/soap-envelope"> " rel="nofollow">http://www.example.org/stock"> IBM

As someone who has been having to work with various SOAP APIs over the last month - amen.

Re: The 7-bit Internet

#133

Post by ajanuary »

DougWebb wrote: post #100
MichaelGG wrote: post #91

Earlier quoted context omitted.

I've written a couple parsers and stacks for SIP, a HTTP-derived protocol. The text-based aspect isn't bad in and of itself. It's the crazy moronic rules and pointlessly flexible syntax that makes it bad. It's the fact that "text-based" is often taken to mean "should allow humans to be flexible in writing it", instead of "uses ASCII". Oh, and UTF8 if you're lucky. If you dare want a non-ASCII value that needs to go i…

What, exactly, prevents a binary protocol definition from being overly flexible and complex? I've seen quite a few like that, and I've seen quite a few simple and easy to parse text protocols.

Attitude. One of the big advantages that seems to be touted for text protocols is easy to use manually by humans, and with that can come a desire to make it forgiving of human error.

You can have simple text protocols and complex binary protocols, but it's more tempting to make text protocols more complex.

(In this comment, simple/complex is in terms of syntax only)

Re: The 7-bit Internet

#134

Post by denzquix »

9h1d9j809s wrote: post #119
sergiosgc wrote: post #63

Earlier quoted context omitted.

Wrong. An encrypted text session is different from a purely for binary session (encrypted or not). The former can be mangled from text by a generic encryption proxy, the latter needs a protocol-specific analyser.

I don't get it. Why does it matter if your tool just decrypts SSL or you use a tool that decrypts SSL and additionally unpacks the binary representation of HTTP 2.0? The output is exactly the same - plain old HTTP.

The point is that HTTP may not be the be-all end-all protocol that we will ever want to use on the open web, and encouraging any potential new protocols to take HTTP's lead and use an arbitrary binary encoding that requires protocol-specific tools to make sense of, is maybe not a decision we should take lightly.

Re: The 7-bit Internet

#135

Post by teddyh »

vidarh wrote: post #129
xymostech wrote: post #77

Earlier quoted context omitted.

I think the reason I like telnet is because I control what is being sent down the line. It's not like telnet has any contextual knowledge of what I'm sending, so it can't do any translations on it; I get to choose exactly how the bytes get sent to the server. This means that telnet can be used for every text-based protocol out there (so long as it accepts \r\n line breaks), whereas your proposed http2net tool would b…

> so it can't do any translations on it; You'd think so, but while it's true we can mostly pretend telnet gives you a raw TCP connection, telnet intercepts some character sequences. It just doesn't interfere much with plain text. My problem with the hypothetical "http2net" tool is that to this day I still have to deal with systems that doesn't have basic tools like tcpdump, curl or wget. But telnet, nc or some other…

No, Telnet does not, in fact, intercept any character sequences unless when connecting to the telnet port (port 23).

Re: The 7-bit Internet

#136

Post by zzzcpan »

cmccabe wrote: post #112
zzzcpan wrote: post #19

Earlier quoted context omitted.

Google can afford to dedicate a bunch of engineers just to deal with all these complexities and inconveniences of binary protocols, but others can't. And this is far more important than some hypothetical tiny improvements in performance.

Yeah. It's too bad there aren't free web servers out there that everyone can use that implement these protocols. Oh wait, there are. By making things more efficient, HTTP 2.0 is really going to make startups spend more money. Oh wait, no, the opposite thing.

These web servers aren't that useful for everyone, some of us have to write our own.

EDIT: It's not the matter of implementation anyways, it's that something important only for Google is proposed as a standard for everyone, which is insane.

Re: The 7-bit Internet

#137

Post by jimktrains2 »

lstamour wrote: post #114
jimktrains2 wrote: post #79

Earlier quoted context omitted.

I don't understand, HTTP is not TLS. So you're saying that we should continue to maintain 2 protocols? As some others have said, I feel that making a "webapps" protocol, a streamlined websocks or something, maybe this HTTP2.0, and keep HTTP for stateless resource representations, like it was designed to do.

Stateless? What about that hack known as cookies? Aren't they useful? How about HTML5? And what happened to the calls for SSL everywhere? Defending your cookies from the NSA and MITM? Of course we need two protocols, perhaps more than two. I'd love to see something more interesting happen with multicast given talk of IPTV in 4K. I'm shocked that your only objection ends up being the protocol name. Worse, it's the ver…

> Stateless? What about that hack known as cookies? Aren't they useful? How about HTML5?

I dislike both.

> And what happened to the calls for SSL everywhere?

It should be, it's just not HTTPs job to provide that

> I'm shocked that your only objection ends up being the protocol name.

I get upset whenever the next version of something is entirely different in philosophy and design than its predecessors. Use spdy:// or something. You can use the HTTP upgrade mechanism, or something like STS to tell a browser that it accepts the new protocol.

Re: The 7-bit Internet

#138

Post by vidarh »

teddyh wrote: post #135
vidarh wrote: post #129

Earlier quoted context omitted.

> so it can't do any translations on it; You'd think so, but while it's true we can mostly pretend telnet gives you a raw TCP connection, telnet intercepts some character sequences. It just doesn't interfere much with plain text. My problem with the hypothetical "http2net" tool is that to this day I still have to deal with systems that doesn't have basic tools like tcpdump, curl or wget. But telnet, nc or some other…

No, Telnet does not, in fact, intercept any character sequences unless when connecting to the telnet port (port 23).

This is not true on the client I have on my OS X box at work, nor on my Debian and Ubuntu machines at home, nor, I believe, with pretty much any other telnet client I've used in the last twenty or so years. I just tested several to verify whether I'd somehow missed something so basic.

Regardless of the issue of negotiated options, most telnet clients goes into a command mode if you enter an escape character, defaulting to ctrl+], unless you explicitly change it or tell it not to with a command line switch. This happens for me regardless of port.

tcpdump and strace also confirms what I thought I knew, namely that it also does LF => CR+LF conversion also when connecting to other ports.

EDIT: Here's a simple demonstration of how it is decidedly not 8-bit clean:

    echo -e "test\035help" | telnet www.google.com 80
Not only will this get you the help text for telnet rather than send the unmodified byte stream to Google's unsuspecting web server, but with default options not a single byte will generally get sent over this connection on Linux at least, as the client starts out line buffered and gets put into command mode without getting a line feed.

Confirm with tcpdump, or this way if you have strace installed:

    echo -e "test\035help" | strace telnet www.google.com 80 2>&1 | grep sendto
(the sendto calls you will get are DNS lookups)

Re: The 7-bit Internet

#139

Post by pbsdp »

vidarh wrote: post #126
pbsdp wrote: post #103

Earlier quoted context omitted.

Since binary protocols are easier to write tools for -- and difficult to us without them -- the tools get written. Slowing down everyone forever just to ease telnet debugging is a misdirected optimization.

The tools might get written . But they won't be installed on those routers, remote servers you're not getting to install stuff on and all kinds of other places where people who work with networks frequently want to be able to talk protocols from. It's largely irrelevant to me if there are tools out the wazoo to work with some binary protocol if I'm unable to run that tool everywhere. And there's a huge range between…

This is just scaremongering. Installing the command line LDAP tools (which is a horrendous binary protocol) is no harder than installing netcat or tcpdunp.

Re: The 7-bit Internet

#140

Post by snuxoll »

dsr_ wrote: post #42
zxcdw wrote: post #35

Earlier quoted context omitted.

> * but human-readability is very useful.* For who, how often and when exactly? As far as I have understood, we are doing something wrong if we have to deal with debugging protocols which implement an abstraction, rather than just let the abstraction do it's job. This is like saying that "Well for programmers x86 assembly instruction mnemonics are useful compared to machine code bytes!", to which one could say that f…

I'm starting to feel like I start all my HN posts with "Hi, I'm a sysadmin." Hi, I'm a sysadmin. Sometimes we have to debug things that are on the other side of the world. When we do that, we need to have a mental model of what we're doing. You're familiar with that as a software developer: you have a mental model of the capabilities of the language that you are using, and you are fitting that in with the mental mode…

If you are using telnet on your smartphone at 0400 on vacation you should probably have access to an SSH client that you can use to get on a real system to run curl on.
Post reply on HN