1212HTTP is a stream-oriented protocol between two connected programs: one acting
1313as the client, the other as the server. While the connection is open, the client
1414sends an HTTP request, which the server reads and answers with an HTTP response.
15- Requests and responses are paired in order; each request has exactly one
15+ These _messages_ are paired in order; each request has exactly one
1616corresponding response. This exchange of structured messages continues until
1717either peer closes the connection, whether normally or due to an error.
1818
@@ -50,6 +50,30 @@ Hello, world!
5050
5151|===
5252
53+ More formally, the ABNF for messages is specified thusly:
54+
55+ [cols="1a,4a"]
56+ |===
57+ |Name|ABNF
58+
59+ |message
60+ |[literal]
61+ HTTP-message = request-line / status-line
62+ *( header-field CRLF )
63+ CRLF
64+ [ message-body ]
65+
66+ |request-line
67+ |[literal]
68+ request-line = method SP request-target SP HTTP-version CRLF
69+
70+ |status-line
71+ |[literal]
72+ status-line = HTTP-version SP status-code SP reason-phrase CRLF
73+
74+ |===
75+
76+
5377Most HTTP header field values are domain-specific or application-defined, while
5478certain fields commonly recur. The library understands these fields and takes
5579appropriate action to ensure RFC compliance:
@@ -58,8 +82,7 @@ appropriate action to ensure RFC compliance:
5882|===
5983|Field|Description
6084
61- |
62- [literal]
85+ |[literal]
6386https://tools.ietf.org/html/rfc7230#section-6.1[*Connection*]
6487https://tools.ietf.org/html/rfc7230#appendix-A.1.2[*Proxy-Connection*]
6588|This field lets the sender specify control options for the current connection.
@@ -77,7 +100,7 @@ The library supports the chunked, gzip, deflate, and brotli encoding schemes,
77100in any valid combination. Encodings can be automatically applied or removed
78101as needed by the caller.
79102
80- |https://tools.ietf.org/html/rfc7230#section-6.7[*Upgrade]
103+ |https://tools.ietf.org/html/rfc7230#section-6.7[*Upgrade* ]
81104|
82105
83106|===
0 commit comments