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

Lesson 1: You hit Enter — who starts the conversation?

Lesson objectives:

  • Name the two main actors in an HTTP exchange.
  • Explain what a URL does.
  • Identify the request and the response in a simple exchange.

Prerequisites: None | Next 2 >>

The web feels instant, but it is actually a short conversation

You type https://example.com into the browser, press Enter, and the page appears. But before anything shows up, two strangers have to agree on a language. One of them is the browser on your computer; the other is the server somewhere on the internet. The language they speak is HTTP.

HTTP is a client-server protocol (a protocol is just an agreed set of rules for a conversation): the browser (the client) starts by sending a request, and the server answers with a response 12. The address the browser uses is the URL. A URL is the address: it tells the browser which server to talk to and which page or file to ask for.

Here is the simplest version of what happens:

The point of this diagram is not every technical detail. It is the direction of the arrows: the browser always speaks first, and the server always replies.

Explanation

The browser is the client

The browser is the program that asks for things. When you press Enter, it looks at the URL, finds the server, and sends an HTTP request 1. It cannot read the page until the server sends it back.

The server is the responder

The server listens for requests. When it receives one, it decides what to send back. That answer is the HTTP response. The server might be one computer or many, but from the browser's point of view it is just "the server" 1.

The URL is the address

A URL like https://example.com/index.html has two jobs: it says which server to contact (example.com) and which resource to ask for (/index.html). The browser turns that URL into a request that the server understands.

A URL is built from named parts, and each part is read by a different actor 3:

  • The scheme is the first part, before the ://. It names the protocol to use — usually HTTPS, or its unsecured older sibling HTTP 3.
  • The authority follows the ://. It holds the domain (which server to reach) and, optionally, the port — the numbered "gate" on that server. The port is normally left out because 80 for HTTP and 443 for HTTPS are the standard ports 3.
  • The path names the resource on that server 3.
  • The query string — everything after the ? — carries extra key/value parameters for the server to use before it returns the resource 3.
  • The fragment — everything after the # — is a bookmark inside the resource. It is worth knowing that the fragment is never sent to the server; only the browser ever sees it 3.

A resource is whatever the URL names: an HTML page, an image, a stylesheet, a JSON payload. The machine that owns and answers for that resource is called the origin server 2.

A request and a response are a pair

Every HTTP exchange is one request followed by one response. That there-and-back pair is one round trip, and its cost is why the number of requests a page makes matters 4. If the response gets lost, the browser will usually ask again. There is no response without a request first 25.

Worked example (follow along)

Let's say you type https://example.com and press Enter.

  1. The browser reads the URL and decides: "I need to ask the server at example.com for the resource /."
  2. The browser sends an HTTP request that starts with:
http
GET / HTTP/1.1Host: example.com
  1. The server at example.com receives the request and sends back a response:
http
HTTP/1.1 200 OKContent-Type: text/html
  1. The browser reads the response body and displays the page.

Your turn (faded example)

Fill in the blanks in this exchange:

  1. You type a URL into the browser.
  2. The browser sends an HTTP request to the server.
  3. The server sends back an HTTP response.
  4. The browser shows the page.

Summary + what's next

In this lesson you met the four pieces of every HTTP exchange: the browser (client), the server, the URL, and the request/response pair. Next, you will look inside the request itself and learn what the browser actually writes on the envelope.

Footnotes

  1. MDN: Overview of HTTP — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview ↩ ↩2 ↩3

  2. RFC 9110: HTTP Semantics — https://www.rfc-editor.org/rfc/rfc9110.html ↩ ↩2 ↩3

  3. MDN: What is a URL? — https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_URL ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. MDN: Redirections in HTTP — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Redirections ↩

  5. MDN: HTTP messages — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages ↩

Exercises

01

Open your browser and visit any website. Without using developer tools yet, write down in plain English: what is the URL? Who is the server? Who is the client?

Level 1 (warm-up)
Done criteria · checked locally
02

Imagine a friend says, "When I press Enter, the server sends the page to my browser." Explain why that sentence is slightly wrong, and what actually happens first.

Level 2 (advanced)
Done criteria · checked locally

My note

Jot down thoughts, sticking points, things you didn't get. Written to this course's appendix only — the lesson file is never touched.