4 ms·

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.

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 go do something else. For the rest of us who use curl, wget, requests, Chrome / Firefox developer tools every day (who are we kidding, it's everyone, you liars! :P), the binary transformation would be transparent. Hell, if you're going for pure cool-factor, how is pulling out your hex editor less cool? But in reality, you'd never do this. For a non-standardized and obscure protocol where tooling would likely be lacking, I can see why human readability is a good idea. But we're talking about the very protocol that makes up the fabric of the internet. Seriously, why? Give me one good reason.

jimktrains2 13y ago
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 able to use simple scripts to automate requests or responses for many reasons.
- comex 13y ago
  Most likely all HTTP/2.0 servers will continue to support HTTP/1.1 forever, so you will still be able to do this.
  - jimktrains2 13y ago
    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.
    - comex 13y ago
      Minimal clients can continue to use HTTP/1.1; full-featured HTTP libraries shouldn't have much trouble adding HTTP/2.0 support.
sergiosgc 13y ago
I'll give you two, both occurred to me in the past month: 1. Debugging which headers were causing Amazon CloudFront to MISS requests originating from Android. tcpdump, observe request, repeat using netcat until the problem was pinpointed. 2. Debugging failed authentication on a dovecot IMAP, on one specific scenario. Again, tcpdump, reproduce, isolate and fix.
ddunkin 13y ago
You've never needed a basic TCP test without installing wget/nmap/etc? Most operating systems and hardware devices have telnet available for this kind of low-level troubleshooting. You've never needed to test an SMTP connection to see what the rejection message was on the remote server (when a user can't get you the bounced message you require)? You never wanted to see if an SSH port was open and what version was running? Telnet is available in every router and firewall I have, I can't install curl onto a router to generate a request from a remote network, and I'll never see wget there either. I do this stuff every day as part of my job, telnet is the go-to, the other utilities are fine, but they usually mask what I'm really looking for anyway, if they are even available on the platform I am using in the first place.
- pbsdp 13y ago
  When its easier to write tools, tools are more plentiful. Same binary protocols make it an afternoon's work to implement most protocols, and even less time if all you want to do is open up a socket and send some EHLOs. Text protocols, on the other hand, require writing a parser, dealing with encoding back and forth between string representations and binary data, handling line delimiters, etc. I'll take binary protocols any day of the week. Any cost they incur in not being human readable is offset by the value of them being so easy to implement.
  - DougWebb 13y ago
    It sounds like your argument is a preference for a pre-written parser library over having to write the parser yourself. Yeah, sure, no one would disagree with that for day to day use. It's when you don't have the pre-written library available that a text-only protocol will save your day.
    - pbsdp 13y ago
      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.
CoreDumpling 13y ago
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.
lstamour 13y ago
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! ;-)
- lstamour 13y ago
  And what if I asked for application/vnd.google.protobuf ? I don't always need 7-bit text over HTTP, after all...
ChuckMcM 13y ago
the cool kids use nc(1)
- otterley 13y ago
  Actually, we use socat.
  - ChuckMcM 13y ago
    Hrmmm, looks like socat expanded the concept to any socket. Very nice.

jimktrains2 13y ago

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 able to use simple scripts to automate requests or responses for many reasons.

comex 13y ago
Most likely all HTTP/2.0 servers will continue to support HTTP/1.1 forever, so you will still be able to do this.
- jimktrains2 13y ago
  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.
  - comex 13y ago
    Minimal clients can continue to use HTTP/1.1; full-featured HTTP libraries shouldn't have much trouble adding HTTP/2.0 support.

sergiosgc 13y ago

I'll give you two, both occurred to me in the past month: 1. Debugging which headers were causing Amazon CloudFront to MISS requests originating from Android. tcpdump, observe request, repeat using netcat until the problem was pinpointed. 2. Debugging failed authentication on a dovecot IMAP, on one specific scenario. Again, tcpdump, reproduce, isolate and fix.

ddunkin 13y ago

You've never needed a basic TCP test without installing wget/nmap/etc? Most operating systems and hardware devices have telnet available for this kind of low-level troubleshooting. You've never needed to test an SMTP connection to see what the rejection message was on the remote server (when a user can't get you the bounced message you require)? You never wanted to see if an SSH port was open and what version was running? Telnet is available in every router and firewall I have, I can't install curl onto a router to generate a request from a remote network, and I'll never see wget there either. I do this stuff every day as part of my job, telnet is the go-to, the other utilities are fine, but they usually mask what I'm really looking for anyway, if they are even available on the platform I am using in the first place.

pbsdp 13y ago
When its easier to write tools, tools are more plentiful. Same binary protocols make it an afternoon's work to implement most protocols, and even less time if all you want to do is open up a socket and send some EHLOs. Text protocols, on the other hand, require writing a parser, dealing with encoding back and forth between string representations and binary data, handling line delimiters, etc. I'll take binary protocols any day of the week. Any cost they incur in not being human readable is offset by the value of them being so easy to implement.
- DougWebb 13y ago
  It sounds like your argument is a preference for a pre-written parser library over having to write the parser yourself. Yeah, sure, no one would disagree with that for day to day use. It's when you don't have the pre-written library available that a text-only protocol will save your day.
  - pbsdp 13y ago
    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.

CoreDumpling 13y ago

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.

lstamour 13y ago

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! ;-)

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

ChuckMcM 13y ago

the cool kids use nc(1)

otterley 13y ago
Actually, we use socat.
- ChuckMcM 13y ago
  Hrmmm, looks like socat expanded the concept to any socket. Very nice.