Table of Contents
Origins and Purpose of HTTP
The Hypertext Transfer Protocol, or HTTP, is the foundation of data communication on the World Wide Web. When you open a web browser and visit a website, your browser and the web server talk using HTTP. HTTP defines how a client, usually a browser, requests resources such as HTML pages, images, scripts, or APIs, and how a server replies.
HTTP is a text based, application layer protocol. It uses the lower layers, for example TCP at the transport layer and IP at the network layer, but focuses only on how to structure requests and responses for web content. The design is client server. The client always initiates requests, and the server replies.
Early HTTP was very simple and worked with a single request and a single response per connection. Over time versions evolved to be more efficient and to support modern web applications.
HTTP Request Structure
Every HTTP interaction begins with a request from the client. A request has three main parts: a request line, headers, and an optional body.
The request line contains three items on one line:
- Method
- Path (or full URL in some cases)
- HTTP version
For example:
GET /index.html HTTP/1.1
The method tells the server what action the client wants to perform. The path tells the server which resource is requested. The version tells the server which HTTP features the client expects.
After the request line, the client sends headers. These are key value pairs, one per line, that provide extra information about the request. For example, the host name, the types of data the client can accept, the language preferences, and many others.
There is an empty line after the headers. After that, there can be an optional body. The body is used mainly with methods that send data to the server, for example when submitting a form or sending JSON to an API.
A simple example of an HTTP request could look like this:
::
GET /login HTTP/1.1
Host: www.example.com
User-Agent: ExampleBrowser/1.0
Accept: text/html
::
There is no body here. The blank line after the headers ends the header section.
Common HTTP Methods
HTTP defines several standard methods. These are verbs that express what the client wants to do with a resource on the server.
The most frequently used methods are:
| Method | Typical use | Has body from client |
|---|---|---|
| GET | Retrieve a resource | Usually no |
| POST | Submit data to create or process something | Usually yes |
| PUT | Replace an existing resource | Yes |
| PATCH | Partially update an existing resource | Yes |
| DELETE | Remove a resource | Rarely |
| HEAD | Same as GET but only headers, no response body | No |
| OPTIONS | Ask server which methods or options are allowed | No |
GET requests are safe and generally should not change data on the server. POST, PUT, PATCH, and DELETE are used for operations that might modify data.
Important rule: Never put sensitive data in a GET URL, because URLs are often logged, cached, and stored in browser history.
HTTP Response Structure
The server replies to each request with an HTTP response. A response has three main parts: a status line, headers, and an optional body.
The status line contains:
- HTTP version
- Status code
- Reason phrase (short text description)
For example:
HTTP/1.1 200 OK
After the status line, the server sends response headers as key value pairs. Then it sends an empty line. After that comes the response body, which usually contains the requested resource, such as HTML, CSS, JavaScript, JSON, or an image.
A simple HTTP response may look like this:
::
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 125
<html>
<head><title>Welcome</title></head>
<body>Hello, world!</body>
</html>
::
The Content-Type header tells the client how to interpret the body. The Content-Length header tells how many bytes the body contains. There are many other headers that affect caching, cookies, compression, and more.
HTTP Status Codes
Status codes are three digit numbers in the response that tell the client the result of the request. They are grouped into five classes by the first digit:
| Class | Range | Meaning |
|---|---|---|
| 1xx | 100–199 | Informational |
| 2xx | 200–299 | Success |
| 3xx | 300–399 | Redirection |
| 4xx | 400–499 | Client errors |
| 5xx | 500–599 | Server errors |
Some of the most common codes are:
| Code | Meaning |
|---|---|
| 200 | OK, request succeeded |
| 201 | Created, a new resource was created |
| 301 | Moved Permanently, new URL given |
| 302 | Found, temporarily moved |
| 304 | Not Modified, use cached version |
| 400 | Bad Request, malformed request |
| 401 | Unauthorized, authentication needed |
| 403 | Forbidden, access not allowed |
| 404 | Not Found, resource does not exist |
| 500 | Internal Server Error |
| 503 | Service Unavailable, try again later |
The status code and reason phrase together give both a numeric and a human readable description of the result.
HTTP Versions and Connections
HTTP has evolved over time. The main versions you will see are HTTP/1.0, HTTP/1.1, HTTP/2, and HTTP/3. They are all based on the same request response idea but handle connections and performance differently.
HTTP/1.0 originally used one TCP connection per request. The client opened a connection, sent one request, received one response, then closed the connection.
HTTP/1.1 introduced persistent connections by default. The same TCP connection can carry multiple requests and responses, one after another. The header Connection: keep-alive is used to keep the connection open. This reduces the overhead of opening many TCP connections.
HTTP/2 keeps the same semantics, but improves speed by allowing many requests to be multiplexed on a single connection. This means several requests and responses can be in progress at the same time. HTTP/3 does something similar but uses a different transport (QUIC over UDP), which is outside the scope of this chapter.
Persistent and multiplexed connections help reduce latency and make web pages load faster, especially pages that need many resources such as images and scripts.
Stateless Nature of HTTP and Cookies
HTTP is stateless. Each request is handled independently by the server. The server does not automatically remember anything from a previous request from the same client. This stateless design keeps the protocol simple and scalable.
However, most web applications need some form of memory. For example, staying logged in, keeping a shopping cart, or remembering user preferences. To add state on top of HTTP, servers and clients use mechanisms such as cookies, sessions, and tokens.
Cookies are small pieces of data that the server asks the browser to store and send back with later requests. This is done with headers. The server uses these cookies to link successive requests to the same user or session.
Important rule: HTTP itself is stateless. Any user session or login state is built using extra mechanisms such as cookies, not by the protocol itself.
HTTPS and the Need for Security
Plain HTTP has three major security problems:
- Data is readable by anyone who can observe the network path.
- Data can be modified by attackers without detection.
- Servers and clients cannot be sure they are talking to the right party, so impersonation is possible.
HTTPS solves these problems by combining HTTP with encryption and authentication. HTTPS is simply HTTP running inside a secure channel that uses TLS. In practice, HTTPS usually uses TCP port 443, while HTTP usually uses port 80.
With HTTPS, the content of HTTP requests and responses is encrypted. This protects confidentiality. The data is also protected by integrity checks, so any modification in transit is detected. The server presents a digital certificate, which helps the client verify that it is talking to the genuine server and not to an attacker.
From the perspective of the application layer, the HTTP messages are the same. Only the way they travel over the network differs. The encryption happens between the HTTP layer and the transport layer, so the application uses HTTP in the usual way, while the underlying channel is secure.
Important statement: HTTPS = HTTP over a secure TLS channel, usually on port 443, with encryption, integrity, and server authentication.
TLS Handshake and Certificates at a High Level
When a client connects to an HTTPS server, they first perform a TLS handshake before sending any application data.
At a very high level, the sequence is:
- The client connects to the server and proposes supported encryption options.
- The server replies with its choice of options and sends its digital certificate.
- The client checks the certificate, usually against a list of trusted certificate authorities built into the operating system or browser.
- If the certificate is trusted and valid, the client and server agree on secret keys.
- Once keys are established, they switch to encrypted communication and start exchanging HTTP requests and responses inside the secure tunnel.
Digital certificates bind a domain name, such as www.example.com, to a public key. A certificate authority signs the certificate. If the browser trusts that authority and the certificate is valid and not expired, the browser trusts that the server is who it claims to be.
If the certificate is wrong, expired, or untrusted, the browser shows a warning. Users should be careful with such warnings, because they indicate potential security issues, such as a misconfigured server or a possible attacker.
URLs and the Role of HTTP / HTTPS
When you type a web address, or URL, into the browser, the scheme at the beginning shows which protocol is used. For example, http://www.example.com uses HTTP without encryption. https://www.example.com uses HTTPS with encryption.
The browser uses the scheme to decide:
- Which default port to use.
- Whether a TLS handshake is needed.
- Which security rules to apply, for example restrictions on insecure content.
Today most websites use HTTPS by default. Many servers and browsers also apply policies that force or strongly prefer HTTPS. This trend protects users from many types of eavesdropping and manipulation.
Redirects and HTTP to HTTPS Migration
Web servers can instruct clients to use a different URL by sending a 3xx status code. This is how many sites move users from HTTP to HTTPS.
For example, if a user visits http://example.com, the server might reply with:
HTTP/1.1 301 Moved Permanently
and include a Location: https://example.com/ header. The browser then requests the new HTTPS URL. Over time, this helps move traffic to secure connections without breaking existing bookmarks or links.
Redirects are also used to change domain names, restructure sites, or handle content that has moved. From a networking point of view, they cause the browser to send another HTTP or HTTPS request to a new address.
Summary
HTTP defines the structure of web requests and responses, including methods, status codes, headers, and bodies. It uses a simple, stateless, client server model that can run over reliable transports such as TCP.
HTTPS uses HTTP inside a TLS encrypted channel to provide confidentiality, integrity, and authentication. The browser and server perform a TLS handshake, verify certificates, and then exchange normal HTTP messages through the secure tunnel.
Together, HTTP and HTTPS enable most of the web applications people use every day, from simple web pages to complex APIs and services.