4 ms·

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, s

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.

vidarh 13y ago
> so it can't do any translations on it; You'd think so, but while it's true we can mostly pretend telnet gives you a raw TCP connection, telnet intercepts some character sequences. It just doesn't interfere much with plain text. My problem with the hypothetical "http2net" tool is that to this day I still have to deal with systems that doesn't have basic tools like tcpdump, curl or wget. But telnet, nc or some other way of getting a semi-raw tcp connection is pretty much always available. So I have every expectation that it'd take 30+ years before this "http2net" tool would be available everywhere I'd want it.
- teddyh 13y ago
  No, Telnet does not, in fact, intercept any character sequences unless when connecting to the telnet port (port 23).
  - vidarh 13y ago
    This is not true on the client I have on my OS X box at work, nor on my Debian and Ubuntu machines at home, nor, I believe, with pretty much any other telnet client I've used in the last twenty or so years. I just tested several to verify whether I'd somehow missed something so basic. Regardless of the issue of negotiated options, most telnet clients goes into a command mode if you enter an escape character, defaulting to ctrl+], unless you explicitly change it or tell it not to with a command line switch. This happens for me regardless of port. tcpdump and strace also confirms what I thought I knew, namely that it also does LF => CR+LF conversion also when connecting to other ports. EDIT: Here's a simple demonstration of how it is decidedly not 8-bit clean: echo -e "test\035help" | telnet www.google.com 80 Not only will this get you the help text for telnet rather than send the unmodified byte stream to Google's unsuspecting web server, but with default options not a single byte will generally get sent over this connection on Linux at least, as the client starts out line buffered and gets put into command mode without getting a line feed. Confirm with tcpdump, or this way if you have strace installed: echo -e "test\035help" | strace telnet www.google.com 80 2>&1 | grep sendto (the sendto calls you will get are DNS lookups)
    - teddyh 13y ago
      Right, the interactive escape character. That's easily fixed with "telnet -E". That is, echo -e "test\035help" | telnet -E www.google.com 80 will not give any help text output. (I was, in fact referring to telnet option negotiation which will not happen if not using the telnet port. Since the escape character for interactive use is so easily remedied, it did not occur to me to consider it a problem.)

vidarh 13y ago

> so it can't do any translations on it; You'd think so, but while it's true we can mostly pretend telnet gives you a raw TCP connection, telnet intercepts some character sequences. It just doesn't interfere much with plain text. My problem with the hypothetical "http2net" tool is that to this day I still have to deal with systems that doesn't have basic tools like tcpdump, curl or wget. But telnet, nc or some other way of getting a semi-raw tcp connection is pretty much always available. So I have every expectation that it'd take 30+ years before this "http2net" tool would be available everywhere I'd want it.

teddyh 13y ago
No, Telnet does not, in fact, intercept any character sequences unless when connecting to the telnet port (port 23).
- vidarh 13y ago
  This is not true on the client I have on my OS X box at work, nor on my Debian and Ubuntu machines at home, nor, I believe, with pretty much any other telnet client I've used in the last twenty or so years. I just tested several to verify whether I'd somehow missed something so basic. Regardless of the issue of negotiated options, most telnet clients goes into a command mode if you enter an escape character, defaulting to ctrl+], unless you explicitly change it or tell it not to with a command line switch. This happens for me regardless of port. tcpdump and strace also confirms what I thought I knew, namely that it also does LF => CR+LF conversion also when connecting to other ports. EDIT: Here's a simple demonstration of how it is decidedly not 8-bit clean: echo -e "test\035help" | telnet www.google.com 80 Not only will this get you the help text for telnet rather than send the unmodified byte stream to Google's unsuspecting web server, but with default options not a single byte will generally get sent over this connection on Linux at least, as the client starts out line buffered and gets put into command mode without getting a line feed. Confirm with tcpdump, or this way if you have strace installed: echo -e "test\035help" | strace telnet www.google.com 80 2>&1 | grep sendto (the sendto calls you will get are DNS lookups)
  - teddyh 13y ago
    Right, the interactive escape character. That's easily fixed with "telnet -E". That is, echo -e "test\035help" | telnet -E www.google.com 80 will not give any help text output. (I was, in fact referring to telnet option negotiation which will not happen if not using the telnet port. Since the escape character for interactive use is so easily remedied, it did not occur to me to consider it a problem.)