Client-Server Model and HTTP
Learning Objectives
- You know of the client-server model.
- You know of the HyperText Transfer Protocol (HTTP) and can identify parts of a HTTP request and a HTTP response.
Internet and client-server model
The internet is a network of networks that use the TCP/IP protocol for communication. The core principle of the internet builds on the client-server model, where servers provide resources and services to clients, as shown in Figure 1.
From an application point of view, clients are typically dependent on the servers. Clients ask for services or resources from servers. On the other hand, while servers share their resources, clients do not.
The World Summit on Information Society in 2003 highlighted that everyone should have the possibility for creating, accessing, using, and sharing information and knowledge.
This, in part, is also related to internet access The United Nations has condemned disrupting or limiting internet access and different countries take their responsibility in ensuring access to internet for all differently. As an example, Finland has declared the availability of internet as a basic right.
HyperText Transfer Protocol
Communication over TCP/IP is done using HyperText Transfer Protocol (HTTP), which is at the core of (almost) all web applications. HTTP defines the structure of messages that are sent between the client and the server.
HTTP is used with the request-response method, where a client is responsible for sending a request to the server, and the server is responsible for returning a response to the client. The overall idea is shown in Figure 2.
Messages in the HTTP-protocol are text-based. Each message consists of rows that form a request header and a set of optional rows that form a request body. The request body is not mandatory.
HTTP request structure
The first row of an HTTP request contains a request method, an identifier of the requested resource, and an indicator of the HTTP protocol. The subsequent rows may contain additional header rows, where each row has one header-value pair.
After headers, there exists an empty line, which is followed by an optional request body that has data that is sent to server. An HTTP request is ended with two line breaks.
request-method /path/to/resource HTTP/version
header1: value1
header2: value2
header3: value3
optional body with contentHTTP methods GET and POST are the most common, where GET is used to ask for a resource from a server, while POST is used for sending data to the server.
GET requests should be idempotent, i.e. GET requests should not change the state of the server. POST requests do not have to be idempotent.
The example below outlines a simple GET request with no headers.
GET / HTTP/1.0The above example contains a GET-request that asks for the resource at the root path of the server (/), using HTTP protocol version 1.0.
The resource identifier can be more complex, including a path, query parameters, and an anchor. The path is the part of the URI that comes after the domain name (e.g. /news/index.html). Query parameters come after a question mark and are used to provide additional information on what is being requested (e.g. /news/index.html?limit=10), and an anchor comes after a hash and is used to point to a specific part of a resource (e.g. /news/index.html#newest).
Some of the other often used methods are: (1) DELETE that is used for asking for removing of a resource, (2) HEAD that is used for asking for the header information related to a resource, but not the resource itself, and (3) OPTIONS that is used for asking information about the possible options available regarding a request.
The resource identifier in the HTTP request does not contain the server address, but just the identifier of the resource. When data is sent over the HTTP protocol, a connection has already been established between the client and the server using TCP/IP. Thus, there is in principle no need to tell the address of the server in the request.
However, due to the increased use of virtual servers, where multiple servers are hosted on the same physical server, the server address is needed. HTTP protocol versions since 1.1 have introduced a Host header that is included in the HTTP request and that has the server name. This way, even if an IP address has multiple servers, the specific server to which the request is meant for can be determined.
HTTP response structure
The server returns — or should return — an HTTP response for every HTTP request. The first row of an HTTP response contains the HTTP-protocol version, a HTTP-status code, and a textual clarification of the status code.
This is followed by a set of headers each on its own line, similar to the HTTP-request. The headers are followed by an empty line and a body of the response, which again similar to the HTTP-request, is not mandatory.
HTTP/version status-code status-code-clarification
header1: value
header2: value
optional body with contentA simple response that tells that the request was received and all is well would be as follows. The response uses the status code 200, which translates to “OK”.
HTTP/1.1 200 OKHTTP status codes are numeric representations that the server can use to indicate how the processing of the request went, and whether there are any (pre-specified) actions that the client (in this case, typically browser) should take.
The status codes can be divided into five high-level categories which are as follows.
- 1**: Information messages (e.g. 100 “Continue”)
- 2**: Succesful events (e.g. 200 “OK”)
- 3**: Additional actions required from the client (e.g. 301 “Moved Permanently”, which often is accompanied by a header that tells the new location, which the client then can retrieve)
- 4**: Error in the request or other issues (e.g. 401 “Not Authorized” and 404 “Not Found”)
- 5**: Error on the server e.g. 500 “Internal Server Error”)
A list of all HTTP-status codes is found on Wikipedia at https://en.wikipedia.org/wiki/List_of_HTTP_status_codes. Alternatively, you may e.g. take a peek at HTTP Cats or HTTP Status Dogs.
It is possible to also study the requests and responses using the developer console of a browser. In Chrome, you can open the developer console by pressing F12 and then selecting the Network tab. As an example, Figure 3 below shows the network tab in Chrome when visiting the address https://aged-cherry-5206.fly.dev/sum?one=43&two=-1. Some of the response headers are not visible in the image though.
HTTP uses text-based communication
Communication over the HTTP-protocol is text-based. This means that the messages are human-readable, and users with access to the network over which the messages are sent can study the messages.
Due to this, it is important to use secure connections when transmitting sensitive information. Secure connections are established using the HyperText Transfer Protocol Secure (HTTPS) protocol, which is an extension of the HTTP-protocol that uses encryption to secure the communication between the client and the server.
When using HTTPS, the connection is secured using a certificate. Current browsers support checking the status of the certificate — for example, in Chrome, there’s an icon on the left hand side of the address and clicking the icon allows checking the certificate details.
HTTP protocols
There are newer variants of the HTTP-protocol, including HTTP/2 and HTTP/3, which both aim to improve the performance of the HTTP-protocol. While HTTP and HTTP/2 are based on the TCP-protocol, HTTP/3 will work over the UDP-protocol using QUIC. In the newer protocols, the structure of the messages is similar to the original HTTP-protocol, although the way how the messages are sent and received is different.
In the context of this course, we do not distinguish between the HTTP protocols, as the key concepts of the HTTP-protocol including request methods, resource identifier, HTTP status codes, and so on, are the same across the different versions.
HTTP and retrieving a web page with a browser
The internet is often used with a browser. When a user enters a URL in the address bar of a browser, the browser makes an HTTP request to the server that hosts the resource. The server responds with an HTTP response that contains the content of the resource.
If the content is an HTML-document, the browser interprets and renders the content, showing the content to the user. While interpreting the content, the browser also detects linked resources such as images, style files, and scripts. For each linked resource, the browser automatically makes a new request to the server.
Retrieving a single web page might in reality consist of the browser making hundreds of requests, even though for the user it might seem that only a single address is visited.