@neoncitylights/typed-http/src/httpHeaders.ts

Provides strongly typed HTTP header names. Supports the Fetch API, XmlHttpRequest, and the Node.js HTTP module with zero-runtime overhead.

/**
 * This file is generated by the `build/generateHttpTypes.ts` script.
 * To run it, run `npm run generateHttpTypes`.
 * Do NOT edit this file directly.
 */

/**
 * The A-IM request-header field is similar to Accept, but
 * restricts the instance-manipulations that are acceptable in
 * the response. A response may be the result of applying
 * multiple instance-manipulations. When an A-IM request-header
 * field includes one or more delta-coding values, the request
 * MUST contain an If-None-Match header field, listing one or
 * more entity tags from prior responses for the request-URI.
 *
 * @see [Documentation → IETF RFC 3229 §10.5.3](https://datatracker.ietf.org/doc/html/rfc3229#section-10.5.3)
 * @see [Specification → RFC 3229](http://webconcepts.info/specs/IETF/RFC/3229)
 */
export type HttpHeaderAIM = 'A-IM';

/**
 * Clients include the ALPN header field in an HTTP CONNECT
 * request to indicate the application-layer protocol that a
 * client intends to use within the tunnel, or a set of
 * protocols that might be used within the tunnel.
 *
 * @see [Documentation → IETF RFC 7639 §2](https://datatracker.ietf.org/doc/html/rfc7639#section-2)
 * @see [Specification → RFC 7639](http://webconcepts.info/specs/IETF/RFC/7639)
 */
export type HttpHeaderALPN = 'ALPN';

/**
 * The "Accept" header field can be used by user agents to
 * specify response media types that are acceptable. Accept
 * header fields can be used to indicate that the request is
 * specifically limited to a small set of desired types, as in
 * the case of a request for an in-line image.
 *
 * @see [Documentation → IETF RFC 7231 §5.3.2](https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.2)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpHeaderAccept = 'Accept';

/**
 * In HTTP, the "Accept" request-header field is used to
 * specify media types which are acceptable for the response.
 * However, in HTCPCP, the response may result in additional
 * actions on the part of the automated pot. For this reason,
 * HTCPCP adds a new header field, "Accept-Additions".
 *
 * @see [Documentation → IETF RFC 2324 §2.2.2.1](https://datatracker.ietf.org/doc/html/rfc2324#section-2.2.2.1)
 * @see [Documentation → IETF RFC 7168 §2.2.1](https://datatracker.ietf.org/doc/html/rfc7168#section-2.2.1)
 * @see [Specification → RFC 2324](http://webconcepts.info/specs/IETF/RFC/2324)
 * @see [Specification → RFC 7168](http://webconcepts.info/specs/IETF/RFC/7168)
 */
export type HttpHeaderAcceptAdditions = 'Accept-Additions';

/**
 * The Accept-CH response header field or the equivalent HTML
 * meta element with http-equiv attribute (HTML5) indicate
 * server support for particular hints indicated in its value.
 *
 * @see [Documentation → Internet Draft ietf-httpbis-client-hints §3.1](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints#section-3.1)
 * @see [Specification → Internet Draft ietf-httpbis-client-hints](http://webconcepts.info/specs/IETF/I-D/ietf-httpbis-client-hints)
 */
export type HttpHeaderAcceptCH = 'Accept-CH';

/**
 * The "Accept-Charset" header field can be sent by a user
 * agent to indicate what charsets are acceptable in textual
 * response content. This field allows user agents capable of
 * understanding more comprehensive or special-purpose charsets
 * to signal that capability to an origin server that is
 * capable of representing information in those charsets.
 *
 * @see [Documentation → IETF RFC 7231 §5.3.3](https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.3)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpHeaderAcceptCharset = 'Accept-Charset';

/**
 * The "Accept-Datetime" request header is transmitted by a
 * user agent to indicate it wants to access a past state of an
 * Original Resource. To that end, the "Accept-Datetime" header
 * is conveyed in an HTTP request issued against a TimeGate for
 * an Original Resource, and its value indicates the datetime
 * of the desired past state of the Original Resource.
 *
 * @see [Documentation → IETF RFC 7089 §2.1.1](https://datatracker.ietf.org/doc/html/rfc7089#section-2.1.1)
 * @see [Specification → RFC 7089](http://webconcepts.info/specs/IETF/RFC/7089)
 */
export type HttpHeaderAcceptDatetime = 'Accept-Datetime';

/**
 * Section 5.3.4 of RFC 7231 defines "Accept-Encoding" as a
 * request header field only. This specification expands that
 * definition to allow "Accept-Encoding" as a response header
 * field as well. When present in a response, it indicates what
 * content codings the resource was willing to accept in the
 * associated request. A field value that only contains
 * "identity" implies that no content codings were supported.
 *
 * @see [Documentation → IETF RFC 7694 §3](https://datatracker.ietf.org/doc/html/rfc7694#section-3)
 * @see [Documentation → IETF RFC 7231 §5.3.4](https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.4)
 * @see [Specification → RFC 7694](http://webconcepts.info/specs/IETF/RFC/7694)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpHeaderAcceptEncoding = 'Accept-Encoding';

/**
 * The Accept-Features request header can be used by a user
 * agent to give information about the presence or absence of
 * certain features in the feature set of the current request.
 * Servers can use this information when running a remote
 * variant selection algorithm.
 *
 * @see [Documentation → IETF RFC 2295 §8.2](https://datatracker.ietf.org/doc/html/rfc2295#section-8.2)
 * @see [Specification → RFC 2295](http://webconcepts.info/specs/IETF/RFC/2295)
 */
export type HttpHeaderAcceptFeatures = 'Accept-Features';

/**
 * The Accept-Indefinite-Ranges request-header field allows the
 * client to indicate its acceptance of indefinite-sized range
 * requests for a resource.
 *
 * @see [Documentation → Internet Draft combs-http-indeterminate-range §2.1](https://datatracker.ietf.org/doc/html/draft-combs-http-indeterminate-range#section-2.1)
 * @see [Specification → Internet Draft combs-http-indeterminate-range](http://webconcepts.info/specs/IETF/I-D/combs-http-indeterminate-range)
 */
export type HttpHeaderAcceptIndefiniteRanges = 'Accept-Indefinite-Ranges';

