3.1. Known-Length Messages

A request or response that has a known length at the time of construction uses the format shown in Figure 1.¶

Known-Length Request {
  Framing Indicator (i) = 0,
  Request Control Data (..),
  Known-Length Field Section (..),
  Known-Length Content (..),
  Known-Length Field Section (..),
  Padding (..),
}

Known-Length Response {
  Framing Indicator (i) = 1,
  Known-Length Informational Response (..) ...,
  Final Response Control Data (..),
  Known-Length Field Section (..),
  Known-Length Content (..),
  Known-Length Field Section (..),
  Padding (..),
}

Known-Length Field Section {
  Length (i),
  Field Line (..) ...,
}

Known-Length Content {
  Content Length (i),
  Content (..),
}

Known-Length Informational Response {
  Informational Response Control Data (..),
  Known-Length Field Section (..),
}

A known-length request consists of a framing indicator (Section 3.3), request control data (Section 3.4), a header section with a length prefix, binary content with a length prefix, a trailer section with a length prefix, and padding.¶

A known-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (Section 3.5.1) followed by response control data (Section 3.5).¶

For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer. This integer is the number of bytes in the field section or content, not including the length field itself.¶

Fields in the header and trailer sections consist of a length-prefixed name and length-prefixed value; see Section 3.6.¶

The format allows for the message to be truncated before any of the length prefixes that precede the field sections or content; see Section 3.8.¶

The variable-length integer encoding means that there is a limit of 2⁶²-1 bytes for each field section and the message content.¶

3.2. Indeterminate-Length Messages

A request or response that is constructed without encoding a known length for each section uses the format shown in Figure 2:¶

Indeterminate-Length Request  {
  Framing Indicator (i) = 2,
  Request Control Data (..),
  Indeterminate-Length Field Section (..),
  Indeterminate-Length Content (..),
  Indeterminate-Length Field Section (..),
  Padding (..),
}

Indeterminate-Length Response  {
  Framing Indicator (i) = 3,
  Indeterminate-Length Informational Response (..) ...,
  Final Response Control Data (..),
  Indeterminate-Length Field Section (..),
  Indeterminate-Length Content (..),
  Indeterminate-Length Field Section (..),
  Padding (..),
}

Indeterminate-Length Content {
  Indeterminate-Length Content Chunk (..) ...,
  Content Terminator (i) = 0,
}

Indeterminate-Length Content Chunk {
  Chunk Length (i) = 1..,
  Chunk (..),
}

Indeterminate-Length Field Section {
  Field Line (..) ...,
  Content Terminator (i) = 0,
}

Indeterminate-Length Informational Response {
  Informational Response Control Data (..),
  Indeterminate-Length Field Section (..),
}

An indeterminate-length request consists of a framing indicator (Section 3.3), request control data (Section 3.4), a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, a trailer section that is terminated by a zero value, and padding.¶

An indeterminate-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (Section 3.5.1) and response control data (Section 3.5).¶

The indeterminate-length encoding only uses length prefixes for content blocks. Multiple length-prefixed portions of content can be included, each prefixed by a non-zero Chunk Length integer describing the number of bytes in the block. The Chunk Length is encoded as a variable-length integer.¶

Each Field Line in an Indeterminate-Length Field Section starts with a Name Length field. An Indeterminate-Length Field Section ends with a Content Terminator field. The zero value of the Content Terminator distinguishes it from the Name Length field, which cannot contain a value of 0.¶

Indeterminate-length messages can be truncated in a way similar to that for known-length messages; see Section 3.8.¶

Indeterminate-length messages use the same encoding for Field Line as known-length messages; see Section 3.6.¶

3.3. Framing Indicator

The start of each binary message is a framing indicator that is a single integer that describes the structure of the subsequent sections. The framing indicator can take just four values:¶

• A value of 0 describes a request of known length.¶
• A value of 1 describes a response of known length.¶
• A value of 2 describes a request of indeterminate length.¶
• A value of 3 describes a response of indeterminate length.¶

Other values cause the message to be invalid; see Section 4.¶

3.4. Request Control Data

The control data for a request message contains the method and request target. That information is encoded as an ordered sequence of fields: Method, Scheme, Authority, Path. Each of these fields is prefixed with a length.¶

The values of these fields follow the rules in HTTP/2 (Section 8.3.1 of [HTTP/2]) that apply to the ":method", ":scheme", ":authority", and ":path" pseudo-header fields, respectively. However, where the ":authority" pseudo-header field might be omitted in HTTP/2, a zero-length value is encoded instead.¶

