A basic HTTP session

Because HTTP is a client-server protocol, an HTTP session consists of three phases:

1. The client establishes a TCP connection (or the appropriate connection if the transport layer is not TCP).
2. The client sends its request and then waits for the answer.
3. The server processes the request and sends back its answer, containing a status code and the appropriate
data.
Starting with HTTP/1.1, the connection is no longer closed after the third phase, as the client is allowed to issue
another request at this point: the second and third phases can therefore be done several times.

Establishing a connection
Because HTTP is a client-server protocol, it always is the client that establishes the connection. Opening a
connection inHTTP really is establishing a connection in the underlying transport layer, usually TCP.
With TCP, the default port for an HTTP server on a computer is port 80, though others are often used, like 8000 or
8080. The URL of a page to fetch contains both the domain name and the port number, though the latter can be
omitted if it is 80.

Note: The client-server model does not allow the server to send data to the client without an explicit request for it. To work
around this problem, web developers use several techniques: pinging the server periodically via the XMLHTTPRequest
Javascript object, using the HTML WebSockets API, or similar protocols.

Sending a client request

Once the connection is established, the user-agent can send its request. (A user-agent is typically a web browser,
but need not be.) A client request consists of text directives, separated by CRLF (carriage return, followed by line
feed), divided in three blocks:
1. The rst line contains a request method followed by its parameters:
the path of the document, i.e., an absolute URL without the protocol and the domain name
the HTTP protocol version used
2. The subsequent lines each represent a specic HTTPheader, giving the server some information about
what kind of data is appropriate (e.g., what language, what MIME types) or some data altering its behavior
(e.g., not sending an answer if it is already cached). These HTTP headers form a block that ends with an

empty line.
3. The nal block is the optional data block, which contains further data and is mainly used by the POST
method.

Example requests
Fetching the root page of developer.mozilla.org, i.e. http://developer.mozilla.org/, and telling the server that the
user-agent would prefer the page in French, if possible:

1
2
3

GET/HTTP/1.1
Host:developer.mozilla.org
AcceptLanguage:fr

Note the nal empty line, separating the data block from the headers block. As there is no ContentLength:
HTTPheader, the data block is empty and the server can process the request as soon as it receives the empty line
marking the end of the headers.
Sending the result of a form:

1
2

POST/contact_form.phpHTTP/1.1

ContentLength:64

ContentType:application/xwwwformurlencoded

5
6

name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue

Host:developer.mozilla.org

Structure of a server response

After the connected agent has sent its request, the web server handles it, and nally sends a response back.
Similarly to a client request, a server response is formed of text directives, separated by CRLF, though divided in
three dierent blocks:
1. The rst line, the status line, consists of an acknowledgment of the HTTPversion used followed by a status
request (and its meaning in human-readable text).
2. The subsequent lines each represent a specic HTTPheader giving the client some information about the
data sent (e.g., type, data size, compression algorithm used, hints about caching). Similarly to the block of
HTTPheaders for a client request, these HTTP headers form a block that ends with an empty line.
3. The nal block is the data block, which contains the data (if any).

Example responses
Successful reception of a web page

1
2
3

HTTP/1.1200OK
Date:Sat,09Oct201014:28:02GMT
Server:Apache

LastModified:Tue,01Dec200920:18:22GMT

ETag:"51142bc17449479b075b2891b"

6
7

AcceptRanges:bytes
ContentLength:29769

ContentType:text/html

10

<!DOCTYPEhtml...(herecomesthe29769bytesoftherequestedwebpage)

Notication that the requested resource has been permanently moved

HTTP/1.1301MovedPermanently

2
3

Server:Apache/2.2.3(RedHat)
ContentType:text/html;charset=iso88591

Date:Sat,09Oct201014:30:24GMT

Location:https://developer.mozilla.org/(thisisthenewlinktotheresource;itisexpected

KeepAlive:timeout=15,max=98

7
8

AcceptRanges:bytes
Via:MozCachezlb05

Connection:KeepAlive

10

XCacheInfo:caching

11

XCacheInfo:caching
ContentLength:325(thecontentcontainsadefaultpagetodisplayiftheuseragentisnota

12
13

14

<!DOCTYPEHTMLPUBLIC"//IETF//DTDHTML2.0//EN">

15
16
17
18
19
20
21
22

<html><head>
<title>301MovedPermanently</title>
</head><body>
<h1>MovedPermanently</h1>
<p>Thedocumenthasmoved<ahref="https://developer.mozilla.org/">here</a>.</p>
<hr>
<address>Apache/2.2.3(RedHat)Serveratdeveloper.mozilla.orgPort80</address>
</body></html>

Notication that the requested resource doesn't exist

1
2
3
4

HTTP/1.1404NotFound
Date:Sat,09Oct201014:33:02GMT
Server:Apache
LastModified:Tue,01May200714:24:39GMT

ETag:"499fd34e29ec42f695ca96761;48fe7523cfcc1"

6
7

AcceptRanges:bytes
ContentLength:10732

8
9
10

ContentType:text/html

<!DOCTYPEhtml...(containsasitecustomizedpagehelpingtheusertofindthemissingresour

Persistent connections
Persistent connections were introduced in HTTP/1.1. They allow transmitting several requests on the same TCP
connection (or on the specic connected transport layer if the HTTPis not built upon TCP/IP). This has several
advantages:
Because the connection can be reused, requests can be pipelined to save part of the connection latency.
By opening and closing fewer TCP connections, CPUtime is saved.
Network congestion is diminished by lowering the total amount of TCPpackets (fewer opening and closing
TCPpackets).
The TCPstack has more time to detect network congestion and to adapt its sending and receiving windows.
HTTPis more adaptive: the cost for trying a feature is considerably lowered as an error response no longer
leads to closing the connection.