3.1.Known-Length Messages

A request or response that has a known length at the time of construction usesthe format shown inFigure 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), requestcontrol data (Section 3.4), a header section with a length prefix,binary content with a length prefix, a trailer section with a length prefix, andpadding.¶

A known-length response contains the same fields, with the exception thatrequest 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 isa variable-length encoding of an integer. This integer is the number of bytesin the field section or content, not including the length field itself.¶

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

The format allows for the message to be truncated before any of the lengthprefixes that precede the field sections or content; seeSection 3.8.¶

The variable-length integer encoding means that there is a limit of 2⁶²-1bytes 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 foreach section uses the format shown inFigure 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 terminatedby a zero value, any number of non-zero-length chunks of binary content, a zerovalue, a trailer section that is terminated by a zero value, and padding.¶

An indeterminate-length response contains the same fields, with the exceptionthat 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 anon-zero Chunk Length integer describing the number of bytes in the block. TheChunk Length is encoded as a variable-length integer.¶

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

Indeterminate-length messages can be truncated in a way similar to that forknown-lengthmessages; seeSection 3.8.¶

Indeterminate-length messages use the same encoding for Field Line asknown-length messages; seeSection 3.6.¶

3.3.Framing Indicator

The start of each binary message is a framing indicator that is a single integer thatdescribes the structure of the subsequent sections. The framing indicator cantake 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; seeSection 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-headerfields, respectively. However, where the":authority" pseudo-header field mightbe omitted in HTTP/2, a zero-length value is encoded instead.¶

The format of request control data is shown inFigure 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 statuscode (Section 15 of [HTTP]) is encoded as a variable-length integer, not alength-prefixed decimal string.¶

The format of final response control data is shown inFigure 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; seeSection 5 of [HTTP]. The format of a field section depends on whether the message is ofknown length or indeterminate length.¶

Each Field Line encoding includes a name and a value. Both the name and value arelength-prefixed sequences of bytes. The Name field is a minimum of onebyte. The format of a Field Line is shown inFigure 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 causethe message to be invalid; seeSection 5.1 of [HTTP] for a definition of whatis valid andSection 4 regarding the handling of invalid messages. A recipientMUSTtreat a message that contains field values that would cause an HTTP/2 message tobe malformed according toSection 8.2.1 of [HTTP/2] as invalid; seeSection 4.¶

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

Messages are invalid (Section 4) if they contain fields named":method",":scheme",":authority",":path", or":status". Other pseudo-fields that aredefined by protocol extensionsMAY be included; pseudo-fields cannot be includedin trailers (seeSection 8.1 of [HTTP/2]). A Field Line containing pseudo-fieldsMUST precede other Field Line values. A message that contains a pseudo-field afterany other field is invalid; seeSection 4.¶

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

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

3.7.Content

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

3.8.Padding and Truncation

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

Truncation can be used to reduce the size of messages that have no data intrailing field sections or content. If the trailers of a message are empty, theyMAY be omitted by the encoder in place of adding a length field equal tozero. An encoderMAY omit empty content in the same way if the trailers are alsoempty. A message that is truncated at any other point is invalid; seeSection 4.¶

DecodersMUST treat missing truncated fields as equivalent to having been sentwith 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 semanticallyequivalent to the part being absent.¶

5.1.Request Example

The example HTTP/1.1 message inFigure 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 islimited to text, which also uses CRLF for line endings.¶

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

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

00034745 54056874 74707300 0a2f6865  ..GET.https../he6c6c6f2e 74787440 6c0a7573 65722d61  llo.txt@l.user-a67656e74 34637572 6c2f372e 31362e33  gent4curl/7.16.3206c6962 6375726c 2f372e31 362e3320   libcurl/7.16.34f70656e 53534c2f 302e392e 376c207a  OpenSSL/0.9.7l z6c69622f 312e322e 3304686f 73740f77  lib/1.2.3.host.w77772e65 78616d70 6c652e63 6f6d0f61  ww.example.com.a63636570 742d6c61 6e677561 67650665  ccept-language.e6e2c206d 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 reproducedaccurately; seeSection 8.3.1 of [HTTP/2].¶

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

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

