curl Basics

Make a request from the terminal

curl is a command-line tool for transferring data to or from a URL. A basic curl <url> request sends an HTTP request and prints the response body in the terminal. This is useful in your network-recon quest because you can inspect a server without building a browser interface first.

curl https://example.com
curl -i https://example.com

The first command displays the body. The -i option includes response headers as well, which contain metadata about the reply. On Windows PowerShell, type curl.exe to run the real curl program; curl may be an alias for a different PowerShell command.

Read the status line

With headers included, find the first line of the response. It contains the HTTP version, a status code and a short reason phrase, such as HTTP/1.1 200 OK. The status code is the key part: it tells you whether the request succeeded or what kind of problem occurred.

The reason phrase is descriptive; use the numeric status as the dependable signal. Your activity asks you to inspect several outcomes, so compare the code with the response body rather than guessing from the page text alone.

Use the response as evidence

Headers can tell you details such as content type, while the body may include data or an error explanation. A 404 means the server could not find the requested resource. A 500 indicates a server-side error, not necessarily a mistake in your terminal command.

Start with a known URL, then inspect the status line and body. When a request fails, check the URL spelling and the response details. This is a small, repeatable way to build an accurate picture of what the server received and returned.

Practise safely

Use public test endpoints or the endpoints supplied for the quest. A request can have effects, especially when it changes server data, so do not experiment against systems you do not have permission to use. In the next lesson, you will add methods and request data to explore more than a basic read.

Annotate a response line by line

This is illustrative output, not evidence to submit:

HTTP/2 200
content-type: application/json
cache-control: no-cache

{"setup":"A practice question","punchline":"A practice answer"}

The first line reports the HTTP status. HTTP/2 and HTTP/3 may omit a reason phrase such as OK. The next lines are response headers; their names are case-insensitive. The blank line separates headers from the body, whose JSON fields are actual content. -i includes both; -I asks for HEAD, which is a different method and may behave differently. Use the activity's lowercase -i.

Four read-only rehearsal requests

On Mac, run these separately; in PowerShell use curl.exe in place of curl:

curl -i https://official-joke-api.appspot.com/random_joke
curl -i https://httpbin.org/status/400
curl -i https://httpbin.org/status/401
curl -i https://official-joke-api.appspot.com/not-a-real-route-4821

Expect 200, 400, 401 and 404 when those public services are functioning normally. These are deliberate test responses: the 401 here is a status simulation, not an instruction to provide a password. Some error bodies are empty; the status line still supplies evidence.

Before each request predict the category, then record the actual status and one relevant header. If a service times out or returns 503, note that result and retry once instead of copying expected output. A transport failure such as “Could not resolve host” has no completed HTTP status; it is not a 404. Curl may exit successfully after an HTTP error unless options such as --fail are used; read the HTTP code, not only the command's exit status.

Before activity 3.1, identify status, headers and body in each of your four outputs. Keep complete outputs for submission, but remove any unrelated sensitive values. Never scan private systems or invent statuses when a public endpoint is unavailable.