HTTP

HTTP (HyperText Transfer Protocol) is the web's application-layer protocol:

• HTTP Semantics (RFC 9110)
• HTTP/1.1 (RFC 9112, introduced in 1997)
• HTTP/2 (RFC 9113, introduced in 2015)
• HTTP/3 (RFC 9114)

HTTP communication occurs between a client process and a server process.

An object (HTML file, image, JavaScript, CSS file, etc.) is addressable by a single URL

HTTP/1.1 uses TCP as its underlying transport protocol:

• the HTTP client first initiates a TCP connection with the server
• once the connection is established:
  • on the client side the socket interface is the door between the client process and the TCP connection
  • on the server side the socket interface is the door between the server process and the TCP connection

TCP provides a reliable data transfer service to HTTP:

• HTTP need not worry about lost data or the details of how TCP recovers from loss or reordering of data within the network
• that is the job of TCP and the protocols in the lower layers of the protocol stack
• here we see one of the great advantages of a layered architecture

The server sends requested files to clients without storing any state information about the client:

• if a particular client asks for the same object twice in a period of a few seconds, the server does not respond by saying that it just served the object to the client
• instead, the server resends the object, as it has completely forgotten what it did earlier
• HTTP is said to be a stateless protocol

Two different browsers may interpret a web page in somewhat different ways:

• HTTP has nothing to do with how a web page is interpreted by a client
• the HTTP specifications define only the communication protocol between the client HTTP program and the server HTTP program

Non-persistent and persistent connections

The application developer needs to make an important decision:

• should each request/response pair be sent over a separate TCP connection?
  • the application is said to use non-persistent connections
• or should all of the requests and their corresponding responses be sent over the same TCP connection?
  • the application is said to use persistent connections
  • with HTTP/1.1 persistent connections (default mode), the server leaves the TCP connection open after sending a response
  • HTTP clients and servers can be configured to use non-persistent connections instead
  • the HTTP server closes a connection when it isn't used for a certain time (a configurable timeout interval)

HTTP/1.1 message format

HTTP specifications include the definitions of the HTTP message formats.

Two types of HTTP messages:

• requests
• responses

In HTTP/1.1, messages are written in ASCII text:

• lines followed by a CRLF
  • CR = carriage return (retour chariot)
  • LF = line feed (saut de ligne)
• the last line is followed by an additional CRLF

Request message

General format of an HTTP request message:

                  ┌──────────────────────────────────────────┐
Request line ─────│ method │ ␣ │ URL │ ␣ │ version │ cr │ lf │
             ┌────└──────────────────────────────────────────┘
             │    │ header field name │ ␣ │ value │ cr │ lf │
Header lines │    └─────────────────────────────────────────┘
             │    │ header field name │ ␣ │ value │ cr │ lf │
             └────└─────────┐───────────────────────────────┘
  Blank line ─────│ cr │ lf │
                  └─────────┘─────────────────────────────────────┐
                  │                                               │
 Entity body ─────│                                               │
                  │                                               │
                  └───────────────────────────────────────────────┘

After the header lines (and the additional CRLF) there is an entity body:

• empty with the GET method
• used with the POST method

Example:

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

The first line is the request line with three fields:

1. method field (GET)
2. URL field (/somedir/page.html)
3. HTTP version field (HTTP/1.1)

Subsequent lines are the header lines:

• Host: www.someschool.edu specifies the host on which the object resides (information required by web proxy caches)
• Connection: close the browser tells the server that it doesn't want persistent connections
• User-agent allows the server to send different versions to different types of user agents
• Accept-language indicates that the user prefers to receive a french version of the object
  • if such an object exists on the server
  • it's just one of many content negotiation headers available in HTTP

Response message

General format of an HTTP response message:

                  ┌────────────────────────────────────────────┐
 Status line ─────│ version │ ␣ │ code │ ␣ │ message │ cr │ lf │
             ┌────└────────────────────────────────────────────┘
             │    │ header field name │ ␣ │ value │ cr │ lf │
Header lines │    └─────────────────────────────────────────┘
             │    │ header field name │ ␣ │ value │ cr │ lf │
             └────└─────────┐───────────────────────────────┘
  Blank line ─────│ cr │ lf │
                  └─────────┘─────────────────────────────────────┐
                  │                                               │
 Entity body ─────│                                               │
                  │                                               │
                  └───────────────────────────────────────────────┘

Example:

HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2026 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2026 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html

(data data data data data ...)

The first line is the status line with three fields:

