Lesson 4-3 covered whose side a 502 is on.
The server side, because any 5xx means the server, or something behind it, failed.
The first digit 5 means a server-side failure, and 502 Bad Gateway specifically means a server was relaying to another server and got a bad answer back.
Keep the rule handy that 4xx is your fault and 5xx is theirs. curl is about to show you these codes constantly, and the first digit is how you decide whether to fix your request or go read the server's logs.
The engineer's HTTP tool
curl is a command-line program that sends HTTP requests and prints the response. It is on nearly every Mac, Linux box, and modern Windows machine, and it is how engineers poke at APIs and debug web problems without a browser in the way.
The basics:
curl https://example.com # GET, print the response body curl -i https://example.com # also print the response headers curl -v https://example.com # verbose: show the request too, plus connection steps curl -o page.html https://example.com # save the body to a file
Everything you learned in unit 4 is visible in curl's output. -i shows the status line and headers from lesson 4-2 sitting right on top of the body. -v goes further and narrates the whole lesson 1-2 journey: the DNS lookup, the TCP connect, the TLS handshake, then every request header (lines starting >) and response header (lines starting <).
A recorded session
A guided curl session. Each command below is paired with its output, which connects back to unit 4.
Each step below shows the command and the output it printed.
Step 1. Plain curl performs a GET and prints only the response body, here the HTML of the page.
$ curl https://example.com <!doctype html> <html> <head><title>Example Domain</title></head> <body><h1>Example Domain</h1></body> </html>
Step 2. Add -i to include the response's status line and headers, exactly the anatomy from lesson 4-2.
$ curl -i https://example.com HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 128 Cache-Control: max-age=3600 <!doctype html> <html>...</html>
Step 3. Use -v to watch the whole journey. Lines with * are connection steps, > is what curl sent, < is what came back. You can see the request line and Host header you built by hand in lesson 4-1.
$ curl -v https://example.com -o /dev/null * Trying 93.184.215.14:443... * Connected to example.com (93.184.215.14) port 443 * SSL connection using TLSv1.3 > GET / HTTP/1.1 > Host: example.com > User-Agent: curl/8.4.0 > Accept: */* > < HTTP/1.1 200 OK < Content-Type: text/html; charset=UTF-8 < Content-Length: 128 <
Step 4. One more useful trick: -s silences the progress noise and -o /dev/null throws away the body, while -w prints just what you ask for. This one-liner answers "what status code does this URL return?"
$ curl -s -o /dev/null -w '%{http_code}\n' https://example.com 200
What the > lines mean
They show the request curl sent, header by header.
> marks outgoing lines, < marks incoming lines from the response, and * marks connection events such as the DNS lookup, the TCP connect, and the TLS handshake.
Reading -v output is reading units 1 to 4 of this course happening live. The * lines are units 2 and 3, and the > and < lines are unit 4's request and response anatomy.
That makes -v the fastest way to answer "what did we actually send?" when a request behaves differently from what the code implies. Headers added by a library or a proxy show up there whether or not you wrote them.