/**
 * The "Accept-Language" header field can be used by user
 * agents to indicate the set of natural languages that are
 * preferred in the response.
 *
 * @see [Documentation → IETF RFC 7231 §5.3.5](https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.5)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpHeaderAcceptLanguage = 'Accept-Language';

/**
 * This specification introduces a new response header
 * Accept-Patch used to specify the patch document formats
 * accepted by the server. Accept-Patch SHOULD appear in the
 * OPTIONS response for any resource that supports the use of
 * the PATCH method. The presence of the Accept-Patch header in
 * response to any method is an implicit indication that PATCH
 * is allowed on the resource identified by the Request-URI.
 *
 * @see [Documentation → IETF RFC 5789 §3.1](https://datatracker.ietf.org/doc/html/rfc5789#section-3.1)
 * @see [Specification → RFC 5789](http://webconcepts.info/specs/IETF/RFC/5789)
 */
export type HttpHeaderAcceptPatch = 'Accept-Patch';

/**
 * The Accept-Post HTTP header SHOULD appear in the OPTIONS
 * response for any resource that supports the use of the POST
 * method. The presence of the Accept-Post header in response
 * to any method is an implicit indication that POST is allowed
 * on the resource identified by the Request-URI. The presence
 * of a specific document format in this header indicates that
 * that specific format is allowed on POST requests to the
 * resource identified by the Request-URI.
 *
 * @see [Documentation](http://www.w3.org/TR/ldp/#header-accept-post)
 * @see [Specification → W3C TR http://www.w3.org/TR/ldp](http://webconcepts.info/specs/W3C/TR/ldp)
 */
export type HttpHeaderAcceptPost = 'Accept-Post';

/**
 * In order to allow a user agent to inform a server about its
 * preferences regarding profiles for resource representations,
 * the "Accept-Profile" HTTP header used. A user agent can
 * specify several profiles and use quality indicators
 * (q-values) to indicate preferences.
 *
 * @see [Documentation → Internet Draft svensson-profiled-representations §4](https://datatracker.ietf.org/doc/html/draft-svensson-profiled-representations#section-4)
 * @see [Specification → Internet Draft svensson-profiled-representations](http://webconcepts.info/specs/IETF/I-D/svensson-profiled-representations)
 */
export type HttpHeaderAcceptProfile = 'Accept-Profile';

/**
 * A client can express the desired push policy for a request
 * by sending an "Accept-Push-Policy" header field in the
 * request. The header field value contains the push policy
 * that the client expects the server to use when processing
 * the request.
 *
 * @see [Documentation → Internet Draft ruellan-http-accept-push-policy §3.1](https://datatracker.ietf.org/doc/html/draft-ruellan-http-accept-push-policy#section-3.1)
 * @see [Specification → Internet Draft ruellan-http-accept-push-policy](http://webconcepts.info/specs/IETF/I-D/ruellan-http-accept-push-policy)
 */
export type HttpHeaderAcceptPushPolicy = 'Accept-Push-Policy';

/**
 * The "Accept-Query" response header field MAY be used by a
 * server to directly signal support for the QUERY method while
 * identifying the specific query format media type(s) that may
 * be used.
 *
 * @see [Documentation → Internet Draft ietf-httpbis-safe-method-w-body §3](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-safe-method-w-body#section-3)
 * @see [Specification → Internet Draft ietf-httpbis-safe-method-w-body](http://webconcepts.info/specs/IETF/I-D/ietf-httpbis-safe-method-w-body)
 */
export type HttpHeaderAcceptQuery = 'Accept-Query';

/**
 * The "Accept-Ranges" header field allows a server to indicate
 * that it supports range requests for the target resource.
 *
 * @see [Documentation → IETF RFC 7233 §2.3](https://datatracker.ietf.org/doc/html/rfc7233#section-2.3)
 * @see [Specification → RFC 7233](http://webconcepts.info/specs/IETF/RFC/7233)
 */
export type HttpHeaderAcceptRanges = 'Accept-Ranges';

/**
 * The Access-Control-Allow-Credentials header indicates
 * whether the response to request can be exposed when the omit
 * credentials flag is unset. When part of the response to a
 * preflight request it indicates that the actual request can
 * include user credentials.
 *
 * @see [Documentation](https://fetch.spec.whatwg.org/#http-access-control-allow-credentials)
 * @see [Specification → WHATWG Fetch Standard](https://fetch.spec.whatwg.org/)
 */
export type HttpHeaderAccessControlAllowCredentials = 'Access-Control-Allow-Credentials';

/**
 * The Access-Control-Allow-Headers header indicates, as part
 * of the response to a preflight request, which header field
 * names can be used during the actual request.
 *
 * @see [Documentation](https://fetch.spec.whatwg.org/#http-access-control-allow-headers)
 * @see [Specification → WHATWG Fetch Standard](https://fetch.spec.whatwg.org/)
 */
export type HttpHeaderAccessControlAllowHeaders = 'Access-Control-Allow-Headers';

/**
 * The Access-Control-Allow-Methods header indicates, as part
 * of the response to a preflight request, which methods can be
 * used during the actual request.
 *
 * @see [Documentation](https://fetch.spec.whatwg.org/#http-access-control-allow-methods)
 * @see [Specification → WHATWG Fetch Standard](https://fetch.spec.whatwg.org/)
 */
export type HttpHeaderAccessControlAllowMethods = 'Access-Control-Allow-Methods';

/**
 * The Access-Control-Allow-Origin header indicates whether a
 * resource can be shared based by returning the value of the
 * Origin request header, "*", or "null" in the response.
 *
 * @see [Documentation](https://fetch.spec.whatwg.org/#http-access-control-allow-origin)
 * @see [Specification → WHATWG Fetch Standard](https://fetch.spec.whatwg.org/)
 */
export type HttpHeaderAccessControlAllowOrigin = 'Access-Control-Allow-Origin';

/**
 * The Access-Control-Expose-Headers header indicates which
 * headers are safe to expose to the API of a CORS API
 * specification.
 *
 * @see [Documentation](https://fetch.spec.whatwg.org/#http-access-control-expose-headers)
 * @see [Specification → WHATWG Fetch Standard](https://fetch.spec.whatwg.org/)
 */
export type HttpHeaderAccessControlExposeHeaders = 'Access-Control-Expose-Headers';

