Live data from Hacker News

The 7-bit Internet

blog.tabini.ca

61–70 of 162 posts

Re: The 7-bit Internet

#61
post #42
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…

Hi, I'm a programmer.

As a sysadmin, do you really have to deal with HTTP protocol by hand on such basis that a tool could not do the task for you if the protocol wasn't human readable?

Re: The 7-bit Internet

#62
post #56

Earlier quoted context omitted.

Have you never had to send a specific request/response to a server? I've often found it easier to store the request in a text file and pipe it instead of using curl or another tool to craft it. When I was a webdev (over the past few years) I did this at least once a month. I'd daily look at the HTTP headers, though. Also, I'd often add custom headers for debugging purposes. Edit: It's also not just telnet, it's being…

Most likely all HTTP/2.0 servers will continue to support HTTP/1.1 forever, so you will still be able to do this.

And clients will need to support it. I feel like the HTTP/1.0 to 1.1 switch allowed for a good deal of code reüse, but this won't.

Re: The 7-bit Internet

#63
post #53

I think TLS/SSL is the elephant in the room here. A large part of the web is effectively already using binary protocol (HTTPS), and frankly I'd wish the part was even bigger. Think of HTTP 2.0 as a successor for HTTPS instead of HTTP if it makes you feel better.

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.

Re: The 7-bit Internet

#64
post #47
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…

Well actually, your assembly example is a good one because C#, Go and a bunch of other similar languages all have refractor information compiled into the output binary because debugging machine code is a pig (even with assembly mnemonics). So even the average developer enjoys the luxury of wasted information in modern specifications.

My point was that a average programmer does not understand a thing about assembly languages, because they are abstracted away by well working implementations of compilers and debuggers. I live under an assumption that such is also the case with HTTP, or at least should be, because for me it seems that a protocol as simple as HTTP would be abstracted away ages ago by libraries and implementations.

Re: The 7-bit Internet

#65
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.

I see the proposals of binary protocols, push content, etc. as symptoms of a deeper issue.

Different than the spirit of HTTP, those protocols have little to do with publishing content anymore. They are just more kludges, in the history of kludges, to patch browsers into application platforms.

That mainly benefits the big web monopolists, who require the browser to be the ultimate application platform, where they can track to their hearts content, display unsolicited advertising, and basically extort business to advertise on their channels to remain relevant on the web. Not quite the idea of "information repository" that spawned the web in the first place.

Re: The 7-bit Internet

#66

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...

> SSL means you're already used to not looking at things through telnet. Someone has never used `openssl s_client` before. Very few people actually delve into and edit the TLS protocol. People, including devs, often delve into the HTTP protocol and craft requests by hand, or with a simple text-processing script. To most people, TLS is transparent. This HTTP 2.0 protocol is not transparent.

If you're using openssl s_client, why not use another such client? That's my point. The fact is, you type ascii because it's inconvenient to type binary, but you have software interpret bytes, so why not send what output you want, monitor what you want, using new tools. Haven't you ever used Fiddler, Charles Web Proxy, WireShark or anything else that makes binary protocols easier? Oh wait, yes, you have: openssl. My point exactly. You'll be able to unwrap the binary to ASCII representations as much as you like, no question, no harm, no foul. Or it won't get adopted.

Re: The 7-bit Internet

#67

I don't get all the for-telnet arguments. Who uses telnet for this anyway? I'd bet that 90% of telnet-folk do: cake:~ mali$ telnet google.com 80 Trying 74.125.235.8... Connected to google.com. Escape character is '^]'. GET / HTTP/1.1 ....... HTTP/1.1 200 OK Date: Wed, 10 Jul 2013 22:25:02 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 At which point they go "oh cool" and…

A lot of MUDs still use telnet. Even with MCCP (which has to be negotiated over telnet anyway), it's not uncommon for legacy clients to connect over raw telnet.

Re: The 7-bit Internet

#68
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.

It's incredibly rude to just dismiss everyone who disagrees with you like that.

Re: The 7-bit Internet

#69

Earlier quoted context omitted.

> SSL means you're already used to not looking at things through telnet. Someone has never used `openssl s_client` before. Very few people actually delve into and edit the TLS protocol. People, including devs, often delve into the HTTP protocol and craft requests by hand, or with a simple text-processing script. To most people, TLS is transparent. This HTTP 2.0 protocol is not transparent.

If you're using openssl s_client, why not use another such client? That's my point. The fact is, you type ascii because it's inconvenient to type binary, but you have software interpret bytes, so why not send what output you want, monitor what you want, using new tools. Haven't you ever used Fiddler, Charles Web Proxy, WireShark or anything else that makes binary protocols easier? Oh wait, yes, you have: openssl. My…

Because I'm not working at the TLS layer, I'm working at the HTTP layer. I'm sure if I had to often write TLS handshakes by hand, s_client wouldn't be my tool of choice, just as curl isn't always my tool of choice.

Making the protocol I'm working in binary doesn't do me any favors.

Re: The 7-bit Internet

#70

I don't get all the for-telnet arguments. Who uses telnet for this anyway? I'd bet that 90% of telnet-folk do: cake:~ mali$ telnet google.com 80 Trying 74.125.235.8... Connected to google.com. Escape character is '^]'. GET / HTTP/1.1 ....... HTTP/1.1 200 OK Date: Wed, 10 Jul 2013 22:25:02 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 At which point they go "oh cool" and…

I was just going to reply to some of these comments when I realised that everyone saying "HTTP 1.1 will still be accepted" is right. After all, the mere fact that you can telnet to so many web servers that will serve gzipped content over SSL at a drop of a hat shows how backwards-compatible the web is. Don't fool yourself into thinking that just because your connection over Telnet works, everyone's using that. That Google example makes me laugh -- since Google already does SPDY! ;-)
Post reply on HN