Hypertext Transfer Protocol (HTTP)

Introduction to HTTP

HTTP, or Hypertext Transfer Protocol, is an application-layer protocol for exchanging hypermedia documents such as HTML between web clients and servers. A browser can use it to request a resource, and a server can return the document or a response describing the operation.

HTTP uses a request-response model and a client-server model. A client such as a browser sends a request message. The server processes it and returns a response that may contain an HTML document, an image, or a status code. HTTP/2 and HTTP/3 can handle multiple streams within a connection, while each message still has the role of request or response.

Examining a web address: Uniform Resource Locator (URL)

Before sending a request, a client needs a reference to the resource. A URL (Uniform Resource Locator) is a specific type of URI (Uniform Resource Identifier) that identifies a resource and a way to access it. Its syntax can include a scheme, authority, path, query, and fragment. The authority can contain a host and an optional port, while the path identifies a resource independently of its representation format. A user-information component can also appear in a URI, although applications should treat credentials in URLs with caution. An example is http://www.cisco.com/web-server.htm.

1. Scheme: http:

   This first URL component specifies the protocol used for communication. In this example it is $http$. The $https$ scheme indicates HTTP over TLS. The scheme is followed by a colon and two forward slashes (://).

2. Host: www.cisco.com

   The host identifies the server where the resource is located. The domain name corresponds to a numerical IP address, for example $2.22.112.115$. The DNS (Domain Name System) translates the name into an address used by IP.

3. Path: /web-server.htm

   The path identifies a resource on the server. When a URL contains an authority component, the path is empty or begins with a single slash. In this example the path is /web-server.htm.

4. Optional components (not in this example):
   • Port: The service port on the server. HTTP defaults to port $80$, and HTTPS to $443$. Another port follows the host after a colon, for example :8080.
   • Query string: Starts with a question mark (?) and can carry data to the server, often as key-value pairs, for example ?search=networking&page=2. HTTP defines no single length limit; clients, servers, and intermediaries impose their own limits.
   • Fragment: Starts with a hash (#) and identifies a part of the resource, for example #section2. The fragment is processed by the client and is not sent in the HTTP request.

The HTTP request and response cycle

Each HTTP message has the role of request or response. In HTTP/1.1 a message consists of a start-line, headers, an empty line, and an optional body. The empty line separates headers from the body, while fields such as Content-Length or Transfer-Encoding help determine how content is read. A response can carry a provisional 1xx status before a final response. Some responses, including HEAD responses, carry no message content even when the corresponding GET would return a body. HTTP/2 and HTTP/3 can handle multiple streams concurrently. The message structures are shown below.

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Accept-Language: en-US
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Date: Mon, 23 May 2025 22:38:34 GMT
Server: Apache/2.4.1 (Unix)
Content-Type: text/html; charset=UTF-8
Content-Length: 122

<!DOCTYPE html>
<html>
...
</html>

HTTP methods

HTTP methods define the client's intended operation on a resource. Their safety and idempotence properties describe the intended effect, while the server can still perform logging or other internal work. A safe method is intended for read-only resource semantics, while an idempotent method has the same intended effect when repeated. Repeated requests can still produce different representations or status codes. The following methods are common in web communication.

GET

A $GET$ request retrieves a representation of a resource. Typing a URL in a browser usually sends GET. The method is safe in the HTTP sense: its intended effect on the resource is read-only, although a server may perform additional actions such as logging. GET data can be placed in a query string, which is visible in the address; HTTP sets no single maximum length, so limits come from clients, servers, and intermediaries.

POST

A $POST$ request sends data for server processing, often to create a resource. A contact form can place its data in the POST body. A body does not provide confidentiality; TLS is required for sensitive data, and its size still depends on the implementation. POST is not a safe method, and the specification does not define it as idempotent. Repeating a request can create more than one resource, depending on the implementation. POST is not idempotent, so repeated requests need not have the same intended effect.

PUT

The $PUT$ method creates or replaces a representation at the target URI. Its intended effect is idempotent, so sending the same request repeatedly should produce the same resource state, although responses can differ.

DELETE

The $DELETE$ method requests removal of the identified resource. Its intended effect is idempotent: subsequent requests should not change the state beyond the first removal, although the server can return different status codes.

HEAD

The $HEAD$ method has the semantics of GET, but the response contains no body. It retrieves the resource headers, for example to check existence, size, or modification time without downloading the content.

HTTP status codes

Every HTTP response includes a three-digit status code describing the result of processing the request. Codes from 100 through 599 are divided into five classes by their first digit. A client that does not recognize a specific code interprets it according to its class. For example, a 204 response has no content, while a 304 response indicates that a cached representation remains valid. A status code reports the request outcome, but application diagnostics require additional response data. A textual description, when supplied, helps human readers, while the code and its semantics define the result.

• 1xx (Informational): A provisional response reports progress or awaits further processing; a final response may follow. Example: $100 Continue$.
• 2xx (Success): The request was successfully received, understood, and accepted.
  • $\text{200 OK}$: The request succeeded. The response body may contain a representation of the resource.
  • $\text{201 Created}$: The request succeeded and created a new resource, for example after POST.
• 3xx (Redirection): The client must take further action to complete the request, as indicated by the response.
  • $\text{301 Moved Permanently}$: The resource has moved permanently to a new URL. A client may update stored references.
  • $302 Found$: The resource is temporarily available at another URL. A client may continue using the original URL in later requests.
• 4xx (Request error): The server cannot or will not fulfill the request because of a problem perceived in the request.
  • $\text{400 Bad Request}$: The server rejects the request because of an error, such as malformed syntax.
  • $\text{403 Forbidden}$: The server refuses to fulfill the request, for example because of an access policy.
  • $\text{404 Not Found}$: The server did not find a current representation of the target resource.
• 5xx (Server error): The server is aware that it has erred or cannot fulfill an apparently valid request.
  • $\text{500 Internal Server Error}$: A generic error code used when no more specific description is suitable.
  • $\text{503 Service Unavailable}$: The server is temporarily unable to handle the request, for example because of maintenance or overload.

The Evolution of HTTP

HTTP evolved as the number of web resources and communication requirements grew. HTTP/1.0 was described in RFC 1945 in 1996, and HTTP/1.1 in RFC 2068 in 1997. Later versions added headers, status codes, persistent connections, and more efficient transfer mechanisms. The meaning of methods and status codes remains a shared semantic layer even when the message transport differs between HTTP versions.

HTTP/0.9 - the one-line protocol (1991)

The first version was simple: a request contained one line with the $GET$ method and the resource path. The response contained the HTML file without headers, status codes, or other metadata.

HTTP/1.0 - extending the format (1996)

This version added request and response headers, status codes, and support for content types other than HTML, such as images and video. In typical use, each request opened a new TCP connection, increasing the cost of pages with many resources.

HTTP/1.1 - the standard (1997)

HTTP/1.1 introduced, among other features, persistent connections, which are the default in HTTP/1.1 and allow multiple requests on one TCP connection. It also defines request pipelining, chunked transfer, and the mandatory Host header; Keep-Alive was previously used as an HTTP/1.0 extension.

Securing the web: HTTPS

In the early web, HTTP traffic was not protected cryptographically. An observer could read data exchanged between a browser and a server. HTTPS means HTTP protected with TLS (Transport Layer Security). TLS provides confidentiality and record integrity, while certificate validation binds the server to the name in the address.

HTTPS is HTTP carried through a protection layer. The protection is provided by TLS (Transport Layer Security), formerly known as SSL (Secure Sockets Layer).

A simplified sequence is as follows:

1. Certificate verification: The server presents a TLS certificate. The certificate binds the server identity to a public key, and the client checks its trust chain and name.
2. The handshake: The client and server negotiate TLS parameters and session keys. In TLS 1.3, the server authenticates with messages including Certificate, CertificateVerify, and Finished.
3. Encrypted communication: After the keys are negotiated, later TLS records protect HTTP traffic from disclosure and modification. The protection depends on correct certificate validation and TLS configuration.

A browser reports the TLS state when the client uses an https:// address. The security assessment depends on valid certificate verification and connection parameters.

The challenge of state in a stateless protocol

One of HTTP's principles is that it is a stateless protocol. Each request should carry the information needed to process it without reconstructing earlier requests. Authorization and Cookie headers can carry data that identifies the client. A server can still retain application state and identify it through data supplied by the client.

This model simplifies independent requests, while web applications often need a session, a cart, or login state. Those values must be associated with later requests.

One mechanism is HTTP cookies. The server sends a cookie in a response header (Set-Cookie). The browser stores it and includes it in a request header (Cookie) only when domain, path, and security attributes allow it. Attributes such as Domain, Path, Max-Age, Secure, and HttpOnly limit where a cookie is used and whether scripts can access it. A cookie can contain a session identifier that lets the server find the user's state. Cookies do not change HTTP's stateless semantics; they carry a state identifier in later requests.