HTTP basics: reading requests and responses in the browser · Lesson 2 of 6

Lesson 2: The request envelope: method, address, and headers

Lesson objectives:

Identify the HTTP method in a request.

Identify the path or URL in a request.

Name at least one common request header and explain what it does.

Previous << 1 | Next 3 >>

A letter needs an action, an address, and a note on the envelope

When the browser sends a request, it is not just yelling "give me the page!" It writes a formal envelope. That envelope has three parts: what it wants to do, where it wants to do it, and a few extra notes for the server.

In HTTP, those three parts are called the method, the path, and the headers ¹.

Explanation

Method: the action

The HTTP method is a single word that says what the browser wants. The most common ones are:

GET — "Please send me this resource." ²
POST — "Here is some data; please accept it." ³

Most page loads use GET. HTTP defines several more: PUT replaces a resource, DELETE removes one, PATCH applies a partial modification, and HEAD asks for the same response as GET but without the body ⁴.

Safe, idempotent, cacheable

Methods differ along three properties, and the words are not synonyms ⁴:

A safe method is read-only: it is not supposed to change anything on the server. GET and HEAD are safe; POST is not ⁴.
An idempotent method can be repeated with the same end result as doing it once. GET, PUT, and DELETE are idempotent; POST is not — sending the same POST twice may create two orders ⁴.
A cacheable method may have its response stored and reused. GET is cacheable by default; POST is only conditionally cacheable ⁴.

Note what this does not say: these are semantics, a contract about meaning, not a capability the network enforces. A server is perfectly able to delete a record when it receives a GET; doing so just breaks the contract every cache, crawler, and browser prefetch relies on ⁴.

Path: the address

The path is the part of the URL that comes after the domain. For https://example.com/about, the path is /about. In the request itself, the browser writes only the path, because the domain is already sent in a header ¹⁵. Path plus query string together are called the request target — the second slot of the request line, after the method and before the protocol version ¹.

Headers: the extra notes

Headers are metadata lines that come after the request line. Each header has a name and a value, separated by a colon. For example:

The Host header tells the server which domain the request is for. The User-Agent header tells the server which browser is asking. The Accept header tells the server what kind of content the browser can handle ¹. Header names are case-insensitive ¹.

The request body

A GET request normally carries no body ². A POST does: the data being submitted travels after the headers, separated from them by one empty line ¹. Two headers describe that body — Content-Type states the format the recipient should parse it as, and Content-Length states how many bytes to read ¹³. A common form encoding is application/x-www-form-urlencoded, which packs the fields as key/value pairs the way a query string does ¹.

Once a server has sent a Set-Cookie header in some earlier response, the browser attaches the stored value back on later requests as a Cookie header ⁶. Which requests get it is decided by the cookie's Domain and Path attributes, which define its scope — what URLs the cookie is sent to ⁶. Omitting Domain is the more restrictive choice: the cookie then goes only to the exact server that set it, not to its subdomains ⁶.

Worked example (follow along)

Here is a complete GET request for https://example.com/about:

GET is the method.
/about is the path.
Host: example.com, User-Agent: LearnBrowser/1.0, and Accept: text/html are headers.

Your turn (faded example)

Underline or label each part of this request:

Method: POST
Path: /contact
Headers: Host: example.com and Content-Type: application/x-www-form-urlencoded

Summary + what's next

A request is an envelope with three parts: the method (what to do), the path (which resource), and the headers (extra notes). In the next lesson, you will look at the server's reply.

MDN: HTTP messages — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
MDN: GET request method — https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/GET ↩ ↩²
MDN: POST request method — https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/POST ↩ ↩²
MDN: HTTP request methods — https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
MDN: Overview of HTTP — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview ↩
MDN: Using HTTP cookies — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies ↩ ↩² ↩³

Exercises

Open your browser's developer tools to the Network panel (you will learn more about this in the next lesson, but the tab is usually called Network or Inspect). Reload any page. Click one request and look for its Headers section. Can you find the method and the path?

Level 1 (warm-up)

Done criteria · checked locally

You can point to the method (usually GET or POST).You can point to the path, which appears after the method in the first line.

A request has the method GET and the path /search?q=cats. Which part of the request is asking for the search results, and which part is just carrying the keyword?

Level 2 (advanced)