Introduction
Web testing starts with understanding ordinary HTTP behavior. A successful connection, a status code, response metadata, and page content each provide a different part of the picture.
This lab supplies a local web service so you can inspect GET and HEAD requests with curl. You will read its responses and preserve useful headers and content without directory guessing, injection, or authentication bypass.
Read an HTTP Resource and Its Status
In this step, you will use curl to inspect a local HTTP resource and distinguish application status from connection success.
Enter Kali and select the shared workspace:
kali
cd /home/labex/project
A URL such as http://127.0.0.1:8080/scope.txt identifies a scheme (http), host (127.0.0.1), optional port (8080), and path (/scope.txt). The host and port choose the service; the path chooses a resource inside that service.
Curl makes requests to URLs. Its default HTTP method is GET, which asks for a representation of a resource. Request the training page:
curl http://127.0.0.1:8080/
The response body is an HTML page containing the title Kali Training Welcome. Curl prints the body as text; it does not render the page like a web browser.
The -i option includes response headers in the displayed output. Inspect the scope resource:
curl -i http://127.0.0.1:8080/scope.txt
The status line reports 200 OK, followed by headers, a blank line, and the body Authorized local training only. HTTP headers describe the response; the body carries its content.
Request a path that the supplied server does not provide:
curl -i http://127.0.0.1:8080/missing
This returns 404 Not Found with a short body. The TCP connection and HTTP exchange still succeeded; the application reports that the requested resource does not exist. Curl without a failure-on-status option can exit successfully for an HTTP 404, so read the response status rather than assuming that every completed request is a valid resource.
-o writes the body to a named file. -s hides the progress meter, while -S still shows an error if a transfer fails; they combine as -sS. Save the scope text:
curl -sS -o scope.txt http://127.0.0.1:8080/scope.txt
cat scope.txt
Expected output:
Authorized local training only.
You saved the response body rather than a hand-typed description of it.
Save Response Headers Separately from the Body
In this step, you will compare GET and HEAD and preserve the server's headers and page as separate artifacts.
The -I option (capital I) asks curl to send a HEAD request. HEAD requests the response metadata without transferring the resource body:
curl -I http://127.0.0.1:8080/
Look for 200 OK, Content-Type: text/html, and the training-site header. The response does not include the HTML body. A content-length header can still describe how large the corresponding GET body would be.
Use GET when you need the actual content. Curl's -D option writes response headers to the filename after it, and -o writes the body to a different file:
curl -sS -D response-headers.txt -o page.html http://127.0.0.1:8080/
Read the saved metadata:
cat response-headers.txt
It should include a successful status, HTML content type, and X-Training-Site: guided-web. Server and date fields may vary.
Read the body separately:
cat page.html
Expected content:
<html><title>Kali Training Welcome</title><body>Local practice site.</body></html>
Headers and body answer different questions: the former describe how the server responded, while the latter contain the requested resource. Keeping them separate makes later comparisons and text processing easier.
Summary
You interpreted URL components, made GET and HEAD requests, distinguished HTTP status from connection success, and inspected headers and body. You saved the original response metadata and page content separately for later analysis.
