4 ms·
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 i
by lstamour 13y ago
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...
- jimktrains2 13y ago> 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.
- lstamour 13y agoIf 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.
- jimktrains2 13y agoBecause 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.
- lstamour 13y agoIf 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?
- jimktrains2 13y agoI 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.
- lstamour 13y agoStateless? 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 version number. But hey, it is semantic versioning... Don't use it if you don't want to. It's not like anyone else will notice if your site is already fast because it's one request with no state.
- jimktrains2 13y ago> 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.
- lstamour 13y ago