Clients, servers, requests, and responses

Written Explanation

Clients and servers

In networking, client and server describe roles in a conversation:

• The client starts the conversation and asks for something. Your browser is a client. So is a mobile app, or a program calling another program.
• The server waits for requests and answers them. A server is a program (which runs on a computer, often also called a server) that stores or produces what the client wants.

MDN's overview states that in HTTP the client is typically a browser, called a user agent, and that the client always initiates the requests while the server answers each one. The server never sends a page "out of the blue" in plain HTTP. It speaks only when spoken to.

Roles can swap depending on the conversation. A backend server may, in one conversation, be the server for your phone and, in another, the client of a database. "Client" and "server" always describe the relationship at that moment.

The URL: telling the browser what to fetch

A URL (Uniform Resource Locator) is the full address of a thing on the web. A typical one has several parts:

https://www.example.com:443/shop/boots?size=42#reviews
 |        |               |   |         |       |
 scheme   host            port path     query   fragment

The fragment is for the browser and is not part of what the server needs to answer. The other parts steer the request.

The journey from URL to page

Here is the full sequence. We keep the numbers from the module's diagram: type the URL, DNS lookup, connect, request, response, render.

1. You type a URL (or click a link). The browser reads it and splits it into parts.
2. DNS lookup. The browser needs an IP address for the host. It uses the lookup process from Lesson 3: caches first, then a resolver. The result is an address such as 192.0.2.10 (illustrative).
3. Connection. The browser opens a connection to that address and the correct port. HTTP is carried over TCP, a set of rules that gives a reliable, ordered connection. MDN notes that opening a TCP connection takes several back-and-forth messages. For https, a security handshake happens here as well (Lesson 5).
4. Request. The browser sends an HTTP request over the connection, such as "GET me /shop/boots".
5. Response. The server finds or builds what was asked for and sends back an HTTP response: a status code and the content.
6. Rendering. The browser reads the content and draws the page. Rendering means turning the downloaded files (HTML, CSS, JavaScript, images) into what you see.

 Browser                    DNS                       Server
    |                        |                          |
    |-- 1. name? ----------->|                          |
    |<-- 2. IP address ------|                          |
    |                                                   |
    |-- 3. open connection ---------------------------->|
    |-- 4. request: GET /shop/boots ------------------->|
    |<-- 5. response: 200 OK + content -----------------|
    |                                                   |
    |-- 6. render the page                               |

Remember this diagram. It is also the assessment for this module.

MDN summarises the web-page journey in a very similar way: query DNS for the server's address, send an HTTP request, receive a 200 OK with the files, then assemble and display the page.

What an HTTP request looks like

HTTP messages are text in a defined layout. A request has:

• A method: what kind of action is wanted. GET means "give me this". POST means "here is some data to handle". There are others you will meet later.
• A path: which resource.
• The HTTP version.
• Headers: extra information in Name: value lines, such as the host and what languages the user prefers.
• An optional body: data for the server, used with methods such as POST.

An example request, written the way it appears on the wire:

GET /shop/boots?size=42 HTTP/1.1
Host: www.example.com
Accept-Language: en

The Host header tells the server which domain the client asked for. That is how one server can host several domains (Lesson 3).

What an HTTP response looks like

A response has:

• The HTTP version and a status code with a short message, in the first line.
• Headers, such as the type of content and its length.
• An optional body: the page, image, or data itself.

An example response:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

<!doctype html>
<html> ... the page ... </html>

The Content-Type header says what is in the body, so that the browser knows whether to draw a page, show an image, or hand the data to a script.

Status codes

The status code is a three-digit number that tells the client how the request went. The first digit gives the group:

Codes you must know:

A handy way to remember: 4xx means "your request had the problem", 5xx means "the server had the problem". As a backend developer, 5xx errors are yours to fix.

One page, many requests

When you load one page, you rarely make only one request. The first response is usually an HTML document. As the browser reads it, it finds references to other files: stylesheets, scripts, images, fonts. Each one is fetched with its own request, as MDN explains: a page is assembled from many resources, each fetched separately.

A page may therefore involve dozens of requests, to the same server and to others. The first request, for the main document, is the one you follow in Lessons 6 and 7.

HTTP is stateless

HTTP is stateless: each request stands alone, and the protocol itself does not remember earlier ones. MDN adds an important detail: stateless does not mean without sessions. Servers add memory on top using cookies: small pieces of data the server asks the browser to store and send back on later requests. That is how a shopping basket survives from one request to the next.

For you as a backend developer, this means the server must work out who is asking from the information in each request, such as a cookie, because it cannot assume "this is the same person as a moment ago".