/**
 * The Access-Control-Max-Age header indicates how long the
 * results of a preflight request can be cached in a preflight
 * result cache.
 *
 * @see [Documentation](https://fetch.spec.whatwg.org/#http-access-control-max-age)
 * @see [Specification → WHATWG Fetch Standard](https://fetch.spec.whatwg.org/)
 */
export type HttpHeaderAccessControlMaxAge = 'Access-Control-Max-Age';

/**
 * The Access-Control-Request-Headers header indicates which
 * headers will be used in the actual request as part of the
 * preflight request.
 *
 * @see [Documentation](https://fetch.spec.whatwg.org/#http-access-control-request-headers)
 * @see [Specification → WHATWG Fetch Standard](https://fetch.spec.whatwg.org/)
 */
export type HttpHeaderAccessControlRequestHeaders = 'Access-Control-Request-Headers';

/**
 * The Access-Control-Request-Method header indicates which
 * method will be used in the actual request as part of the
 * preflight request.
 *
 * @see [Documentation](https://fetch.spec.whatwg.org/#http-access-control-request-method)
 * @see [Specification → WHATWG Fetch Standard](https://fetch.spec.whatwg.org/)
 */
export type HttpHeaderAccessControlRequestMethod = 'Access-Control-Request-Method';

/**
 * The "Age" header field conveys the sender's estimate of the
 * amount of time since the response was generated or
 * successfully validated at the origin server.
 *
 * @see [Documentation → IETF RFC 7234 §5.1](https://datatracker.ietf.org/doc/html/rfc7234#section-5.1)
 * @see [Specification → RFC 7234](http://webconcepts.info/specs/IETF/RFC/7234)
 */
export type HttpHeaderAge = 'Age';

/**
 * The "Allow" header field lists the set of methods advertised
 * as supported by the target resource. The purpose of this
 * field is strictly to inform the recipient of valid request
 * methods associated with the resource.
 *
 * @see [Documentation → IETF RFC 7231 §7.4.1](https://datatracker.ietf.org/doc/html/rfc7231#section-7.4.1)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpHeaderAllow = 'Allow';

/**
 * An HTTP(S) origin server can advertise the availability of
 * alternative services to clients by adding an Alt-Svc header
 * field to responses.
 *
 * @see [Documentation → IETF RFC 7838 §3](https://datatracker.ietf.org/doc/html/rfc7838#section-3)
 * @see [Specification → RFC 7838](http://webconcepts.info/specs/IETF/RFC/7838)
 */
export type HttpHeaderAltSvc = 'Alt-Svc';

/**
 * The Alt-Used header field is used in requests to indicate
 * the identity of the alternative service in use, just as the
 * Host header field identifies the host and port of the
 * origin. Alt-Used is intended to allow alternative services
 * to detect loops, differentiate traffic for purposes of load
 * balancing, and generally to ensure that it is possible to
 * identify the intended destination of traffic, since
 * introducing this information after a protocol is in use has
 * proven to be problematic.
 *
 * @see [Documentation → IETF RFC 7838 §5](https://datatracker.ietf.org/doc/html/rfc7838#section-5)
 * @see [Specification → RFC 7838](http://webconcepts.info/specs/IETF/RFC/7838)
 */
export type HttpHeaderAltUsed = 'Alt-Used';

/**
 * The Alternates response header is used to convey the list of
 * variants bound to a negotiable resource. This list can also
 * include directives for any content negotiation process. If a
 * response from a transparently negotiable resource includes
 * an Alternates header, this header MUST contain the complete
 * variant list bound to the negotiable resource. Responses
 * from resources which do not support transparent content
 * negotiation MAY also use Alternates headers.
 *
 * @see [Documentation → IETF RFC 2295 §8.3](https://datatracker.ietf.org/doc/html/rfc2295#section-8.3)
 * @see [Specification → RFC 2295](http://webconcepts.info/specs/IETF/RFC/2295)
 */
export type HttpHeaderAlternates = 'Alternates';

/**
 * The optional Apply-To-Redirect-Ref header can be used on any
 * request to a redirect reference resource. When it is present
 * and set to "T", the request MUST be applied to the reference
 * resource itself, and a 3xx response MUST NOT be returned.
 *
 * @see [Documentation → IETF RFC 4437 §12.2](https://datatracker.ietf.org/doc/html/rfc4437#section-12.2)
 * @see [Specification → RFC 4437](http://webconcepts.info/specs/IETF/RFC/4437)
 */
export type HttpHeaderApplyToRedirectRef = 'Apply-To-Redirect-Ref';

/**
 * The Authentication-Control header provides more precise
 * control of the client behavior for Web applications using an
 * HTTP authentication protocol.
 *
 * @see [Documentation → IETF RFC 8053 §4](https://datatracker.ietf.org/doc/html/rfc8053#section-4)
 * @see [Specification → RFC 8053](http://webconcepts.info/specs/IETF/RFC/8053)
 */
export type HttpHeaderAuthenticationControl = 'Authentication-Control';

/**
 * HTTP authentication schemes can use the Authentication-Info
 * response header field to communicate information after the
 * client's authentication credentials have been accepted. This
 * information can include a finalization message from the
 * server (e.g., it can contain the server authentication).
 *
 * @see [Documentation → IETF RFC 7615 §3](https://datatracker.ietf.org/doc/html/rfc7615#section-3)
 * @see [Specification → RFC 7615](http://webconcepts.info/specs/IETF/RFC/7615)
 */
export type HttpHeaderAuthenticationInfo = 'Authentication-Info';

/**
 * The client is expected to retry the request, passing an
 * Authorization header field line with Digest scheme, which is
 * defined according to the framework above. The values of the
 * opaque and algorithm fields must be those supplied in the
 * WWW-Authenticate response header field for the entity being
 * requested.
 *
 * @see [Documentation → IETF RFC 7616 §3.4](https://datatracker.ietf.org/doc/html/rfc7616#section-3.4)
 * @see [Documentation → IETF RFC 5849 §3.5.1](https://datatracker.ietf.org/doc/html/rfc5849#section-3.5.1)
 * @see [Documentation → IETF RFC 7235 §4.1](https://datatracker.ietf.org/doc/html/rfc7235#section-4.1)
 * @see [Specification → RFC 7616](http://webconcepts.info/specs/IETF/RFC/7616)
 * @see [Specification → RFC 5849](http://webconcepts.info/specs/IETF/RFC/5849)
 * @see [Specification → RFC 7235](http://webconcepts.info/specs/IETF/RFC/7235)
 */
