<t>

HTTP uses "<x:dfn>fields</x:dfn>" to provide data in the form of extensible

key/value pairs with a registered key namespace. Fields are sent and

received within the header and trailer sections of messages

(<xref target="message.abstraction"/>).

</t>

A field name labels the corresponding field value as having the

semantics defined by that name. For example, the <x:ref>Date</x:ref>

header field is defined in <xref target="field.date"/> as containing the

origination timestamp for the message in which it appears.

Adhering to these requirements allows HTTP's functionality to be extended

without updating or removing deployed intermediaries.

Field sections are composed of any number of "<x:dfn>field lines</x:dfn>",

data for that instance of the field.

When a field name is only present once in a section, the combined

"<x:dfn>field value</x:dfn>" for that field consists of the corresponding

field line value.

When a field name is repeated within a section, its combined field value

consists of the list of corresponding field line values within that section,

concatenated in order, with each non-empty field line value separated by a

comma.

<section title="Field Order" anchor="field-order">

A recipient &MAY; combine multiple field lines within a field section that

have the same field name

The order in which field lines with differing field names are received in a

section is not significant. However, it is good practice to send header

fields that contain additional control data first, such as

<x:ref>Host</x:ref> on requests and <x:ref>Date</x:ref> on responses, so

that implementations can decide when not to handle a message as early as

possible.

request header section is received, since later header field lines might

include conditionals, authentication credentials, or deliberately misleading

Parameters are instances of name=value pairs; they are often used in field

<iref primary="true" item="message"/>

<iref primary="true" item="self-descriptive"/>

<t>

Each major version of HTTP defines its own syntax for communicating

messages. This section defines an abstract data type for HTTP messages

based on a generalization of those message characteristics, common structure,

and capacity for conveying semantics. This abstraction is used to define

requirements on senders and recipients that are independent of the HTTP

version, such that a message in one version can be relayed through other

versions without changing its meaning.

</t>

<t>

A <x:dfn>message</x:dfn> consists of control data to describe and route the

message, a headers lookup table of key/value pairs for extending that

control data and conveying additional information about the sender, message,

payload, or context, a potentially unbounded stream of payload data, and a

trailers lookup table of key/value pairs for communicating information

obtained while sending the payload.

</t>

Framing and control data is sent first, followed by a header section

containing fields for the headers table. When a message includes a payload,

the payload data is sent after the header section and potentially

interleaved with zero or more trailer sections containing fields for the

trailers table.

Messages are expected to be processed as a stream, wherein the purpose of

that stream and its continued processing is revealed while being read.

Hence, control data describes what the recipient needs to know immediately,

header fields describe what needs to be known before receiving a payload,

the payload (when present) presumably contains what the recipient wants or

needs to fulfill the message semantics, and trailer fields provide

additional metadata that can be dropped (safely ignored) when not desired.

Messages are intended to be <x:dfn>self-descriptive</x:dfn>:

everything a recipient needs to know about the message can be determined by

looking at the message itself, after decoding or reconstituting parts that

have been compressed or elided in transit, without requiring an

understanding of the sender's current application state (established via

prior messages).

</t>

<t>

Note that this message abstraction is a generalization across many versions

of HTTP, including features that might not be found in some versions. For

example, trailers were introduced within the HTTP/1.1 chunked transfer

coding as a single trailer section at the end of the payload data. An

equivalent feature is present in HTTP/2 and HTTP/3 within the header block

that terminates each stream. However, multiple trailer sections interleaved

with payload data have only been deployed as frame extensions.

connection to end a response. For backwards compatibility, this implicit

Messages start with control data that describe its primary purpose. Request

message control data includes a request method (<xref target="methods"/>),

request target (<xref target="request.target"/>), and protocol version

(<xref target="protocol.version"/>). Response message control data includes

a status code (<xref target="status.codes"/>), optional reason phrase, and

protocol version.

</t>

<t>

In HTTP/1.1 <xref target="Messaging"/> and earlier, control data is sent

as the first line of a message. In HTTP/2 (<xref target="RFC7540"/>) and

HTTP/3 (<xref target="HTTP3"/>), control data is sent as pseudo-header

fields with a reserved name prefix (e.g., ":authority").

</t>

<t>

Every HTTP message has a protocol version. Depending on the version in use,

it might be identified within the message explicitly or inferred by the

connection over which the message is received. Recipients use that version

information to determine limitations or potential for later communication

with that sender.

</t>

<t>

When a message is forwarded by an intermediary, the protocol version is

updated to reflect the version used by that intermediary.

The <x:ref>Via</x:ref> header field (<xref target="field.via"/>) is used to

communicate upstream protocol information within a forwarded message.

<iref primary="true" item="header section"/>

<t>

Fields (<xref target="fields"/>) that are sent/received before the payload

are referred to as "header fields" (or just "headers", colloquially).

The "<x:dfn>header section</x:dfn>" of a message consists of a sequence of

of header field lines. Each header field might modify or extend message

semantics, describe the sender, define the payload, or provide additional

context.

<aside>

<t>

&Note; We refer to named fields specifically as a "header field" when they

are only allowed to be sent in the header section.

</t>

</aside>

<iref primary="true" item="trailer section"/>

<iref primary="true" item="trailer fields"/>

<iref primary="true" item="trailers"/>

Fields (<xref target="fields"/>) that are sent/received after the header

section has ended (usually after the payload data begins to stream) are

Trailer fields can be useful for supplying message integrity checks, digital

signatures, delivery metrics, or post-processing status information.

<t>

An abstract data type for HTTP messages has been introduced to define the

components of a message and their semantics as an abstraction across

multiple HTTP versions, rather than in terms of the specific syntax form of

HTTP/1.1 in <xref target="Messaging"/>, and reflect the contents after the

message is parsed. This makes it easier to distinguish between requirements

on the payload data (what is conveyed) versus requirements on the messaging

syntax (how it is conveyed) and avoids baking limitations of early protocol

versions into the future of HTTP. (<xref target="message.abstraction"/>)

</t>

<li>In <xref target="message.abstraction"/>, add an abstract data type for message to help define semantics without being dependent on the specific structure of HTTP/1.1 (<eref target="https://github.com/httpwg/http-core/issues/557"/>)</li>