How to send an HTTP request using Telnet [closed]
Asked Answered
E

4

95

How to get a web page's content using Telnet?

For example, the content of https://stackoverflow.com/questions.

Empanel answered 2/4, 2013 at 19:10 Comment(2)
Example telnet telehack.com. List of examplesBartley
This comment/example, is far better than the highest rated answer - if using a device which doesn't have dns (such as some of the cisco routers I'm setting up) just nslookup the IP first, then connect.Berm
D
63

telnet ServerName 80


GET /index.html↵
↵

↵ means 'return', you need to hit return twice

Demonology answered 2/4, 2013 at 19:14 Comment(4)
You must add two line breaks after GET /index.html, otherwise, it wouldn't work. The end of the header section is indicated by an empty field(line), resulting in the transmission of two consecutive CR-LF pairs.from WikipediaCastrate
if you want to automate this: { echo "GET /"; sleep 1; } | telnet localhost 80 (from #7013637)Gerrit
HTTP/1.0 is really not necessary? The HTTP Specification does not mark it as opcional, but most servers seems to work without it. Is this a kind of undocumented behavior, or it is documented elsewhere?Azaleeazan
@DiegoQueiroz: IIRC it's interpreted then as "HTTP v0.9".Conidium
M
125

You could do

telnet stackoverflow.com 80

And then paste

GET /questions HTTP/1.0
Host: stackoverflow.com


# add the 2 empty lines above but not this one

Here is a transcript

$ telnet stackoverflow.com 80
Trying 151.101.65.69...
Connected to stackoverflow.com.
Escape character is '^]'.
GET /questions HTTP/1.0
Host: stackoverflow.com

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
...
Matte answered 2/4, 2013 at 19:22 Comment(4)
Hrm, it worked just fine for me (and the 'Accept' header wasn't necessary either). If you execute it quickly enough (and with the same headers as a real browser) then it would be literally impossible to tell the difference between a CLI request and one from a browser. The only way to discriminate would be to look at a greater context (e.g. follow-up requests or the lack thereof, or their timing, but even then it's not deterministic as a user might use an extension or setting to disable the loading of external resources).Bohol
There were extra spaces at the beginning of the lines that caused a HTTP/1.1 400 Bad Request response. I fixed it and included a transcript. Cheers.Meerkat
HTTP/1.0 doesn't work for me. Shouldn't it be HTTP/1.1 ?Heimlich
@Heimlich Both protocols are in common use. It would be unusual to find a general-purpose server which refuses to serve 1.0 clients, but a bespoke server for a limited purpose might well have such restrictions, though it seems more likely to be an implementor oversight than a calibrated decision.Scrotum
D
63

telnet ServerName 80


GET /index.html↵
↵

↵ means 'return', you need to hit return twice

Demonology answered 2/4, 2013 at 19:14 Comment(4)
You must add two line breaks after GET /index.html, otherwise, it wouldn't work. The end of the header section is indicated by an empty field(line), resulting in the transmission of two consecutive CR-LF pairs.from WikipediaCastrate
if you want to automate this: { echo "GET /"; sleep 1; } | telnet localhost 80 (from #7013637)Gerrit
HTTP/1.0 is really not necessary? The HTTP Specification does not mark it as opcional, but most servers seems to work without it. Is this a kind of undocumented behavior, or it is documented elsewhere?Azaleeazan
@DiegoQueiroz: IIRC it's interpreted then as "HTTP v0.9".Conidium
N
57

For posterity, your question was how to send an http request to https://stackoverflow.com/questions. The real answer is: you cannot with telnet, cause this is an https-only reachable url.

So, you might want to use openssl instead of telnet, like this for instance

$ openssl s_client -connect stackoverflow.com:443
...
---
GET /questions HTTP/1.1
Host: stackoverflow.com

This will give you the https response.

Nielson answered 5/7, 2017 at 14:53 Comment(4)
or nc --ssl stackoverflow.com 443 if netcat is installedPelagian
If the server insists on CR/LF line termination (as per the HTTP protocol spec, but frequently ignored) add -crlf to the options.Scrotum
@Pelagian On macOS nc can't do that, but brew install nmap provides ncat command with that optionUnreason
Posterity thanks you.Hypophyge
S
15

To somewhat expand on earlier answers, there are a few complications.

telnet is not particularly scriptable; you might prefer to use nc (aka netcat) instead, which handles non-terminal input and signals better.

Also, unlike telnet, nc actually allows SSL (and so https instead of http traffic -- you need port 443 instead of port 80 then).

There is a difference between HTTP 1.0 and 1.1. The recent version of the protocol requires the Host: header to be included in the request on a separate line after the POST or GET line, and to be followed by an empty line to mark the end of the request headers.

The HTTP protocol requires carriage return / line feed line endings. Many servers are lenient about this, but some are not. You might want to use

printf "%s\r\n" \
    "GET /questions HTTP/1.1" \
    "Host: stackoverflow.com" \
    "" |
nc --ssl stackoverflow.com 443

If you fall back to HTTP/1.0 you don't always need the Host: header, but many modern servers require the header anyway; if multiple sites are hosted on the same IP address, the server doesn't know from GET /foo HTTP/1.0 whether you mean http://site1.example.com/foo or http://site2.example.net/foo if those two sites are both hosted on the same server (in the absence of a Host: header, a HTTP 1.0 server might just default to a different site than the one you want, so you don't get the contents you think you are getting).

The HTTPS protocol is identical to HTTP in these details; the only real difference is in how the session is set up initially.

For what it's worth, Telnet was once a fairly ubiquitous protocol for unencrypted remote terminal access (standard port number 23). When encrypted remote access over SSH (port 22) became available in 1995, it basically caused a mass extinction of Telnet servers, but the client software still exists, and allows you to easily talk to any text-based server, such as an HTTP server (or an SMTP server, or an FTP server, or etc).

The Telnet protocol has some non-textual control sequences which of course an HTTP server will not transmit most of the time, though it could happen by accident e.g. if you triggered it to send random binary data, in which case the client could intercept the control codes and corrupt the data.

Netcat has no such protocol-specific features, and is purely a tool for putting bytes on the wire. In addition to its simpler and more robust general-purpose design, it has features to allow you to control specific behaviors of the raw socket from the command line, and to control details of its interactive behavior for scripting etc. Unlike the Telnet client, it also allows you to set up a listening socket, so a simple server.

(On some platforms, there are multiple Netcat implementations, some of which are less featureful than others. If you can't find netcat, maybe look for nc or ncat. There is also a separate tool socat which can be useful for network troubleshooting.)

Scrotum answered 8/11, 2018 at 10:56 Comment(6)
Here is a one-liner with netcat: { echo "GET / HTTP/1.1"; echo "Host: example.com"; echo; sleep 1; } | ncat --ssl example.com 443Gerrit
I don't really see any advantage over printf. Maybe the sleep helps in some situations.Scrotum
I think it does not matter, I guess printf can do more things but echo is enough in this case. I just thought it can be useful to share a one-liner with netcat.Gerrit
Awesome. A little tweak on MacOs Catalina was using ncat instead, because nc doesn't provide --ssl.Munda
If that counts as a one-liner, the printf version can certainly be folded to a single line simply by removing the newlines, too.Scrotum
The echo example also fails to include the DOS carriage returns before every newline. It can be worked around with echo -e but again that begs the question why you try to avoid the simpler, more elegant and portable printfScrotum

© 2022 - 2024 — McMap. All rights reserved.