export type HttpHeaderAuthorization = 'Authorization';

/**
 * The C-Ext response header field is used to indicate that all
 * hop-by-hop mandatory extension declarations in the request
 * were fulfilled.
 *
 * @see [Documentation → IETF RFC 2774 §4.3](https://datatracker.ietf.org/doc/html/rfc2774#section-4.3)
 * @see [Specification → RFC 2774](http://webconcepts.info/specs/IETF/RFC/2774)
 */
export type HttpHeaderCExt = 'C-Ext';

/**
 * A mandatory extension declaration indicates that the
 * ultimate recipient MUST consult and adhere to the rules
 * given by the extension when processing the message or
 * reporting an error. Hop-by-hop extension declarations are
 * meaningful only for a single HTTP connection. In HTTP/1.1,
 * C-Man, C-Opt, and all header fields with matching
 * header-prefix values defined by C-Man and C-Opt MUST be
 * protected by a Connection header field. That is, these
 * header fields are to be included as Connection header field
 * directives.
 *
 * @see [Documentation → IETF RFC 2774 §4.2](https://datatracker.ietf.org/doc/html/rfc2774#section-4.2)
 * @see [Specification → RFC 2774](http://webconcepts.info/specs/IETF/RFC/2774)
 */
export type HttpHeaderCMan = 'C-Man';

/**
 * An optional extension declaration indicates that the
 * ultimate recipient of the extension MAY consult and adhere
 * to the rules given by the extension when processing the
 * message, or ignore the extension declaration completely. An
 * agent may not be able to distinguish whether the ultimate
 * recipient does not understand an extension referred to by an
 * optional extension or simply ignores the extension
 * declaration. Hop-by-hop extension declarations are
 * meaningful only for a single HTTP connection. In HTTP/1.1,
 * C-Man, C-Opt, and all header fields with matching
 * header-prefix values defined by C-Man and C-Opt MUST be
 * protected by a Connection header field. That is, these
 * header fields are to be included as Connection header field
 * directives.
 *
 * @see [Documentation → IETF RFC 2774 §4.2](https://datatracker.ietf.org/doc/html/rfc2774#section-4.2)
 * @see [Specification → RFC 2774](http://webconcepts.info/specs/IETF/RFC/2774)
 */
export type HttpHeaderCOpt = 'C-Opt';

/**
 * PEP hop-by-hop extension declarations are meaningful only
 * for a single transport-level connection. The C-PEP header
 * field is a hop-by-hop header field and must not be
 * communicated by proxies over further connections.
 *
 * @see [Documentation](http://www.w3.org/TR/WD-http-pep-971121.html#_Toc404743948)
 * @see [Specification → W3C TR http://www.w3.org/TR/WD-http-pep](http://webconcepts.info/specs/W3C/TR/WD-http-pep)
 */
export type HttpHeaderCPEP = 'C-PEP';

/**
 * PEP hop-by-hop policies are meaningful only for a single
 * transport-level connection. The C-PEP-Info header field is a
 * hop-by-hop header field and MUST NOT be communicated by
 * proxies over further connections.
 *
 * @see [Documentation](http://www.w3.org/TR/WD-http-pep-971121.html#_Toc404743954)
 * @see [Specification → W3C TR http://www.w3.org/TR/WD-http-pep](http://webconcepts.info/specs/W3C/TR/WD-http-pep)
 */
export type HttpHeaderCPEPInfo = 'C-PEP-Info';

/**
 * The CDN-Cache-Control response header field is a targeted
 * field that allows origin servers to control the behavior of
 * CDN caches interposed between them and clients separately
 * from other caches that might handle the response. It applies
 * to caches that are part of a distributed network that
 * operate on behalf of an origin server (commonly called a
 * CDN).
 *
 * @see [Documentation → IETF RFC 9213 §3](https://datatracker.ietf.org/doc/html/rfc9213#section-3)
 * @see [Specification → RFC 9213](http://webconcepts.info/specs/IETF/RFC/9213)
 */
export type HttpHeaderCDNCacheControl = 'CDN-Cache-Control';

/**
 * The "Cache-Control" header field is used to specify
 * directives for caches along the request/response chain. Such
 * cache directives are unidirectional in that the presence of
 * a directive in a request does not imply that the same
 * directive is to be given in the response.
 *
 * @see [Documentation → IETF RFC 7234 §5.2](https://datatracker.ietf.org/doc/html/rfc7234#section-5.2)
 * @see [Specification → RFC 7234](http://webconcepts.info/specs/IETF/RFC/7234)
 */
export type HttpHeaderCacheControl = 'Cache-Control';

/**
 * For precisely identifying transferred content independent of
 * the used URL and independent of additional header fields in
 * the context of content negotiation, the Cache-NT header
 * field is used. The new header field carries an SHA-256
 * value.
 *
 * @see [Documentation → Internet Draft drechsler-httpbis-improved-caching §2.1](https://datatracker.ietf.org/doc/html/draft-drechsler-httpbis-improved-caching#section-2.1)
 * @see [Specification → Internet Draft drechsler-httpbis-improved-caching](http://webconcepts.info/specs/IETF/I-D/drechsler-httpbis-improved-caching)
 */
export type HttpHeaderCacheNT = 'Cache-NT';

/**
 * The Cache-Status HTTP response header field indicates how
 * caches have handled that response and its corresponding
 * request.
 *
 * @see [Documentation → Internet Draft ietf-httpbis-cache-header §2](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cache-header#section-2)
 * @see [Specification → Internet Draft ietf-httpbis-cache-header](http://webconcepts.info/specs/IETF/I-D/ietf-httpbis-cache-header)
 */
export type HttpHeaderCacheStatus = 'Cache-Status';

/**
 * The Cal-Managed-ID response header field provides the value
 * of the MANAGED-ID parameter corresponding to a newly added
 * ATTACH property. It MUST be sent only in response to a
 * successful POST request with an action set to attachment-add
 * or attachment-update.
 *
 * @see [Documentation → Internet Draft ietf-calext-caldav-attachments §5.1](https://datatracker.ietf.org/doc/html/draft-ietf-calext-caldav-attachments#section-5.1)
 * @see [Specification → Internet Draft ietf-calext-caldav-attachments](http://webconcepts.info/specs/IETF/I-D/ietf-calext-caldav-attachments)
 */