02034745 54056874 74707300 0a2f6865  ..GET.https../he6c6c6f2e 7478740a 75736572 2d616765  llo.txt.user-age6e743463 75726c2f 372e3136 2e33206c  nt4curl/7.16.3 l69626375 726c2f37 2e31362e 33204f70  ibcurl/7.16.3 Op656e5353 4c2f302e 392e376c 207a6c69  enSSL/0.9.7l zli622f312e 322e3304 686f7374 0f777777  b/1.2.3.host.www2e657861 6d706c65 2e636f6d 0f616363  .example.com.acc6570742d 6c616e67 75616765 06656e2c  ept-language.en,206d6900 00000000 00000000 00000000   mi.............

This indeterminate-length encoding contains 10 bytes of padding. As two additionalbytes can be truncated in the same way as the known-length example, anything upto 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 inFigure 10 shows.Figure 10 includes examples of informationalstatus codes 102 and 103, as defined in[RFC2518] (now obsolete but defines status code 102) and[RFC8297], respectively.¶

HTTP/1.1 102 ProcessingRunning: "sleep 15"HTTP/1.1 103 Early HintsLink: </style.css>; rel=preload; as=styleLink: </script.js>; rel=preload; as=scriptHTTP/1.1 200 OKDate: Mon, 27 Jul 2009 12:28:53 GMTServer: ApacheLast-Modified: Wed, 22 Jul 2009 19:15:56 GMTETag: "34aa387-d-1568eb00"Accept-Ranges: bytesContent-Length: 51Vary: Accept-EncodingContent-Type: text/plainHello World! My content includes a trailing CRLF.

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

03406607 72756e6e 696e670a 22736c65  .@f.running."sle65702031 35220040 67046c69 6e6b233c  ep 15".@g.link#<2f737479 6c652e63 73733e3b 2072656c  /style.css>; rel3d707265 6c6f6164 3b206173 3d737479  =preload; as=sty6c65046c 696e6b24 3c2f7363 72697074  le.link$</script2e6a733e 3b207265 6c3d7072 656c6f61  .js>; rel=preloa643b2061 733d7363 72697074 0040c804  d; as=script.@..64617465 1d4d6f6e 2c203237 204a756c  date.Mon, 27 Jul20323030 39203132 3a32383a 35332047   2009 12:28:53 G4d540673 65727665 72064170 61636865  MT.server.Apache0d6c6173 742d6d6f 64696669 65641d57  .last-modified.W65642c20 3232204a 756c2032 30303920  ed, 22 Jul 200931393a31 353a3536 20474d54 04657461  19:15:56 GMT.eta67142233 34616133 38372d64 2d313536  g."34aa387-d-15638656230 30220d61 63636570 742d7261  8eb00".accept-ra6e676573 05627974 65730e63 6f6e7465  nges.bytes.conte6e742d6c 656e6774 68023531 04766172  nt-length.51.var790f4163 63657074 2d456e63 6f64696e  y.Accept-Encodin670c636f 6e74656e 742d7479 70650a74  g.content-type.t6578742f 706c6169 6e003348 656c6c6f  ext/plain.3Hello20576f72 6c642120 4d792063 6f6e7465   World! My conte6e742069 6e636c75 64657320 61207472  nt includes a tr61696c69 6e672043 524c462e 0d0a0000  ailing CRLF.....

A response that uses the chunked encoding (seeSection 7.1 of [HTTP/1.1]) asshown inFigure 12 can be encoded using indeterminate-length encoding, whichminimizes buffering needed to translate into the binary format. However, chunkboundaries do not need to be retained, and any chunk extensions cannot beconveyed using the binary format; seeSection 6.¶

HTTP/1.1 200 OKTransfer-Encoding: chunked4This6 conte13;chunk-extension=foont contains CRLF.0Trailer: text

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

0140c800 1d546869 7320636f 6e74656e  .@...This conten7420636f 6e746169 6e732043 524c462e  t contains CRLF.0d0a0d07 74726169 6c657204 74657874  ....trailer.text