4 ms·

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 yo

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.

jimktrains2 13y ago
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.
- lstamour 13y ago
  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?
  - jimktrains2 13y ago
    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.
    - lstamour 13y ago
      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 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
      "maintain 2 protocols" - actually, yes, I do expect browser vendors to maintain compatibility with HTTP 1.0, 1.1, 1.2 and 2.0+. By the way, you might be interested in 1.2: http://www.infoq.com/news/2011/04/http-1.2-released http://www.infoq.com/news/2011/04/http-1.2-released The way I see it, we can have our cake, both flavours. Why make someone remember different URLs? "http://" http://" is too entrenched for when people type it in, and I'd rather not worry about browsers trying to sniff out faster protocols as they currently do with SPDY. Better to make it a version number, even if you personally never use it.
      - teddyh 13y ago
        HTTP 1.2 is an April fools joke.
        lstamour 13y ago
        Sigh. And I knew that. Just not at 2am. (Though the way I phrased it, maybe it could slip by as an intentional link...) Thanks for pointing this out to my less tired self and anyone else who stumbles upon this thread. It's perhaps worth pointing out that HTTP 2.0 then is not an April Fools joke :D (1.0 and 1.1 was all I knew, but Google distracted me in to thinking it was real again with those dang uncorrected news articles...)

jimktrains2 13y ago

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.

lstamour 13y ago
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?
- jimktrains2 13y ago
  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.
  - lstamour 13y ago
    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 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
    "maintain 2 protocols" - actually, yes, I do expect browser vendors to maintain compatibility with HTTP 1.0, 1.1, 1.2 and 2.0+. By the way, you might be interested in 1.2: http://www.infoq.com/news/2011/04/http-1.2-released http://www.infoq.com/news/2011/04/http-1.2-released The way I see it, we can have our cake, both flavours. Why make someone remember different URLs? "http://" http://" is too entrenched for when people type it in, and I'd rather not worry about browsers trying to sniff out faster protocols as they currently do with SPDY. Better to make it a version number, even if you personally never use it.
    - teddyh 13y ago
      HTTP 1.2 is an April fools joke.
      - lstamour 13y ago
        Sigh. And I knew that. Just not at 2am. (Though the way I phrased it, maybe it could slip by as an intentional link...) Thanks for pointing this out to my less tired self and anyone else who stumbles upon this thread. It's perhaps worth pointing out that HTTP 2.0 then is not an April Fools joke :D (1.0 and 1.1 was all I knew, but Google distracted me in to thinking it was real again with those dang uncorrected news articles...)