export type HttpHeaderCalManagedID = 'Cal-Managed-ID';

/**
 * The Clear-Site-Data HTTP response header field sends a
 * signal to the user agent that it ought to remove all data of
 * a certain set of types.
 *
 * @see [Documentation](http://www.w3.org/TR/clear-site-data/#header)
 * @see [Specification → W3C TR http://www.w3.org/TR/clear-site-data](http://webconcepts.info/specs/W3C/TR/clear-site-data)
 */
export type HttpHeaderClearSiteData = 'Clear-Site-Data';

/**
 * In the context of a TLS terminating reverse proxy
 * deployment, the proxy makes the TLS client certificate
 * available to the backend application with the Client-Cert
 * HTTP header field. This field contains the end-entity
 * certificate used by the client in the TLS handshake.
 *
 * @see [Documentation → Internet Draft ietf-httpbis-client-cert-field §2.2](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-cert-field#section-2.2)
 * @see [Specification → Internet Draft ietf-httpbis-client-cert-field](http://webconcepts.info/specs/IETF/I-D/ietf-httpbis-client-cert-field)
 */
export type HttpHeaderClientCert = 'Client-Cert';

/**
 * In the context of a TLS terminating reverse proxy
 * deployment, the proxy MAY make the certificate chain used
 * for validation of the end-entity certificate available to
 * the backend application with the Client-Cert-Chain HTTP
 * header field. This field contains certificates used by the
 * proxy to validate the certificate used by the client in the
 * TLS handshake. These certificates might or might not have
 * been provided by the client during the TLS handshake.
 *
 * @see [Documentation → Internet Draft ietf-httpbis-client-cert-field §2.3](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-cert-field#section-2.3)
 * @see [Specification → Internet Draft ietf-httpbis-client-cert-field](http://webconcepts.info/specs/IETF/I-D/ietf-httpbis-client-cert-field)
 */
export type HttpHeaderClientCertChain = 'Client-Cert-Chain';

/**
 * The header field-name "Close" has been registered as
 * "reserved", since using that name as an HTTP header field
 * might conflict with the "close" connection option of the
 * Connection header field.
 *
 * @see [Documentation → IETF RFC 7230 §8.1](https://datatracker.ietf.org/doc/html/rfc7230#section-8.1)
 * @see [Specification → RFC 7230](http://webconcepts.info/specs/IETF/RFC/7230)
 */
export type HttpHeaderClose = 'Close';

/**
 * The "Connection" header field allows the sender to indicate
 * desired control options for the current connection. In order
 * to avoid confusing downstream recipients, a proxy or gateway
 * MUST remove or replace any received connection options
 * before forwarding the message.
 *
 * @see [Documentation → IETF RFC 7230 §6.1](https://datatracker.ietf.org/doc/html/rfc7230#section-6.1)
 * @see [Specification → RFC 7230](http://webconcepts.info/specs/IETF/RFC/7230)
 */
export type HttpHeaderConnection = 'Connection';

/**
 * The Content-Base entity-header field may be used to specify
 * the base URI for resolving relative URLs within the entity.
 * This header field is described as Base in RFC 1808, which is
 * expected to be revised.
 *
 * @see [Documentation → IETF RFC 2068 §14.11](https://datatracker.ietf.org/doc/html/rfc2068#section-14.11)
 * @see [Specification → RFC 2068](http://webconcepts.info/specs/IETF/RFC/2068)
 */
export type HttpHeaderContentBase = 'Content-Base';

/**
 * The Content-Digest HTTP field can be used in requests and
 * responses to communicate digests that are calculated using a
 * hashing algorithm applied to the actual message content.
 *
 * @see [Documentation → Internet Draft ietf-httpbis-digest-headers §2](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-digest-headers#section-2)
 * @see [Specification → Internet Draft ietf-httpbis-digest-headers](http://webconcepts.info/specs/IETF/I-D/ietf-httpbis-digest-headers)
 */
export type HttpHeaderContentDigest = 'Content-Digest';

/**
 * The Content-Disposition response header field is used to
 * convey additional information about how to process the
 * response payload, and also can be used to attach additional
 * metadata, such as the filename to use when saving the
 * response payload locally.
 *
 * @see [Documentation → IETF RFC 6266 §4](https://datatracker.ietf.org/doc/html/rfc6266#section-4)
 * @see [Specification → RFC 6266](http://webconcepts.info/specs/IETF/RFC/6266)
 */
export type HttpHeaderContentDisposition = 'Content-Disposition';

/**
 * The "Content-Encoding" header field indicates what content
 * codings have been applied to the representation, beyond
 * those inherent in the media type, and thus what decoding
 * mechanisms have to be applied in order to obtain data in the
 * media type referenced by the Content-Type header field.
 * Content-Encoding is primarily used to allow a
 * representation's data to be compressed without losing the
 * identity of its underlying media type.
 *
 * @see [Documentation → IETF RFC 7231 §3.1.2.2](https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.2.2)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpHeaderContentEncoding = 'Content-Encoding';

/**
 * The "Content-Language" header field describes the natural
 * language(s) of the intended audience for the representation.
 * Note that this might not be equivalent to all the languages
 * used within the representation.
 *
 * @see [Documentation → IETF RFC 7231 §3.1.3.2](https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.3.2)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpHeaderContentLanguage = 'Content-Language';

/**
 * When a message does not have a Transfer-Encoding header
 * field, a Content-Length header field can provide the
 * anticipated size, as a decimal number of octets, for a
 * potential payload body. For messages that do include a
 * payload body, the Content-Length field-value provides the
 * framing information necessary for determining where the body
 * (and message) ends. For messages that do not include a
 * payload body, the Content-Length indicates the size of the
 * selected representation (Section 3 of [Part2]).
 *
 * @see [Documentation → IETF RFC 7230 §3.3.2](https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.2)
 * @see [Specification → RFC 7230](http://webconcepts.info/specs/IETF/RFC/7230)
 */
export type HttpHeaderContentLength = 'Content-Length';