1. the protocol version (HTTP/1.1)
2. a status code (200)
3. a status message (OK)

Subsequent lines:

• Connection: close tells the client that it is going to close the TCP connection after sending the message
• Date: indicates date/time when the HTTP response was created and sent by the server
• Server: analogous to User-agent:
• Last-Modified:
  • indicates the date/time when the object was created or last modified
  • critical for object caching both in the local client and in network cache servers (proxy servers)
• Content-Length: indicates the number of bytes in the object being sent
• Content-Type: indicates that the object in the entity body is html text

User-server interaction: cookies

Cookies (RFC 6265) can be used to create a user session layer on top of stateless HTTP.

A cookie has four components:

• a cookie header line in the HTTP response message (Set-cookie: 1678)
• a cookie header line in the HTTP request message (Cookie: 1678)
• a cookie file kept on the user's end system and managed by the user's browser
• a back-end database at the web site (user 1678)

Web caching (web cache/proxy server)

A web cache (or proxy server, RFC 9111) is a network entity that satisfies HTTP requests on behalf of an origin web server.

The web cache has its own disk storage and keeps copies of recently requested objects in this storage.

A browser can be configured so that all the user's HTTP requests are first directed to the web cache.

A cache is both a server and a client at the same time:

• when it receives requests from and sends responses to a browser, it is a server
• when it sends requests to and receives responses from an origin server, it is a client

The conditional GET

Caching introduces a new problem: the copy of an object residing in the cache may be stale.

HTTP has a mechanism that allows a cache to verify that its objects are up to date: conditional GET (RFC 9110).

An HTTP request message is a conditional GET message if:

• the request message uses the GET method
• the request message includes an If-Modified-Since: header line

Example:

• on the behalf of a requesting browser, a proxy cache sends a request message to a web server:

  GET /fruit/kiwi.gif HTTP/1.1
  Host: www.exotiquecuisine.com
  

• the web server sends a response message with the requested object to the cache:

  HTTP/1.1 200 OK
  Date: Sat, 3 Oct 2026 15:39:29
  Server: Apache/1.3.0 (Unix)
  Last-Modified: Wed, 9 Sep 2026 09:23:24
  Content-Type: image/gif
  
  data…
  

• the cache:

  • forwards the object to the requesting browser
  • caches the object locally
  • stores the last-modified date along with the object

• one week later:

  • another browser requests the same object via the cache
  • the object is still in the cache

• the cache performs an up-to-date check by issuing a conditional GET:

  GET /fruit/kiwi.gif HTTP/1.1
  Host: www.exotiquecuisine.com
  If-modified-since: Wed, 9 Sep 2026 09:23:24
  

• if the object has not been modified since 9 Sep 2026 09:23:24, the web server sends this response:

  HTTP/1.1 304 Not Modified
  Date: Sat, 10 Oct 2026 15:39:29
  Server: Apache/1.3.0 (Unix)
  
  (empty entity body)
  

HTTP/2

HTTP/2 goals:

• reduce perceived latency by enabling request and response multiplexing over a single TCP connection
• provide request prioritization
• provide efficient compression of HTTP header fields
• provide server push (deprecated in modern browsers)

HTTP/2:

• does not change HTTP methods, status codes, URLs, or header fields
• changes how the data is formatted and transported between the client and server

Persistent TCP connections are used to reduce the number of sockets at the server:

• HTTP/2 has a Head of Line (HOL) blocking problem by sending all the objects in a Web page over a single TCP connection
• e.g. a large video clip at the head of the line could block the small objects behind it supposing a low-to-medium speed bottleneck link
• HTTP/1.1 browsers work around this problem by opening multiple parallel TCP connections

HTTP/2 framing:

• is a solution to remove application-layer HOL blocking:
  • it breaks each message into small frames and multiplexes them over a single TCP connection
  • as frames arrive at the client, they are reassembled into the original response
• but there is still TCP-level HOL blocking:
  • HTTP/2 runs over a single TCP connection
  • TCP enforces strict in-order byte delivery
  • if one TCP segment is lost, all later data is blocked until retransmission

Compression of HTTP header fields:

The framing sublayer uses HPACK header compression:

• binary protocols are more efficient to parse
• lead to smaller frames
• reduce overhead compared to plain text headers

Message prioritization:

• when a client sends concurrent requests, it can assign priorities to responses
• servers may use these priorities, but they are not strictly enforced in practice

Server push:

• historically allowed servers to send additional resources without explicit requests
• deprecated and disabled in most modern browsers due to limited effectiveness