Learn Curl - Basic HTTP Requests
Running your first HTTP request with curl: understanding the body output on GET, the difference with HEAD, and dissecting verbose mode to read the request and response flow line by line.
#Introduction
After dissecting curl's architecture in episode 2 — from URL parsing to the six transfer stages — it's time for the most practical episode: running real HTTP requests. This episode is a milestone, because from here on, every command you learn can be used directly for real things: checking websites, testing APIs, and making sure servers work.
Everything we do in this episode starts from one incredibly simple command. But don't be fooled by its simplicity — behind that single line are all the concepts we've built over the previous two episodes. We'll run our first GET, understand what's displayed, then learn to "open the hood" with verbose mode.
#Your First HTTP Request
Open a terminal and run the following command:
curl https://example.comYou'll see the raw HTML from example.com flowing across the screen. This is the body of the HTTP response — exactly as explained in episode 0. Why example.com? Because IANA intentionally reserved this domain for documentation — stable, lightweight, and always available, so it's safe for practice. Since the output flows to stdout, you can pipe it straight into another command, for example curl -s https://example.com | wc -l to count its lines.
Why is the result raw, not a pretty page like in a browser? Because curl is an HTTP client, not a browser: it doesn't execute JavaScript, doesn't load CSS, doesn't render anything. What you see is exactly what the server sent — clean, with nothing added. That's actually curl's strength: you see the real data, not a rendered result.
#GET vs HEAD: -I
Now the second command:
curl -I https://example.comInstead of the HTML body, you'll see a list of response headers:
HTTP/2 200
accept-ranges: bytes
content-type: text/html; charset=UTF-8
content-length: 1256
server: ECAcc (dcd/7D17)The key difference: -I sends a HEAD method — the server answers with headers only, without sending a body. This is like calling a store and asking "do you have it in stock?" without placing the order.
It's important to understand: -I is not just "hide the body" from a normal GET request. It actually changes the method being sent to HEAD. As a consequence, the server may respond differently — some servers run special logic for HEAD. For a simple health check, HEAD is the lightweight, right choice.
Tip
Make curl -I https://example.com a habit for quick health checks: it's cheap (no body), fast, and enough to confirm the server is alive and its status code is good. If you only want to see the headers from a real GET request, use -i, which we'll cover in episode 4.
#Verbose: Opening the Hood
The two commands above only show the surface. To see everything that happens — including the request being sent and connection details — use the -v (verbose) option:
curl -v https://example.comThe output will be much longer and mixes connection details, request, and response. Let's dissect it:
* Trying 93.184.215.14:443...
* Connected to example.com (93.184.215.14) port 443
* ALPN: offers h2
* TLS handshake completed
> GET / HTTP/2
> Host: example.com
> User-Agent: curl/8.21.0
>
< HTTP/2 200
< content-type: text/html; charset=UTF-8
< content-length: 1256
<
<!doctype html>
<html>...Three prefixes determine the type of each line:
| Prefix | Meaning |
|---|---|
* | curl internal information: connection, DNS, TLS |
> | Lines sent by curl to the server (request) |
< | Lines received by curl from the server (response) |
Let's read it line by line:
* Trying 93.184.215.14:443...— curl reaches the IP from DNS resolution on port 443. This is the TCP connect stage (episode 2).* TLS handshake completed— TLS encryption was successfully agreed upon. Without this line, the connection isn't secure.> GET / HTTP/2— request line: GET method, path/, HTTP/2 protocol.> Host: example.comand> User-Agent: curl/8.21.0— headers curl sends.>(empty line) — end-of-headers marker, followed by the request body (empty for GET).< HTTP/2 200— response status line: protocol, code 200, phrase OK.<followed by an empty line — end of response headers.- The HTML body flows without a prefix — because that's the actual content.
Important
When debugging a failure, verbose mode is your first eyewitness. Notice which stage the failure happens at: no Connected line means a DNS/network problem; a TLS handshake completed but no < HTTP/... means a server application problem. Direct your debugging based on the failure location, not guesswork.
#Silent Mode: -s and -S
In the scripting world, long verbose output is actually disruptive. Curl provides two options to control the noise:
-s(--silent) — turns off the progress meter and error messages.-S(--show-error) — still shows errors even when-sis active.
The most popular combination in scripts is -sS: silent from the progress bar, but still loud when something fails.
curl -sS https://example.comCompare with pure -s: if an error occurs, -s stays completely quiet — and your script won't know what happened. That's why the -sS combination is almost always better than -s alone.
Caution
-s is not a "body noise reducer" — it only turns off the progress meter and errors. To discard the body (for example, when you only want the exit code), the curl -s -o /dev/null URL combination plus an exit code check is a neat pattern — a favorite idiom in the scripting world you'll see often.
#Dissecting Request & Response Headers
After seeing the verbose lines, let's make sure we understand some of the most common headers:
| Header | Direction | Function |
|---|---|---|
Host | Request | Specifies the target domain (important in shared hosting) |
User-Agent | Request | Client identity; curl defaults to curl/8.21.0 |
Accept | Request | Formats the client can accept |
Content-Type | Response | Media type of the body the server sends |
Content-Length | Response | Body length in bytes |
In episode 4 we'll learn to modify request headers with -H and read response headers with -i and -D.
#Closing
In this episode 3, you've run your first HTTP requests: GET displaying the body on stdout, HEAD with -I fetching only headers, reading verbose output with -v line by line (recognizing the *, >, < prefixes), and controlling noise with -s and -S.
Key takeaways:
curl URLdisplays the body on stdout; curl isn't a browser, so the result is raw.-Isends a HEAD method — headers only, great for health checks.- Verbose
-vopens the entire conversation:*connection details,>request,<response. - The failure location in verbose output determines your debugging direction.
- In scripts, use
-sS— quiet but still informs you when something fails.
In the next episode 4 we'll cover headers, response & redirect handling — sending and overriding request headers with -H, displaying and saving response headers with -i and -D, following redirects with -L, and managing cookies with -b and -c. See you in episode 4!