/**
 * The "Content-Location" header field references a URI that
 * can be used as an identifier for a specific resource
 * corresponding to the representation in this message's
 * payload. In other words, if one were to perform a GET
 * request on this URI at the time of this message's
 * generation, then a 200 (OK) response would contain the same
 * representation that is enclosed as payload in this message.
 *
 * @see [Documentation → IETF RFC 7231 §3.1.4.2](https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.4.2)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpHeaderContentLocation = 'Content-Location';

/**
 * The Content-Range entity-header is sent with a partial
 * entity-body to specify where in the full entity-body the
 * partial body should be applied.
 *
 * @see [Documentation → Internet Draft combs-http-indeterminate-range §2.2](https://datatracker.ietf.org/doc/html/draft-combs-http-indeterminate-range#section-2.2)
 * @see [Documentation → IETF RFC 7233 §4.2](https://datatracker.ietf.org/doc/html/rfc7233#section-4.2)
 * @see [Specification → Internet Draft combs-http-indeterminate-range](http://webconcepts.info/specs/IETF/I-D/combs-http-indeterminate-range)
 * @see [Specification → RFC 7233](http://webconcepts.info/specs/IETF/RFC/7233)
 */
export type HttpHeaderContentRange = 'Content-Range';

/**
 * The Content-Security-Policy HTTP response header field is
 * the preferred mechanism for delivering a policy from a
 * server to a client.
 *
 * @see [Documentation](http://www.w3.org/TR/CSP3/#csp-header)
 * @see [Documentation](http://www.w3.org/TR/CSP2/#content-security-policy-header-field)
 * @see [Specification → W3C TR http://www.w3.org/TR/CSP3](http://webconcepts.info/specs/W3C/TR/CSP3)
 * @see [Specification → W3C TR http://www.w3.org/TR/CSP2](http://webconcepts.info/specs/W3C/TR/CSP2)
 */
export type HttpHeaderContentSecurityPolicy = 'Content-Security-Policy';

/**
 * The Content-Security-Policy-Pin header field is the
 * mechanism for delivering a pinned policy that the user agent
 * MUST enforce for any resource which is not delivered with a
 * Content-Security-Policy header (as described in the "Pin a
 * policy to response" algorithm).
 *
 * @see [Documentation](http://www.w3.org/TR/csp-pinning/#content-security-policy-pin-header-field)
 * @see [Specification → W3C TR http://www.w3.org/TR/csp-pinning](http://webconcepts.info/specs/W3C/TR/csp-pinning)
 */
export type HttpHeaderContentSecurityPolicyPin = 'Content-Security-Policy-Pin';

/**
 * The Content-Security-Policy-Report-Only HTTP response header
 * field allows web developers to experiment with policies by
 * monitoring (but not enforcing) their effects.
 *
 * @see [Documentation](http://www.w3.org/TR/CSP3/#cspro-header)
 * @see [Documentation](http://www.w3.org/TR/CSP2/#content-security-policy-report-only-header-field)
 * @see [Specification → W3C TR http://www.w3.org/TR/CSP3](http://webconcepts.info/specs/W3C/TR/CSP3)
 * @see [Specification → W3C TR http://www.w3.org/TR/CSP2](http://webconcepts.info/specs/W3C/TR/CSP2)
 */
export type HttpHeaderContentSecurityPolicyReportOnly = 'Content-Security-Policy-Report-Only';

/**
 * The Content-Security-Policy-Report-Only-Pin header field is
 * the mechanism for delivering a pinned policy that the user
 * agent MUST monitor for any resource which is not delivered
 * with a Content-Security-Policy-Report-Only header (as
 * described in the "Pin a policy to response" algorithm).
 *
 * @see [Documentation](http://www.w3.org/TR/csp-pinning/#content-security-policy-report-only-pin-header-field)
 * @see [Specification → W3C TR http://www.w3.org/TR/csp-pinning](http://webconcepts.info/specs/W3C/TR/csp-pinning)
 */
export type HttpHeaderContentSecurityPolicyReportOnlyPin = 'Content-Security-Policy-Report-Only-Pin';

/**
 * The Content-Signature header field carries a signature of
 * the payload body of an HTTP message. This allows for content
 * to be protected from modification.
 *
 * @see [Documentation → Internet Draft thomson-http-content-signature §2](https://datatracker.ietf.org/doc/html/draft-thomson-http-content-signature#section-2)
 * @see [Specification → Internet Draft thomson-http-content-signature](http://webconcepts.info/specs/IETF/I-D/thomson-http-content-signature)
 */
export type HttpHeaderContentSignature = 'Content-Signature';

/**
 * The Content-Translation-Type field can be used in the
 * individual language message parts to identify the type of
 * translation. Based on the value of this field and the user's
 * preferences, a conforming email client can determine which
 * message part to display.
 *
 * @see [Documentation → IETF RFC 8255 §6](https://datatracker.ietf.org/doc/html/rfc8255#section-6)
 * @see [Specification → RFC 8255](http://webconcepts.info/specs/IETF/RFC/8255)
 */
export type HttpHeaderContentTranslationType = 'Content-Translation-Type';

/**
 * The "Content-Type" header field indicates the media type of
 * the associated representation: either the representation
 * enclosed in the message payload or the selected
 * representation, as determined by the message semantics. The
 * indicated media type defines both the data format and how
 * that data is intended to be processed by a recipient, within
 * the scope of the received message semantics, after any
 * content codings indicated by Content-Encoding are decoded.
 *
 * @see [Documentation → IETF RFC 7231 §3.1.1.5](https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.1.5)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpHeaderContentType = 'Content-Type';

/**
 * The Content-Version entity-header field defines the version
 * tag associated with a rendition of an evolving entity.
 * Together with the Derived-From field, it allows a group of
 * people to work simultaneously on the creation of a work as
 * an iterative process. The field should be used to allow
 * evolution of a particular work along a single path rather
 * than derived works or renditions in different
 * representations.
 *
 * @see [Documentation → IETF RFC 2068 §19.6.2.2](https://datatracker.ietf.org/doc/html/rfc2068#section-19.6.2.2)
 * @see [Specification → RFC 2068](http://webconcepts.info/specs/IETF/RFC/2068)
 */
export type HttpHeaderContentVersion = 'Content-Version';

