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

71–80 of 162 posts

Re: The 7-bit Internet

#71

Post by hollerith »

weland wrote: post #32
antitrust wrote: post #13

The original idea behind the web was a publishing platform that, like a classic car, would be easy to explore, maintain and develop. The new vision is the application. Whether it's on a phone, or running as a web site, these are not publishing so much as services. Perhaps it's time to fork protocols: one for publishing, one for interactive applications.

This has been on my mind, too, for a long time. Many applications don't fit the semantic framework of the WWW anyway; why not call it a day and fork it? This way the web app crowd will be able to do their somethingJS magic without worrying about what the WWW was meant to be, and the people who use WWW for publishing can get a sane platform back on track.

That would be a big win if you can pull it off.

I wonder what is the best way to do it. convincing all owners of web apps to migrate to a new infrastructure strikes me as extremely hard. convincing the millions of 'publishers' of web writings (including all bloggers) to migrate sounds really hard, too.

Re: The 7-bit Internet

#72

Post by lstamour »

lstamour wrote: post #70
makmanalp wrote: post #45

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 G…

And what if I asked for application/vnd.google.protobuf ? I don't always need 7-bit text over HTTP, after all...

Re: The 7-bit Internet

#73

Post by lstamour »

hcarvalhoalves wrote: post #65
oconnore wrote: 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…

Right. Because the alternative, bloated pages out the wazoo makes so much more sense than having smarter Apache and Nginx servers who will do all this for you. Remember, most of the web will be connected by cell phones, we need better protocols for that.

Re: The 7-bit Internet

#74

Post by lstamour »

mbq wrote: 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'd like the re-iterate that "ban encryption" line -- do we really need to be listening in to packets on the wire? Better to capture before the wire at the web server, or after the wire in the browser.

Re: The 7-bit Internet

#75

Post by lstamour »

gdwatson wrote: post #34
kyrra wrote: post #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.

But one of the beautiful features of TCP is that it has the properties necessary to treat it as a text stream -- you can build text-based protocols on top of it. Since troubleshooting an application-level protocol seldom requires you to delve into the TCP-level, it works very well in practice. The HTTP 2.0 draft not only makes the application-level protocol binary, but it eschews the simpler stream metaphor in favor…

So don't support HTTP 2.0 if it doesn't benefit you and your use case. It's that simple. In a world where HTML5 says browsers need to pretend to be Netscape Navigator when asked, you'll never lose HTTP 1.x no matter what happens. Never.

Re: The 7-bit Internet

#76

Post by lstamour »

jimktrains2 wrote: post #69
lstamour wrote: post #66

Earlier quoted context omitted.

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.

If you're not working at the TLS layer, then why make the request over HTTP 2.0? You can just ask for 1.1 instead. If it works for Google.com, it should work for you too, right?

Re: The 7-bit Internet

#77

Post by xymostech »

itcmcgrath wrote: post #46
jperras wrote: 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.

So you are saying you are using a tool (telnet) to view/interact with the current protocol and this is good because it is easy to read and use. Now we build a different tool, let's call it http2net. With HTTP being so prevalent, perhaps it isn't unreasonable to think it becomes part of most OS distributions. So now you are using a tool (http2net) to view/interact with the new protocol and this is good because it is e…

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 be specifically for turning commands into bytes to be sent to HTTP 2.0 servers, and that response.

Re: The 7-bit Internet

#78

Post by lstamour »

bcoates wrote: post #40
zackbrown wrote: post #8

This sounds similar to an argument you could make for writing all of your code in assembly instead of C (or other higher-level languages.) Yes, there's a layer of obscurity between a program written in C and the resulting assembly: a tool (yes, a tool, spouting abstraction all over the place!) called a compiler. As a core tenet of engineering, we create tools that often leverage abstraction in order to let us tackle…

There's a broadly-held idea that passing around compiled images ready to be copied into memory as software is too fragile, arcane and low-level and that we should just put the human-readable source on the target machine to be consumed by the runtime. Isn't that directly equivalent to having a preference for a textual wire protocol?

I'm not sure the two relate. Textual is still made of bits, just more of them. As a stream, they can be checked via TCP for completeness and order, iirc. The danger, I suppose, is that they might be interpreted incorrectly, but that's why you've a versioned spec. Like SSL and HTTP itself, negotiate based on what the browser says it supports and the server prefers, and that's that. Binaries for software or "golden master" images for the OS are fragile not because they're binary, but because they aren't versioned as easily and they can deviate from the golden master. While on the web, a new golden master of your app/doc is a refresh away and there is such version negotiation.

Re: The 7-bit Internet

#79

Post by jimktrains2 »

lstamour wrote: post #76
jimktrains2 wrote: post #69

Earlier quoted context omitted.

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.

If you're not working at the TLS layer, then why make the request over HTTP 2.0? You can just ask for 1.1 instead. If it works for Google.com, it should work for you too, right?

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.

Re: The 7-bit Internet

#80

Post by comex »

jimktrains2 wrote: post #62
comex wrote: post #56

Earlier quoted context omitted.

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.

Minimal clients can continue to use HTTP/1.1; full-featured HTTP libraries shouldn't have much trouble adding HTTP/2.0 support.
Post reply on HN