</section>

</section>

<section title="FieldNameExtensibility" anchor="field-extensibility">

<section title="Field Extensibility" anchor="field-extensibility">

<x:anchor-alias value="header.extensibility"/>

<t>

HTTP's most widely used extensibility point is the definition of new header and

trailer fields.

</t>

<t>

New fields can be defined such that, when they are understood by a

recipient, they override or enhance the interpretation of previously

defined fields, define preconditions on request evaluation, or

refine the meaning of responses.

</t>

<t>

However, defining a field doesn't guarantee its deployment or recognition

by recipients. Most fields are designed with the expectation that a recipient

can safely ignore (but forward downstream) any field not recognized.

In other cases, the sender's ability to understand a given field might be

indicated by its prior communication, perhaps in the protocol version

or fields that it sent in prior messages, or its use of a specific media type.

Likewise, direct inspection of support might be possible through an

OPTIONS request or by interacting with a defined well-known URI

<xref target="RFC8615"/> if such inspection is defined along with

the field being introduced.

</t>

<section title="Field Name Registry" anchor="field-name.registry">

<x:anchor-alias value="header.name.registry"/>

<t>

</section>

<section title="Considerations for New Field Names" anchor="considerations.for.new.field.names">

<t>

There is no limit on the introduction of new field names, each presumably

defining new semantics.

</t>

<t>

New fields can be defined such that, when they are understood by a

recipient, they might override or enhance the interpretation of previously

defined fields, define preconditions on request evaluation, or

refine the meaning of responses.

</t>

<t>

Authors of specifications defining new fields are advised to choose a short

but descriptive field name. Short names avoid needless data transmission;

<seriesInfo name="RFC" value="8336"/>

</reference>

<reference anchor="RFC8615">

<front>

<title>Well-Known Uniform Resource Identifiers (URIs)</title>

<author initials="M." surname="Nottingham" fullname="M. Nottingham"/>

<date year="2019" month="May"/>

</front>

<seriesInfo name="RFC" value="8615"/>

</reference>

<reference anchor="HTTP3">

<front>

<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>

<section title="Since draft-ietf-httpbis-semantics-12" anchor="changes.since.12">

<ul x:when-empty="None yet.">

<li>In <xref target="field-extensibility"/>, explain why new fields need to be backwards-compatible (<eref target="https://github.com/httpwg/http-core/issues/448"/>)</li>

<li>In <xref target="field-order"/>, constrain field combination to be within a section (<eref target="https://github.com/httpwg/http-core/issues/454"/>)</li>

<li>In <xref target="http.date"/>, mention that caching relaxes date sensitivity (<eref target="https://github.com/httpwg/http-core/issues/473"/>)</li>

<li>In <xref target="field.name.registration"/>, moved "*" field registration into main table (<eref target="https://github.com/httpwg/http-core/issues/476"/>)</li>