/**
 * The Content-Warning header allows to return different kinds
 * of warning information via HTTP.
 *
 * @see [Documentation → Internet Draft cedik-http-warning §8.1](https://datatracker.ietf.org/doc/html/draft-cedik-http-warning#section-8.1)
 * @see [Specification → Internet Draft cedik-http-warning](http://webconcepts.info/specs/IETF/I-D/cedik-http-warning)
 */
export type HttpHeaderContentWarning = 'Content-Warning';

/**
 * The user agent sends stored cookies to the origin server in
 * the Cookie header.
 *
 * @see [Documentation → Internet Draft ietf-httpbis-rfc6265bis §4.2](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis#section-4.2)
 * @see [Documentation → IETF RFC 6265 §4.2](https://datatracker.ietf.org/doc/html/rfc6265#section-4.2)
 * @see [Specification → Internet Draft ietf-httpbis-rfc6265bis](http://webconcepts.info/specs/IETF/I-D/ietf-httpbis-rfc6265bis)
 * @see [Specification → RFC 6265](http://webconcepts.info/specs/IETF/RFC/6265)
 */
export type HttpHeaderCookie = 'Cookie';

/**
 * The Cookie2 request header facilitates interoperation
 * between clients and servers that understand different
 * versions of the cookie specification.
 *
 * @see [Documentation → IETF RFC 2965 §3.3](https://datatracker.ietf.org/doc/html/rfc2965#section-3.3)
 * @see [Specification → RFC 2965](http://webconcepts.info/specs/IETF/RFC/2965)
 */
export type HttpHeaderCookie2 = 'Cookie2';

/**
 * The Cross-Origin-Embedder-Policy header allows controlling
 * how cross-origin resources should load, based on a specific
 * policy/set of permissions.
 *
 * @see [Documentation](https://html.spec.whatwg.org/#cross-origin-embedder-policy)
 * @see [Specification → WHATWG HTML Standard](https://html.spec.whatwg.org/)
 */
export type HttpHeaderCrossOriginEmbedderPolicy = 'Cross-Origin-Embedder-Policy';

/**
 * A cross-origin opener policy value allows a document which
 * is navigated to in a top-level browsing context to force the
 * creation of a new top-level browsing context, and a
 * corresponding group.
 *
 * @see [Documentation](https://html.spec.whatwg.org/#cross-origin-opener-policy)
 * @see [Specification → WHATWG HTML Standard](https://html.spec.whatwg.org/)
 */
export type HttpHeaderCrossOriginOpenerPolicy = 'Cross-Origin-Opener-Policy';

/**
 * The `Cross-Origin-Resource-Policy` response header can be
 * used to require checking a request’s current URL’s origin
 * against a request’s origin when request’s mode is "no-cors".
 *
 * @see [Documentation](https://fetch.spec.whatwg.org/#http-cross-origin-resource-policy)
 * @see [Specification → WHATWG Fetch Standard](https://fetch.spec.whatwg.org/)
 */
export type HttpHeaderCrossOriginResourcePolicy = 'Cross-Origin-Resource-Policy';

/**
 * The DASL response header indicates server support for query
 * grammars in the OPTIONS method. The value is a list of URIs
 * that indicate the types of supported grammars. Note that
 * although the URIs can be used to identify each supported
 * search grammar, there is not necessarily a direct
 * relationship between the URI and the XML element name that
 * can be used in XML based SEARCH requests (the element name
 * itself is identified by its namespace name (a URI reference)
 * and the element's local name).
 *
 * @see [Documentation → IETF RFC 5323 §9.1.1](https://datatracker.ietf.org/doc/html/rfc5323#section-9.1.1)
 * @see [Specification → RFC 5323](http://webconcepts.info/specs/IETF/RFC/5323)
 */
export type HttpHeaderDASL = 'DASL';

/**
 * This general-header appearing in the response indicates that
 * the resource supports the DAV schema and protocol as
 * specified. As a request header, this header allows the
 * client to advertise compliance with named features when the
 * server needs that information.
 *
 * @see [Documentation → IETF RFC 4918 §10.1](https://datatracker.ietf.org/doc/html/rfc4918#section-10.1)
 * @see [Specification → RFC 4918](http://webconcepts.info/specs/IETF/RFC/4918)
 */
export type HttpHeaderDAV = 'DAV';

/**
 * The DNT header field is defined as the means for expressing
 * a user's tracking preference via HTTP.
 *
 * @see [Documentation](http://www.w3.org/TR/tracking-dnt/#dnt-header-field)
 * @see [Specification → W3C TR http://www.w3.org/TR/tracking-dnt](http://webconcepts.info/specs/W3C/TR/tracking-dnt)
 */
export type HttpHeaderDNT = 'DNT';

/**
 * The "Date" header field represents the date and time at
 * which the message was originated, having the same semantics
 * as the Origination Date Field (orig-date) defined in Section
 * 3.6.1 of RFC 5322.
 *
 * @see [Documentation → IETF RFC 7231 §7.1.1.2](https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.1.2)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpHeaderDate = 'Date';

/**
 * The Delta-Base entity-header field is used in a
 * delta-encoded response to specify the entity tag of the base
 * instance. A Delta-Base header field MUST be included in a
 * response with an IM header that includes a delta-coding, if
 * the request included more than one entity tag in its
 * If-None-Match header field. Any response with an IM header
 * that includes a delta-coding MAY include a Delta-Base
 * header.
 *
 * @see [Documentation → IETF RFC 3229 §10.5.1](https://datatracker.ietf.org/doc/html/rfc3229#section-10.5.1)
 * @see [Specification → RFC 3229](http://webconcepts.info/specs/IETF/RFC/3229)
 */
export type HttpHeaderDeltaBase = 'Delta-Base';

/**
 * The "Deprecation" HTTP response header field allows a server
 * to communicate to a client that the URI-identified resource
 * in context of the message is deprecated. It can also provide
 * information that the resource is deprecated since which
 * version.
 *
 * @see [Documentation → Internet Draft ietf-httpapi-deprecation-header §2](https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-deprecation-header#section-2)
 * @see [Specification → Internet Draft ietf-httpapi-deprecation-header](http://webconcepts.info/specs/IETF/I-D/ietf-httpapi-deprecation-header)
 */
export type HttpHeaderDeprecation = 'Deprecation';