The format of request control data is shown in Figure 3.¶

Request Control Data {
  Method Length (i),
  Method (..),
  Scheme Length (i),
  Scheme (..),
  Authority Length (i),
  Authority (..),
  Path Length (i),
  Path (..),
}

3.5. Response Control Data

The control data for a response message consists of the status code. The status code (Section 15 of [HTTP]) is encoded as a variable-length integer, not a length-prefixed decimal string.¶

The format of final response control data is shown in Figure 4.¶

Final Response Control Data {
  Status Code (i) = 200..599,
}

Informational Response Control Data {
  Status Code (i) = 100..199,
}

3.6. Header and Trailer Field Lines

Header and trailer sections consist of zero or more field lines; see Section 5 of [HTTP]. The format of a field section depends on whether the message is of known length or indeterminate length.¶

Each Field Line encoding includes a name and a value. Both the name and value are length-prefixed sequences of bytes. The Name field is a minimum of one byte. The format of a Field Line is shown in Figure 6.¶

Field Line {
  Name Length (i) = 1..,
  Name (..),
  Value Length (i),
  Value (..),
}

For field names, byte values that are not permitted in an HTTP field name cause the message to be invalid; see Section 5.1 of [HTTP] for a definition of what is valid and Section 4 regarding the handling of invalid messages. A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed according to Section 8.2.1 of [HTTP/2] as invalid; see Section 4.¶

The same field name can be repeated over more than one field line; see Section 5.2 of [HTTP] for the semantics of repeated field names and rules for combining values.¶

Messages are invalid (Section 4) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status". Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see Section 8.1 of [HTTP/2]). A Field Line containing pseudo-fields MUST precede other Field Line values. A message that contains a pseudo-field after any other field is invalid; see Section 4.¶

Fields that relate to connections (Section 7.6.1 of [HTTP]) cannot be used to produce the effect on a connection in this context. These fields SHOULD be removed when constructing a binary message. However, they do not cause a message to be invalid (Section 4); permitting these fields allows a binary message to capture messages that are exchanged in a protocol context.¶

Like HTTP/2 or HTTP/3, this format has an exception for the combination of multiple instances of the Cookie field. Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon octet (0x3b) rather than a comma; see Section 8.2.3 of [HTTP/2].¶

3.7. Content

The content of messages is a sequence of bytes of any length. Though a known-length message has a limit, this limit is large enough that it is unlikely to be a practical limitation. There is no limit to the size of content in an indeterminate-length message.¶

3.8. Padding and Truncation

Messages can be padded with any number of zero-valued bytes. Non-zero padding bytes cause a message to be invalid (see Section 4). Unlike other parts of a message, a processor MAY decide not to validate the value of padding bytes.¶

Truncation can be used to reduce the size of messages that have no data in trailing field sections or content. If the trailers of a message are empty, they MAY be omitted by the encoder in place of adding a length field equal to zero. An encoder MAY omit empty content in the same way if the trailers are also empty. A message that is truncated at any other point is invalid; see Section 4.¶

Decoders MUST treat missing truncated fields as equivalent to having been sent with the length field set to zero.¶

Padding is compatible with truncation of empty parts of the messages. Zero-valued bytes will be interpreted as a zero-length part, which is semantically equivalent to the part being absent.¶

5.1. Request Example

The example HTTP/1.1 message in Figure 7 shows the content in the "message/http" format.¶

Valid HTTP/1.1 messages require lines terminated with CRLF (the two bytes 0x0d and 0x0a). For simplicity and consistency, the content of these examples is limited to text, which also uses CRLF for line endings.¶

GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi

This can be expressed as a binary message (type "message/bhttp") using a known-length encoding as shown in hexadecimal in Figure 8. Figure 8 includes text alongside to show that most of the content is not modified.¶

00034745 54056874 74707300 0a2f6865  ..GET.https../he
6c6c6f2e 74787440 6c0a7573 65722d61  [email protected]
67656e74 34637572 6c2f372e 31362e33  gent4curl/7.16.3
206c6962 6375726c 2f372e31 362e3320   libcurl/7.16.3
4f70656e 53534c2f 302e392e 376c207a  OpenSSL/0.9.7l z
6c69622f 312e322e 3304686f 73740f77  lib/1.2.3.host.w
77772e65 78616d70 6c652e63 6f6d0f61  ww.example.com.a
63636570 742d6c61 6e677561 67650665  ccept-language.e
6e2c206d 690000                      n, mi..

