Introduction to the HTTP Protocol: Versions, Workflow, Requests, and Responses

1. HTTP Protocol Overview

The interaction between browsers and web servers follows the HTTP protocol, an application‑layer protocol in the TCP/IP suite that defines how data is exchanged and formatted. The widely used versions are HTTP/1.0 and HTTP/1.1, with the latter adding support for persistent connections.

2. Protocol Process

2.1 HTTP/1.0 Communication Process

HTTP/1.0 supports only short connections; each request requires a separate TCP connection, even when accessing multiple pages on the same site.

2.2 HTTP/1.1 Communication Process

HTTP/1.1 supports persistent (long) connections, allowing multiple requests and responses over a single TCP connection, reducing latency and enabling pipelining where the client can send a new request before receiving the previous response.

3. HTTP Request

3.1 Request Line

The request line consists of a method, a request‑URI, and an HTTP version, followed by CRLF. Example format: Method Request-URI HTTP-Version CRLF .

The eight standard methods are GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, and OPTIONS.

3.2 Header Fields

Header fields are divided into four categories: general, request, response, and entity headers.

3.2.1 General Header Fields

Common general headers include Cache-Control, Connection, and Transfer-Encoding.

3.2.2 Request Header Fields

Typical request headers are Accept, Accept-Encoding, Accept-Language, Accept-Charset, Host, Referer, User-Agent, and Cookie.

Example Cookie header: BAIDUID=27C48D40C9CDCF48CEAAFCFD9C47FC52:FG=1; BD_UTK_DVT=1

3.2.3 Response Header Fields

Response headers are covered in section 4.

3.2.4 Entity Header Fields

Common entity headers are Content-Encoding, Content-Length, Content-Type, and Expires.

3.3 Optional Entity Body

GET requests usually have no body, while POST requests typically include an entity body. An example POST request with a body is shown in the accompanying image.

4. HTTP Response

4.1 Status Line

The status line starts with the HTTP version, followed by a three‑digit status code and a reason phrase, ending with CRLF. Status codes are grouped into five classes: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), and 5xx (server error).

4.2 Response Header Fields

Key response headers include Server, Location, Set-Cookie, and P3P, which convey server information, redirection targets, cookie settings, and privacy policies respectively.

4.3 Entity Body Types

Response bodies can be identified by Content‑Length, Transfer‑Encoding (chunked), or by closing the connection (special type).

4.3.1 Content‑Length Example

An example response with a Content‑Length header (20 bytes) is illustrated below.

4.3.2 Chunked Transfer Encoding

When the server cannot determine the body length in advance, it uses chunked encoding, indicated by the Transfer‑Encoding header. Each chunk is preceded by its size in hexadecimal, followed by CRLF, the data, and another CRLF. The final chunk size is 0.

Example test file test.php placed in the Apache document root and accessed with the following command:

echo –ne "GET /test.php HTTP/1.1\r\nHost: www.baidu.com\r\n\r\n" | nc 127.0.0.1 9000

The binary response shows the first chunk size (hex 74 = 116 bytes), followed by the chunk data, subsequent chunk sizes, and the terminating 0‑size chunk, illustrating how the client parses the chunked body.

4.3.3 Special Type (No Length Header)

If neither Content‑Length nor Transfer‑Encoding is present, the server signals the end of the response by closing the TCP connection. An example of such a response is shown below.

5. References

For the official specification, see RFC 2616: http://tools.ietf.org/html/rfc2616