/**
 * The Depth request header is used with methods executed on
 * resources that could potentially have internal members to
 * indicate whether the method is to be applied only to the
 * resource ("Depth: 0"), to the resource and its internal
 * members only ("Depth: 1"), or the resource and all its
 * members ("Depth: infinity").
 *
 * @see [Documentation → IETF RFC 4918 §10.2](https://datatracker.ietf.org/doc/html/rfc4918#section-10.2)
 * @see [Specification → RFC 4918](http://webconcepts.info/specs/IETF/RFC/4918)
 */
export type HttpHeaderDepth = 'Depth';

/**
 * The Destination request header specifies the URI that
 * identifies a destination resource for methods such as COPY
 * and MOVE, which take two URIs as parameters.
 *
 * @see [Documentation → IETF RFC 4918 §10.3](https://datatracker.ietf.org/doc/html/rfc4918#section-10.3)
 * @see [Specification → RFC 4918](http://webconcepts.info/specs/IETF/RFC/4918)
 */
export type HttpHeaderDestination = 'Destination';

/**
 * The Device Memory header field is a number that indicates
 * the client's device memory i.e. approximate amount of ram in
 * GiB.
 *
 * @see [Documentation](http://www.w3.org/TR/device-memory-1/#sec-device-memory-client-hint-header)
 * @see [Specification → W3C TR http://www.w3.org/TR/device-memory-1](http://webconcepts.info/specs/W3C/TR/device-memory-1)
 */
export type HttpHeaderDeviceMemory = 'Device-Memory';

/**
 * The Digest message header field provides a message digest of
 * the instance described by the message.
 *
 * @see [Documentation → IETF RFC 3230 §4.3.2](https://datatracker.ietf.org/doc/html/rfc3230#section-4.3.2)
 * @see [Specification → RFC 3230](http://webconcepts.info/specs/IETF/RFC/3230)
 */
export type HttpHeaderDigest = 'Digest';

/**
 * The Downlink request header field is a number that indicates
 * the downlink value at the time when the request is made by
 * the user agent.
 *
 * @see [Documentation](https://wicg.github.io/netinfo/#downlink-request-header-field)
 * @see [Specification → WICG Network Information API](https://wicg.github.io/netinfo/)
 */
export type HttpHeaderDownlink = 'Downlink';

/**
 * The EDIINT-Features header field indicates the originating
 * user agent is capable of supporting the features listed.
 *
 * @see [Documentation → IETF RFC 6017 §3](https://datatracker.ietf.org/doc/html/rfc6017#section-3)
 * @see [Specification → RFC 6017](http://webconcepts.info/specs/IETF/RFC/6017)
 */
export type HttpHeaderEDIINTFeatures = 'EDIINT-Features';

/**
 * Servers may request the protections outlined by Entry Point
 * Regulation (EPR) by sending an EPR HTTP response header
 * field along with a response.
 *
 * @see [Documentation](http://www.w3.org/TR/epr/#epr-header)
 * @see [Specification → W3C TR http://www.w3.org/TR/epr](http://webconcepts.info/specs/W3C/TR/epr)
 */
export type HttpHeaderEPR = 'EPR';

/**
 * The "ETag" header field in a response provides the current
 * entity-tag for the selected representation, as determined at
 * the conclusion of handling the request. An entity-tag is an
 * opaque validator for differentiating between multiple
 * representations of the same resource, regardless of whether
 * those multiple representations are due to resource state
 * changes over time, content negotiation resulting in multiple
 * representations being valid at the same time, or both.
 *
 * @see [Documentation → IETF RFC 7232 §2.3](https://datatracker.ietf.org/doc/html/rfc7232#section-2.3)
 * @see [Specification → RFC 7232](http://webconcepts.info/specs/IETF/RFC/7232)
 */
export type HttpHeaderETag = 'ETag';

/**
 * The Early-Data request header field indicates that the
 * request has been conveyed in early data and that a client
 * understands the 425 (Too Early) status code.
 *
 * @see [Documentation → IETF RFC 8470 §5.1](https://datatracker.ietf.org/doc/html/rfc8470#section-5.1)
 * @see [Specification → RFC 8470](http://webconcepts.info/specs/IETF/RFC/8470)
 */
export type HttpHeaderEarlyData = 'Early-Data';

/**
 * The ECT request header field is a number that indicates the
 * effective connection type at the time when the request is
 * made by the user agent.
 *
 * @see [Documentation](https://wicg.github.io/netinfo/#ect-request-header-field)
 * @see [Specification → WICG Network Information API](https://wicg.github.io/netinfo/)
 */
export type HttpHeaderECT = 'ECT';

/**
 * The "Expect" header field in a request indicates a certain
 * set of behaviors (expectations) that need to be supported by
 * the server in order to properly handle this request.
 *
 * @see [Documentation → IETF RFC 7231 §5.1.1](https://datatracker.ietf.org/doc/html/rfc7231#section-5.1.1)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpHeaderExpect = 'Expect';

/**
 * The Expect-CT response header field is a new field defined
 * in this specification. It is used by a server to indicate
 * that UAs should evaluate connections to the host emitting
 * the header field for CT compliance.
 *
 * @see [Documentation → IETF RFC 9239 §2.1](https://datatracker.ietf.org/doc/html/rfc9239#section-2.1)
 * @see [Specification → RFC 9163](http://webconcepts.info/specs/IETF/RFC/9163)
 */
export type HttpHeaderExpectCT = 'Expect-CT';

/**
 * The "Expires" header field gives the date/time after which
 * the response is considered stale. The presence of an Expires
 * field does not imply that the original resource will change
 * or cease to exist at, before, or after that time.
 *
 * @see [Documentation → IETF RFC 7234 §5.3](https://datatracker.ietf.org/doc/html/rfc7234#section-5.3)
 * @see [Specification → RFC 7234](http://webconcepts.info/specs/IETF/RFC/7234)
 */
export type HttpHeaderExpires = 'Expires';

/**
 * The Ext header field is used to indicate that all end-to-end
 * mandatory extension declarations in the request were
 * fulfilled.
 *
 * @see [Documentation → IETF RFC 2774 §4.3](https://datatracker.ietf.org/doc/html/rfc2774#section-4.3)
 * @see [Specification → RFC 2774](http://webconcepts.info/specs/IETF/RFC/2774)
 */
export type Ht