This example shows that the Host header field is not replicated in the ":authority" field, as is required for ensuring that the request is reproduced accurately; see Section 8.3.1 of [HTTP/2].¶

The same message can be truncated with no effect on interpretation. In this case, the last two bytes -- corresponding to content and a trailer section -- can each be removed without altering the semantics of the message.¶

The same message, encoded using an indeterminate-length encoding, is shown in Figure 9. As the content of this message is empty, the difference in formats is negligible.¶

02034745 54056874 74707300 0a2f6865  ..GET.https../he
6c6c6f2e 7478740a 75736572 2d616765  llo.txt.user-age
6e743463 75726c2f 372e3136 2e33206c  nt4curl/7.16.3 l
69626375 726c2f37 2e31362e 33204f70  ibcurl/7.16.3 Op
656e5353 4c2f302e 392e376c 207a6c69  enSSL/0.9.7l zli
622f312e 322e3304 686f7374 0f777777  b/1.2.3.host.www
2e657861 6d706c65 2e636f6d 0f616363  .example.com.acc
6570742d 6c616e67 75616765 06656e2c  ept-language.en,
206d6900 00000000 00000000 00000000   mi.............

This indeterminate-length encoding contains 10 bytes of padding. As two additional bytes can be truncated in the same way as the known-length example, anything up to 12 bytes can be removed from this message without affecting its meaning.¶

5.2. Response Example

Response messages can contain interim (1xx) status codes, as the message in Figure 10 shows. Figure 10 includes examples of informational status codes 102 and 103, as defined in [RFC2518] (now obsolete but defines status code 102) and [RFC8297], respectively.¶

HTTP/1.1 102 Processing
Running: "sleep 15"

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Hello World! My content includes a trailing CRLF.

As this is a longer example, only the indeterminate-length encoding is shown in Figure 11. Note here that the specific text used in the reason phrase is not retained by this encoding.¶

03406607 72756e6e 696e670a 22736c65  [email protected]."sle
65702031 35220040 67046c69 6e6b233c  ep 15"[email protected]#<
2f737479 6c652e63 73733e3b 2072656c  /style.css>; rel
3d707265 6c6f6164 3b206173 3d737479  =preload; as=sty
6c65046c 696e6b24 3c2f7363 72697074  le.link$</script
2e6a733e 3b207265 6c3d7072 656c6f61  .js>; rel=preloa
643b2061 733d7363 72697074 0040c804  d; as=script.@..
64617465 1d4d6f6e 2c203237 204a756c  date.Mon, 27 Jul
20323030 39203132 3a32383a 35332047   2009 12:28:53 G
4d540673 65727665 72064170 61636865  MT.server.Apache
0d6c6173 742d6d6f 64696669 65641d57  .last-modified.W
65642c20 3232204a 756c2032 30303920  ed, 22 Jul 2009
31393a31 353a3536 20474d54 04657461  19:15:56 GMT.eta
67142233 34616133 38372d64 2d313536  g."34aa387-d-156
38656230 30220d61 63636570 742d7261  8eb00".accept-ra
6e676573 05627974 65730e63 6f6e7465  nges.bytes.conte
6e742d6c 656e6774 68023531 04766172  nt-length.51.var
790f4163 63657074 2d456e63 6f64696e  y.Accept-Encodin
670c636f 6e74656e 742d7479 70650a74  g.content-type.t
6578742f 706c6169 6e003348 656c6c6f  ext/plain.3Hello
20576f72 6c642120 4d792063 6f6e7465   World! My conte
6e742069 6e636c75 64657320 61207472  nt includes a tr
61696c69 6e672043 524c462e 0d0a0000  ailing CRLF.....

A response that uses the chunked encoding (see Section 7.1 of [HTTP/1.1]) as shown in Figure 12 can be encoded using indeterminate-length encoding, which minimizes buffering needed to translate into the binary format. However, chunk boundaries do not need to be retained, and any chunk extensions cannot be conveyed using the binary format; see Section 6.¶

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
This
6
 conte
13;chunk-extension=foo
nt contains CRLF.

0
Trailer: text

Figure 13 shows this message using the known-length encoding. Note that the Transfer-Encoding header field is removed.¶

0140c800 1d546869 7320636f 6e74656e  [email protected] conten
7420636f 6e746169 6e732043 524c462e  t contains CRLF.
0d0a0d07 74726169 6c657204 74657874  ....trailer.text