@unshared/client 0.6.4 → 0.6.6

package/dist/HttpHeaders.js.map

@@ -1 +1 @@
-{"version":3,"file":"HttpHeaders.js","sources":["../HttpHeaders.ts"],"sourcesContent":["/* eslint-disable unicorn/prevent-abbreviations */\nexport enum HttpHeader {\n\n  /**\n   * The HTTP **`Accept-CH`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) may be set by a server to specify which [client hint](/en-US/docs/Web/HTTP/Client_hints) headers should be included by the client in subsequent requests.\n   * To ensure client hints are sent reliably, the `Accept-CH` header should be persisted for all secure requests.\n   */\n  'Accept-CH' = 'Accept-CH',\n\n  /**\n   * > [!WARNING]\n   * > Do not use this header. Browsers omit this header and servers should ignore it.\n   *\n   * The HTTP **`Accept-Charset`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) was a header that advertised a client's supported [character encodings](https://developer.mozilla.org/en-US/docs/glossary/character_encoding). It is no longer widely used.\n   *\n   * UTF-8 is well-supported and the overwhelmingly preferred choice for character encoding. To [guarantee better privacy through less configuration-based entropy](https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy), all browsers omit the `Accept-Charset` header.\n   *\n   * Today, `Accept-Charset` is most notable for being one of several [forbidden header names](/en-US/docs/Glossary/Forbidden_header_name).\n   */\n  'Accept-Charset' = 'Accept-Charset',\n\n  /**\n   * The HTTP **`Accept-Encoding`** [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) indicates the content encoding (usually a compression algorithm) that the recipient can understand.\n   * In requests, the server uses [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) to select one of the encoding proposals from the client and informs the client of that choice with the [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) response header.\n   * In responses, it provides information about which content encodings the server can understand in messages to the requested resource, so that the encoding can be used in subsequent requests to the resource. For example, this might be sent in the response to a `PUT` request to a resource that used an unsupported encoding.\n   *\n   * Even if both the client and the server support the same compression algorithms, the server may choose not to compress the body of a response if the `identity` value is also acceptable.\n   * This happens in two common cases:\n   *\n   * 1. The data is already compressed, meaning a second round of compression will not reduce the transmitted data size, and may actually increase the size of the content in some cases.\n   * This is true for pre-compressed image formats (JPEG, for instance).\n   * 2. The server is overloaded and cannot allocate computing resources to perform the compression. For example, Microsoft recommends not to compress if a server uses more than 80% of its computational power.\n   *\n   * As long as the `identity;q=0` or `*;q=0` directives do not explicitly forbid the `identity` value that means no encoding, the server must never return a [406 Not Acceptable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406) error.\n   *\n   * > [!NOTE]\n   * > IANA maintains [a list of official content encodings](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding).\n   * > The `bzip` and `bzip2` encodings are non-standard, but may be used in some cases, particularly for legacy support.\n   */\n  'Accept-Encoding' = 'Accept-Encoding',\n\n  /**\n   * The HTTP **`Accept-Language`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates the natural language and locale that the client prefers.\n   * The server uses [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) to select one of the proposals and informs the client of the choice with the [Content-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Language) response header.\n   * Browsers set required values for this header according to their active user interface language.\n   * Users can also configure additional preferred languages through browser settings.\n   *\n   * The `Accept-Language` header generally lists the same locales as the [navigator.languages](https://developer.mozilla.org/en-US/docs/domxref/navigator.languages) property, with decreasing `q` values ([quality values](/en-US/docs/Glossary/Quality_values)). Some browsers, like Chrome and Safari, add language-only fallback tags in `Accept-Language`. For example, `en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7` when `navigator.languages` is `[\"en-US\", \"zh-CN\"]`. For privacy purposes (reducing [fingerprinting](https://developer.mozilla.org/en-US/docs/Glossary/fingerprinting)), both `Accept-Language` and `navigator.languages` may not include the full list of user preferences. For example, in Safari (always) and Chrome's incognito mode, only one language is listed.\n   *\n   * This header serves as a hint when the server cannot determine the target content language otherwise (for example, use a specific URL that depends on an explicit user decision).\n   * The server should never override an explicit user language choice. The content of `Accept-Language` is often out of a user's control (when traveling, for instance).\n   * A user may also want to visit a page in a language different from the user interface language.\n   *\n   * The server may send back a [406 Not Acceptable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406) error code when unable to serve content in a matching language, but this is rarely implemented.\n   * Servers often ignore the `Accept-Language` header in such cases and send a successful response with the most appropriate resource instead for a better user experience.\n   *\n   *\n   *\n   * \\* Values can only be `0-9`, `A-Z`, `a-z`, space, or the characters `*,-.;=`.\n   */\n  'Accept-Language' = 'Accept-Language',\n\n  /**\n   * The HTTP **`Accept-Patch`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) advertises which [media types](/en-US/docs/Web/HTTP/MIME_types) the server is able to understand in a [PATCH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PATCH) request.\n   * For example, a server receiving a `PATCH` request with an unsupported media type could reply with [415 Unsupported Media Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415) and an `Accept-Patch` header referencing one or more supported media types.\n   *\n   * The header should appear in [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS) requests to a resource that supports the `PATCH` method.\n   * An `Accept-Patch` header in a response to any request method implicitly means that a `PATCH` is allowed on the target resource in the request.\n   *\n   * > [!NOTE]\n   * > IANA maintains [a list of official content encodings](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding).\n   * > The `bzip` and `bzip2` encodings are non-standard but may be used in some cases, particularly for legacy support.\n   */\n  'Accept-Patch' = 'Accept-Patch',\n\n  /**\n   * The HTTP **`Accept-Post`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) advertises which [media types](/en-US/docs/Web/HTTP/MIME_types) are accepted by the server in a [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) request.\n   * For example, a server receiving a `POST` request with an unsupported media type could reply with [415 Unsupported Media Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415) and an `Accept-Post` header referencing one or more supported media types.\n   *\n   * The header should appear in [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS) requests to a resource that supports the `POST` method.\n   * An `Accept-Post` header in a response to any request method implicitly means that a `POST` is allowed on the target resource in the request.\n   *\n   * > [!NOTE]\n   * > IANA maintains [a list of official content encodings](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding).\n   * > The `bzip` and `bzip2` encodings are non-standard but may be used in some cases, particularly for legacy support.\n   */\n  'Accept-Post' = 'Accept-Post',\n\n  /**\n   * The HTTP **`Accept-Ranges`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used by the server to advertise its support for [range requests](/en-US/docs/Web/HTTP/Range_requests), allowing clients to request part or several parts of a resource.\n   * The value of this header indicates the unit that can be used to define a range.\n   *\n   * For example, a response with an `Accept-Ranges` header indicates that the server is capable of _resuming_ an interrupted download instead of a client restarting the transfer in full.\n   */\n  'Accept-Ranges' = 'Accept-Ranges',\n\n  /**\n   * The HTTP **`Accept`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates which content types, expressed as [MIME types](/en-US/docs/Web/HTTP/MIME_types), the client is able to understand.\n   * The server uses [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) to select one of the proposals and informs the client of the choice with the [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) response header.\n   * Browsers set required values for this header based on the context of the request.\n   * For example, a browser uses different values in a request when fetching a CSS stylesheet, image, video, or a script.\n   *\n   *\n   *\n   * \\* Values can't contain [CORS-unsafe request header bytes](https://fetch.spec.whatwg.org/#cors-unsafe-request-header-byte), including `\"():<>?@[\\]{},`, Delete `0x7F`, and control characters `0x00` to `0x19`, except for Tab `0x09`.\n   */\n  'Accept' = 'Accept',\n\n  /**\n   * The HTTP **`Access-Control-Allow-Credentials`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) tells browsers whether the server allows credentials to be included in cross-origin HTTP requests.\n   *\n   * Credentials include cookies, [Transport Layer Security (TLS)](https://developer.mozilla.org/en-US/docs/glossary/TLS) client certificates, or authentication headers containing a username and password.\n   * By default, these credentials are not sent in cross-origin requests, and doing so can make a site vulnerable to [Cross-Site Request Forgery (CSRF)](https://developer.mozilla.org/en-US/docs/Glossary/CSRF) attacks.\n   *\n   * A client can ask for credentials to be included in cross-site requests in several ways:\n   *\n   * - Using [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch), by setting the [`credentials`](/en-US/docs/Web/API/RequestInit#credentials) option to `\"include\"`.\n   * - Using [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest), by setting the [XMLHttpRequest.withCredentials](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest.withCredentials) property to `true`.\n   * - Using [EventSource()](https://developer.mozilla.org/en-US/docs/domxref/EventSource()), by setting the [EventSource.withCredentials](https://developer.mozilla.org/en-US/docs/domxref/EventSource.withCredentials) property to `true`.\n   *\n   * When credentials are included:\n   *\n   * - For [preflighted](https://developer.mozilla.org/en-US/docs/glossary/Preflight_request) requests: The preflight request does not include credentials.\n   * If the server's response to the preflight request sets the `Access-Control-Allow-Credentials` header to `true`, then the real request will include credentials; otherwise, the browser reports a network error.\n   * - For non-preflighted requests: The request will include credentials, and if the server's response does not set the `Access-Control-Allow-Credentials` header to `true`, the browser reports a network error.\n   */\n  'Access-Control-Allow-Credentials' = 'Access-Control-Allow-Credentials',\n\n  /**\n   * The HTTP **`Access-Control-Allow-Headers`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used in response to a [preflight request](https://developer.mozilla.org/en-US/docs/Glossary/preflight_request) to indicate the HTTP headers that can be used during the actual request.\n   * This header is required if the preflight request contains [Access-Control-Request-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Headers).\n   *\n   * > [!NOTE]\n   * > The [CORS-safelisted request headers](https://developer.mozilla.org/en-US/docs/glossary/CORS-safelisted_request_header) are always allowed and usually aren't listed in `Access-Control-Allow-Headers` unless there is a need to circumvent the [additional safelist restrictions](/en-US/docs/Glossary/CORS-safelisted_request_header#additional_restrictions).\n   */\n  'Access-Control-Allow-Headers' = 'Access-Control-Allow-Headers',\n\n  /**\n   * The HTTP **`Access-Control-Allow-Methods`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) specifies one or more [HTTP request methods](/en-US/docs/Web/HTTP/Methods) allowed when accessing a resource in response to a [preflight request](https://developer.mozilla.org/en-US/docs/glossary/preflight_request).\n   */\n  'Access-Control-Allow-Methods' = 'Access-Control-Allow-Methods',\n\n  /**\n   * The HTTP **`Access-Control-Allow-Origin`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates whether the response can be shared with requesting code from the given [origin](https://developer.mozilla.org/en-US/docs/Glossary/origin).\n   */\n  'Access-Control-Allow-Origin' = 'Access-Control-Allow-Origin',\n\n  /**\n   * The HTTP **`Access-Control-Expose-Headers`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) allows a server to indicate which response headers should be made available to scripts running in the browser in response to a cross-origin request.\n   *\n   * Only the [CORS-safelisted response headers](https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_response_header) are exposed by default. For clients to be able to access other headers, the server must list them using the `Access-Control-Expose-Headers` header.\n   */\n  'Access-Control-Expose-Headers' = 'Access-Control-Expose-Headers',\n\n  /**\n   * The HTTP **`Access-Control-Max-Age`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates how long the results of a [preflight request](https://developer.mozilla.org/en-US/docs/glossary/preflight_request) (that is, the information contained in the [Access-Control-Allow-Methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods) and [Access-Control-Allow-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers) headers) can be cached.\n   */\n  'Access-Control-Max-Age' = 'Access-Control-Max-Age',\n\n  /**\n   * The HTTP **`Access-Control-Request-Headers`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is used by browsers when issuing a [preflight request](https://developer.mozilla.org/en-US/docs/glossary/preflight_request) to let the server know which [HTTP headers](/en-US/docs/Web/HTTP/Headers) the client might send when the actual request is made (such as with [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch) or [XMLHttpRequest.setRequestHeader()](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest.setRequestHeader())). The complementary server-side header of [Access-Control-Allow-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers) will answer this browser-side header.\n   */\n  'Access-Control-Request-Headers' = 'Access-Control-Request-Headers',\n\n  /**\n   * The HTTP **`Access-Control-Request-Method`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is used by browsers when issuing a [preflight request](https://developer.mozilla.org/en-US/docs/glossary/preflight_request) to let the server know which [HTTP method](/en-US/docs/Web/HTTP/Methods) will be used when the actual request is made.\n   * This header is necessary because the preflight request is always an [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS) and doesn't use the same method as the actual request.\n   */\n  'Access-Control-Request-Method' = 'Access-Control-Request-Method',\n\n  /**\n   * The HTTP **`Age`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates the time in seconds for which an object was in a proxy cache.\n   *\n   * The header value is usually close to zero.\n   * If the value is `0`, the object was probably fetched from the origin server; otherwise, the value is usually calculated as a difference between the proxy's current date and the [Date](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date) general header included in the HTTP response.\n   */\n  'Age' = 'Age',\n\n  /**\n   * The HTTP **`Allow`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) lists the set of [request methods](/en-US/docs/Web/HTTP/Methods) supported by a resource.\n   * This header must be sent if the server responds with a [405 Method Not Allowed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405) status code to indicate which request methods can be used instead.\n   * An empty `Allow` value indicates that the resource allows no request methods, which might occur temporarily for a given resource.\n   */\n  'Allow' = 'Allow',\n\n  /**\n   * The HTTP **`Alt-Svc`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) lets a server indicate that another network location (the \"alternative service\") can be treated as authoritative for that origin when making future requests.\n   *\n   * Doing so allows new protocol versions to be advertised without affecting in-flight requests and can also help servers manage traffic. Using an alternative service is not visible to the end user; it does not change the URL or the origin of the request and does not introduce additional round trips.\n   */\n  'Alt-Svc' = 'Alt-Svc',\n\n  /**\n   * The HTTP **`Alt-Used`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is used to identify the alternative service in use, just as the [Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host) HTTP header field identifies the host and port of the origin.\n   *\n   * The 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.\n   *\n   * When a client uses an alternative service for a request, it can indicate this to the server using the `Alt-Used` HTTP header.\n   */\n  'Alt-Used' = 'Alt-Used',\n\n  /**\n   * The HTTP **`Attribution-Reporting-Eligible`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates that the corresponding response is eligible to register an attribution source or trigger.\n   *\n   * This header is never set manually and is instead sent by the browser in response to various HTML element or JavaScript request settings. Depending on the allowed registrations specified in the `Attribution-Reporting-Eligible` value, the server is expected to respond with either an [Attribution-Reporting-Register-Source](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Source) or [Attribution-Reporting-Register-Trigger](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Trigger) header to complete the registration of an attribution source or trigger, respectively.\n   *\n   * See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details.\n   */\n  'Attribution-Reporting-Eligible' = 'Attribution-Reporting-Eligible',\n\n  /**\n   * The HTTP **`Attribution-Reporting-Register-Source`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) registers a page feature as an [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources). This header is included as part of a response to a request that contains the [Attribution-Reporting-Eligible](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Eligible) header. It provides the information that the browser should store when a user interacts with the attribution source. The information you include in this header also determines the types of reports the browser can generate.\n   *\n   * See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details.\n   *\n   * > [!NOTE]\n   * > If the calling site does not have the Attribution Reporting API included in a successful [privacy sandbox enrollment process](/en-US/docs/Web/Privacy/Privacy_sandbox/Enrollment), the `Attribution-Reporting-Register-Source` header is ignored and attribution sources are not registered.\n   */\n  'Attribution-Reporting-Register-Source' = 'Attribution-Reporting-Register-Source',\n\n  /**\n   * The HTTP **`Attribution-Reporting-Register-Trigger`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) registers a page feature as an [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers). This header is included as part of a response to a request that contains the [Attribution-Reporting-Eligible](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Eligible) header.\n   *\n   * See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details.\n   *\n   * > [!NOTE]\n   * > If the calling site does not have the Attribution Reporting API included in a successful [privacy sandbox enrollment process](/en-US/docs/Web/Privacy/Privacy_sandbox/Enrollment), the `Attribution-Reporting-Register-Trigger` header is ignored and attribution triggers are not registered.\n   */\n  'Attribution-Reporting-Register-Trigger' = 'Attribution-Reporting-Register-Trigger',\n\n  /**\n   * The HTTP **`Authorization`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) can be used to provide credentials that authenticate a user agent with a server, allowing access to protected resources.\n   *\n   * The `Authorization` header is usually, but not always, sent after the user agent first attempts to request a protected resource without credentials.\n   * The server responds with a [401 Unauthorized](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401) message that includes at least one [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate) header.\n   * This header indicates the authentication schemes that can be used to access the resource and any additional information needed by the client to use them.\n   * The user-agent should select the most secure authentication scheme that it supports from those offered, prompt the user for their credentials, and then re-request the resource with the encoded credentials in the `Authorization` header.\n   *\n   * This header is stripped from cross-origin redirects.\n   *\n   * > [!NOTE]\n   * > This header is part of the [General HTTP authentication framework](/en-US/docs/Web/HTTP/Authentication#the_general_http_authentication_framework).\n   * > It can be used with a number of [authentication schemes](/en-US/docs/Web/HTTP/Authentication#authentication_schemes).\n   */\n  'Authorization' = 'Authorization',\n\n  /**\n   * The HTTP **`Cache-Control`** header holds _directives_ (instructions) in both requests and responses that control [caching](/en-US/docs/Web/HTTP/Caching) in browsers and shared caches (e.g., Proxies, CDNs).\n   */\n  'Cache-Control' = 'Cache-Control',\n\n  /**\n   * The HTTP **`Clear-Site-Data`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) sends a signal to the client that it should remove all browsing data of certain types (cookies, storage, cache) associated with the requesting website.\n   * It allows web developers to have more control over the data stored by browsers for their origins.\n   */\n  'Clear-Site-Data' = 'Clear-Site-Data',\n\n  /**\n   * The HTTP **`Connection`** header controls whether the network connection stays open after the current transaction finishes.\n   * If the value sent is `keep-alive`, the connection is persistent and not closed, allowing subsequent requests to the same server on the same connection.\n   *\n   * > [!WARNING]\n   * > Connection-specific header fields such as\n   * > `Connection` and [Keep-Alive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive) are prohibited\n   * > in [HTTP/2](https://httpwg.org/specs/rfc9113.html#ConnectionSpecific) and\n   * > [HTTP/3](https://httpwg.org/specs/rfc9114.html#header-formatting). Chrome and\n   * > Firefox ignore them in HTTP/2 responses, but Safari conforms to the HTTP/2\n   * > spec requirements and does not load any response that contains them.\n   *\n   * All [hop-by-hop headers](/en-US/docs/Web/HTTP/Compression#hop-by-hop_compression), including the standard hop-by-hop headers ([Keep-Alive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive),\n   * [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding), [TE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/TE), `Connection`,\n   * [Trailer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer), [Upgrade](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade),\n   * [Proxy-Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authorization), and [Proxy-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authenticate)) must be listed in the `Connection`\n   * header, so that the first proxy knows it has to consume them and not forward them\n   * further.\n   *\n   * The default value of `Connection` changed between HTTP/1.0 and HTTP/1.1.\n   * Therefore, to ensure backwards compatibility, browsers often send `Connection: keep-alive` explicitly, even though it's the default in HTTP/1.1.\n   */\n  'Connection' = 'Connection',\n\n  /**\n   * The HTTP **`Content-Digest`** header provides a [digest](https://developer.mozilla.org/en-US/docs/Glossary/digest) of the message content in an HTTP message.\n   * As such, `Content-Digest` is dependent on among other things [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) and [Content-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range), but not dependent on, for example, HTTP/1.1's [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding).\n   * `Content-Digest` may coincide with [Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Repr-Digest) if a representation was sent in a single message.\n   *\n   * In this setting, _content_ refers to a particular octet representation of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource.\n   *\n   * A client can request that a server emit a `Content-Digest` by issuing [Want-Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Content-Digest).\n   */\n  'Content-Digest' = 'Content-Digest',\n\n  /**\n   * The HTTP **`Content-Disposition`** header indicates whether content should be displayed _inline_ in the browser as a web page or part of a web page or downloaded as an _attachment_ locally.\n   *\n   * In a multipart body, the header must be used on each subpart to provide information about its corresponding field. The subpart is delimited by the _boundary_ defined in the [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) header. When used on the body itself, `Content-Disposition` has no effect.\n   *\n   * The `Content-Disposition` header is defined in the larger context of MIME messages for email, but only a subset of the possible parameters apply to HTTP forms and [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) requests. Only the value `form-data`, as well as the optional directive `name` and `filename`, can be used in the HTTP context.\n   */\n  'Content-Disposition' = 'Content-Disposition',\n\n  /**\n   * The HTTP **`Content-DPR`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used to confirm the _image_ device to pixel ratio (DPR) in requests where the screen [DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DPR) client hint was used to select an image resource.\n   *\n   * > [!NOTE]\n   * > The `Content-DPR` header was removed from the client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07).\n   * > The [Responsive Image Client Hints](https://wicg.github.io/responsive-image-client-hints/) specification proposes to replace this header by specifying intrinsic resolution/dimensions in EXIF metadata.\n   *\n   * If the `DPR` client hint is used to select an image, the server must specify `Content-DPR` in the response.\n   * If the value in `Content-DPR` is different from the [DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DPR) value in the request (i.e., image DPR is not the same as screen DPR), the client must use the `Content-DPR` for determining intrinsic image size and scaling the image.\n   *\n   * If the `Content-DPR` header appears more than once in a message, the last occurrence is used.\n   */\n  'Content-DPR' = 'Content-DPR',\n\n  /**\n   * The HTTP **`Content-Encoding`** [representation header](https://developer.mozilla.org/en-US/docs/Glossary/representation_header) lists the encodings and the order in which they have been applied to a resource.\n   * This lets the recipient know how to decode the data in order to obtain the original content format described in the [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) header.\n   * Content encoding is mainly used to compress content without losing information about the original media type.\n   *\n   * Servers should compress data as much as possible, and should use content encoding where appropriate.\n   * Compressing already compressed media types, such as .zip or .jpeg, is usually not appropriate because it can increase the file size.\n   * If the original media is already encoded (e.g., as a .zip file), this information is not included in the `Content-Encoding` header.\n   *\n   * When the `Content-Encoding` header is present, other metadata (e.g., [Content-Length](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length)) refer to the encoded form of the data, not the original resource, unless explicitly stated.\n   * Content encoding differs to [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding) in that `Transfer-Encoding` handles how HTTP messages themselves are delivered across the network on a [hop-by-hop basis](/en-US/docs/Web/HTTP/Headers#hop-by-hop_headers).\n   */\n  'Content-Encoding' = 'Content-Encoding',\n\n  /**\n   * The HTTP **`Content-Language`** [representation header](https://developer.mozilla.org/en-US/docs/Glossary/representation_header) is used to describe the language(s) intended for the audience, so users can differentiate it according to their own preferred language.\n   *\n   * For example, `Content-Language: de-DE` indicates that the document is intended for German language speakers. The document may be written in English, not German, as part of a language course for German speakers. To indicate the language the document is **written in**, use the [`lang`](/en-US/docs/Web/HTML/Global_attributes/lang) attribute instead.\n   *\n   * If no `Content-Language` is specified, the default is that the content is intended for all language audiences. Multiple language tags are also possible, as well as applying the `Content-Language` header to various media types and not only to textual documents.\n   *\n   *\n   *\n   * \\* Values can only be `0-9`, `A-Z`, `a-z`, a space, or the characters `*,-.;=`.\n   */\n  'Content-Language' = 'Content-Language',\n\n  /**\n   * The HTTP **`Content-Length`** header indicates the size, in bytes, of the message body sent to the recipient.\n   */\n  'Content-Length' = 'Content-Length',\n\n  /**\n   * The HTTP **`Content-Location`** [representation header](https://developer.mozilla.org/en-US/docs/Glossary/representation_header) indicates an alternate location for the returned data.\n   * It's main use is to indicate the URL of a resource transmitted as the result of [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation).\n   *\n   * The `Content-Location` header is different from the [Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location) header.\n   * `Content-Location` indicates the direct URL to access the resource when [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) has happened, allowing the client to bypass future content negotiation for this resource.\n   * `Location`, on the other hand, indicates either the target of a `3XX` redirection or the URL of a newly created resource in a [201 Created](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201) response.\n   */\n  'Content-Location' = 'Content-Location',\n\n  /**\n   * The HTTP **`Content-Range`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used in [range requests](/en-US/docs/Web/HTTP/Range_requests) to indicate where the content of a response body belongs in relation to a complete resource.\n   */\n  'Content-Range' = 'Content-Range',\n\n  /**\n   * The HTTP **`Content-Security-Policy-Report-Only`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) helps to monitor Content Security Policy (CSP) violations and their effects without enforcing the security policies.\n   * This header allows you to test or repair violations before a specific [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) is applied and enforced.\n   *\n   * The CSP [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive must be specified for reports to be sent: if not, the operation won't have any effect.\n   *\n   * Violation reports are sent using the [Reporting API](/en-US/docs/Web/API/Reporting_API) to endpoints defined in a [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Reporting-Endpoints) HTTP response header and selected using the CSP [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive.\n   *\n   * For more information, see our [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/CSP) guide.\n   *\n   * > [!NOTE]\n   * > The header can also be used with the deprecated [report-uri](https://developer.mozilla.org/en-US/docs/CSP/report-uri) directive (this is being replaced by [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to)).\n   * > The usage and resulting report syntax is slightly different; see the [report-uri](https://developer.mozilla.org/en-US/docs/CSP/report-uri) topic for more details.\n   */\n  'Content-Security-Policy-Report-Only' = 'Content-Security-Policy-Report-Only',\n\n  /**\n   * The HTTP **`Content-Security-Policy`** response header allows\n   * website administrators to control resources the user agent is allowed to load for a\n   * given page. With a few exceptions, policies mostly involve specifying server origins and\n   * script endpoints. This helps guard against cross-site scripting attacks\n   * ([Cross-site_scripting](https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting)).\n   *\n   * For more information, see the introductory article on [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/CSP).\n   */\n  'Content-Security-Policy' = 'Content-Security-Policy',\n\n  /**\n   * The HTTP **`Content-Type`** [representation header](https://developer.mozilla.org/en-US/docs/Glossary/representation_header) is used to indicate the original [media type](https://developer.mozilla.org/en-US/docs/Glossary/MIME_type) of a resource before any content encoding is applied.\n   *\n   * In responses, the `Content-Type` header informs the client about the media type of the returned data.\n   * In requests such as [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) or [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT), the client uses the `Content-Type` header to specify the type of content being sent to the server.\n   * If a server implementation or configuration is strict about content type handling, a [415](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415) client error response may be returned.\n   *\n   * The `Content-Type` header differs from [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) in that `Content-Encoding` helps the recipient understand how to decode data to its original form.\n   *\n   * > [!NOTE]\n   * > This value may be ignored if browsers perform [MIME sniffing](/en-US/docs/Web/HTTP/MIME_types#mime_sniffing) (or content sniffing) on responses.\n   * > To prevent browsers from using MIME sniffing, set the [X-Content-Type-Options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options) header value to `nosniff`.\n   * > See [MIME type verification](/en-US/docs/Web/Security/Practical_implementation_guides/MIME_types) for more details.\n   *\n   *\n   *\n   * \\* Values can't contain a [CORS-unsafe request header byte](https://fetch.spec.whatwg.org/#cors-unsafe-request-header-byte): `\"():<>?@[\\]{},`, Delete `0x7F`, and control characters `0x00` to `0x19` except for Tab `0x09`.\n   * It also needs to have a media type of its parsed value (ignoring parameters) of either `application/x-www-form-urlencoded`, `multipart/form-data`, or `text/plain`.\n   */\n  'Content-Type' = 'Content-Type',\n\n  /**\n   * The HTTP **`Cookie`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) contains stored [HTTP cookies](/en-US/docs/Web/HTTP/Cookies) associated with the server (i.e., previously sent by the server with the [Set-Cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie) header or set in JavaScript using [Document.cookie](https://developer.mozilla.org/en-US/docs/domxref/Document.cookie)).\n   *\n   * The `Cookie` header is optional and may be omitted if, for example, the browser's privacy settings block cookies.\n   */\n  'Cookie' = 'Cookie',\n\n  /**\n   * The HTTP **`Critical-CH`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used along with [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) to identify the accepted [client hints](/en-US/docs/Web/HTTP/Client_hints) that are [critical](/en-US/docs/Web/HTTP/Client_hints#critical_client_hints).\n   *\n   * User agents receiving a response with `Critical-CH` must check if the indicated critical headers were sent in the original request. If not, the user agent will retry the request along with the critical headers rather than render the page. This approach ensures that client preferences set using critical client hints are always used, even if not included in the first request, or following server configuration changes.\n   *\n   * Each header listed in the `Critical-CH` header should also be present in the `Accept-CH` and `Vary` headers.\n   */\n  'Critical-CH' = 'Critical-CH',\n\n  /**\n   * The HTTP **`Cross-Origin-Embedder-Policy`** (COEP) [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) configures embedding cross-origin resources into the document.\n   */\n  'Cross-Origin-Embedder-Policy' = 'Cross-Origin-Embedder-Policy',\n\n  /**\n   * The HTTP **`Cross-Origin-Opener-Policy`** (COOP) [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) allows a website to control whether a new top-level document, opened using [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()) or by navigating to a new page, is opened in the same [browsing context group](https://developer.mozilla.org/en-US/docs/glossary/Browsing_context) (BCG) or in a new browsing context group.\n   *\n   * When opened in a new BCG, any references between the new document and its opener are severed, and the new document may be process-isolated from its opener.\n   * This ensures that potential attackers can't open your documents with [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()) and then use the returned value to access its global object, and thereby prevents a set of cross-origin attacks referred to as [XS-Leaks](https://xsleaks.dev/).\n   *\n   * It also means that any object opened by your document in a new BCG can't access it using [`window.opener`](/en-US/docs/Web/API/Window/opener).\n   * This allows you to have more control over references to a window than [`rel=noopener`](/en-US/docs/Web/HTML/Attributes/rel/noopener), which affects outgoing navigations but not documents opened with [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()).\n   *\n   * The behaviour depends on the policies of both the new document and its opener, and whether the new document is opened following a navigation or using [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()).\n   */\n  'Cross-Origin-Opener-Policy' = 'Cross-Origin-Opener-Policy',\n\n  /**\n   * The HTTP **`Cross-Origin-Resource-Policy`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates that the browser should block no-cors cross-origin or cross-site requests to the given resource.\n   */\n  'Cross-Origin-Resource-Policy' = 'Cross-Origin-Resource-Policy',\n\n  /**\n   * The **`Date`** general HTTP header contains the date and time\n   * at which the message originated.\n   *\n   * > **Warning:** `Date` is listed\n   * > in the [forbidden header names](https://fetch.spec.whatwg.org/#forbidden-header-name)\n   * > in the fetch spec, so this code will not send the `Date` header:\n   * >\n   * > ```js\n   * > fetch(\"https://httpbin.org/get\", {\n   * >   headers: {\n   * >     Date: new Date().toUTCString(),\n   * >   },\n   * > });\n   * > ```\n   */\n  'Date' = 'Date',\n\n  /**\n   * The **`Device-Memory`** [device client hint](/en-US/docs/Web/HTTP/Client_hints#device_client_hints) request header field indicates the approximate amount of available RAM on the client device. The header is part of the [Device Memory API\", \"\", \"nocode](https://developer.mozilla.org/en-US/docs/DOMxRef/Device_Memory_API).\n   *\n   *\n   *\n   * > [!NOTE]\n   * >\n   * > - Client Hints are accessible only on secure origins (via TLS).\n   * > - A server has to opt in to receive the `Device-Memory` header from the client, by sending the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header.\n   * > - Servers that opt in to the `Device-Memory` client hint will typically also specify it in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header. This informs caches that the server may send different responses based on the header value in a request.\n   */\n  'Device-Memory' = 'Device-Memory',\n\n  /**\n   * > [!NOTE]\n   * > This header was removed from the specification in [draft 8](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-digest-headers-08).\n   * > Use [Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Digest) instead.\n   * > For `id-*` digest algorithms, use [Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Repr-Digest).\n   *\n   * The **`Digest`** response or request HTTP header provides the other side with a [digest](https://developer.mozilla.org/en-US/docs/Glossary/digest) of the [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding)-encoded _selected representation_. It can be requested by using the [Want-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Digest) header.\n   *\n   * Representations are different forms of a particular resource that might be returned from a request: for example, the same resource might be formatted in a particular media type such as XML or JSON, localized to a particular written language or geographical region, and/or compressed or otherwise encoded for transmission.\n   * The _selected representation_ is the actual format of a resource that is returned following [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation), and can be determined from the response's [Representation headers](https://developer.mozilla.org/en-US/docs/Glossary/Representation_header).\n   *\n   * The digest applies to the whole representation of a resource, not to a particular message.\n   * It can be used to verify that the representation data has not been modified during transmission.\n   *\n   * > [!NOTE]\n   * > While a representation may be fully contained in the message body of a single response, it can also be sent using multiple messages in response to a [range request](/en-US/docs/Web/HTTP/Range_requests), or omitted altogether in response to a [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) request.\n   */\n  'Digest' = 'Digest',\n\n  /**\n   * > [!NOTE]\n   * > The DNT (Do Not Track) specification has been discontinued. See [Navigator.doNotTrack](https://developer.mozilla.org/en-US/docs/domxref/Navigator.doNotTrack) for more information.\n   *\n   * The **`DNT`** (**D**o **N**ot\n   * **T**rack) request header indicates the user's tracking preference. It lets\n   * users indicate whether they would prefer privacy rather than personalized content.\n   *\n   * DNT is deprecated in favor of [Global Privacy Control](https://globalprivacycontrol.org/), which is communicated to servers using the [Sec-GPC](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-GPC) header, and accessible to clients from [navigator.globalPrivacyControl](https://developer.mozilla.org/en-US/docs/domxref/navigator.globalPrivacyControl).\n   */\n  'DNT' = 'DNT',\n\n  /**\n   * The **`Downlink`** [Client hint](/en-US/docs/Web/HTTP/Client_hints) request header field provides the approximate bandwidth of the client's connection to the server, in Mbps.\n   *\n   *\n   *\n   * The `Downlink` value is given in Mbps and rounded to the nearest 25 kilobits per second to prevent [fingerprinting](/en-US/docs/Glossary/Fingerprinting). There are many other mechanisms an attacker might use to obtain similar information.\n   *\n   * The hint allows a server to choose what information is sent based on the network bandwidth. For example, a server might choose to send smaller versions of images and other resources on low bandwidth networks.\n   *\n   * > [!NOTE]\n   * > The [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header is used in responses to indicate that a different resource is sent for every different value of the header (see [HTTP Caching Vary](/en-US/docs/Web/HTTP/Caching#vary)). Even if `Downlink` is used to configure what resources are sent, consider omitting it in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header — it is likely to change often, which effectively makes the resource uncacheable.\n   */\n  'Downlink' = 'Downlink',\n\n  /**\n   * The **`DPR`** [device client hint](/en-US/docs/Web/HTTP/Client_hints) request header provides the client device pixel ratio. This ratio is the number of physical device pixels corresponding to every [CSS pixel](https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel).\n   *\n   *\n   *\n   * The hint is useful when selecting image sources that best correspond to a screen's pixel density. This is similar to the role played by `x` descriptors in the `<img>` [`srcset`](/en-US/docs/Web/HTML/Element/img#srcset) attribute to allow user agents to select a preferred image.\n   *\n   * If a server uses the `DPR` hint to choose which resource is sent in a response, the response must include the [Content-DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-DPR) header. The client must use the value in `Content-DPR` for layout if it differs from the value in the request's `DPR` header.\n   *\n   * If the `DPR` header appears more than once in a message the last occurrence is used.\n   *\n   * > [!NOTE]\n   * >\n   * > - Client Hints are accessible only on secure origins (via TLS).\n   * > - A server has to opt in to receive the `DPR` header from the client, by sending the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header.\n   * > - Servers that opt in to the `DPR` client hint will typically also specify it in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header. This informs caches that the server may send different responses based on the header value in a request.\n   * > - `DPR` was removed from the client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07). The proposed replacement is [`Sec-CH-DPR`](https://wicg.github.io/responsive-image-client-hints/#sec-ch-dpr) (Responsive Image Client Hints).\n   */\n  'DPR' = 'DPR',\n\n  /**\n   * The **`Early-Data`** header is set by\n   * an intermediary to indicate that the request has been conveyed in [TLS early data](/en-US/docs/Web/Security/Transport_Layer_Security#tls_1.3),\n   * and also indicates that the intermediary understands the [425 Too Early](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/425) status code.\n   *\n   * The `Early-Data` header is **not** set by the originator of the\n   * request (i.e., a browser).\n   */\n  'Early-Data' = 'Early-Data',\n\n  /**\n   * The **`ECT`** [Client hint](/en-US/docs/Web/HTTP/Client_hints) request header field indicates the [effective connection type](https://developer.mozilla.org/en-US/docs/Glossary/effective_connection_type): `slow-2g`, `2g`, `3g`, `4g`.\n   *\n   *\n   *\n   * The value represents the \"network profile\" that best matches the connection's latency and bandwidth, rather than the actual mechanisms used for transferring the data. For example, `2g` might be used to represent a slow Wi-Fi connection with high latency and low bandwidth, while `4g` might be used to represent a fast fibre-based broadband network.\n   *\n   * The hint allows a server to choose what information is sent based on the broad characteristics of the network. For example, a server might choose to send smaller versions of images and other resources on less capable connections. The value might also be used as a starting point for determining what information is sent, which is further refined using information in [RTT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/RTT) and [Downlink](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Downlink) hints.\n   *\n   * > [!NOTE]\n   * > A server that specifies `ECT` in [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) may also specify it in [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) to indicate that responses should be cached for different ECT values.\n   */\n  'ECT' = 'ECT',\n\n  /**\n   * The **`ETag`** (or **entity tag**) HTTP response header is an identifier for a\n   * specific version of a resource. It lets caches be more efficient and save bandwidth, as\n   * a web server does not need to resend a full response if the content was not changed.\n   * Additionally, etags help to prevent simultaneous updates of a resource from overwriting\n   * each other ([\"mid-air collisions\"](#avoiding_mid-air_collisions)).\n   *\n   * If the resource at a given URL changes, a new `Etag` value _must_ be\n   * generated. A comparison of them can determine whether two representations of a resource\n   * are the same.\n   */\n  'ETag' = 'ETag',\n\n  /**\n   * The `Expect-CT` header lets sites opt in to reporting and/or enforcement of [Certificate Transparency](/en-US/docs/Web/Security/Certificate_Transparency) requirements. Certificate Transparency (CT) aims to prevent the use of misissued certificates for that site from going unnoticed.\n   *\n   * Only Google Chrome and other Chromium-based browsers implemented `Expect-CT`, and Chromium has deprecated the header from version 107, because Chromium now enforces CT by default. See the [Chrome Platform Status](https://chromestatus.com/feature/6244547273687040) update.\n   *\n   * CT requirements can be satisfied via any one of the following mechanisms:\n   *\n   * - X.509v3 certificate extension to allow embedding of signed certificate timestamps issued by individual logs. Most TLS certificates issued by publicly-trusted CAs and used online contain embedded CT.\n   * - A TLS extension of type `signed_certificate_timestamp` sent during the handshake\n   * - Supporting OCSP stapling (that is, the `status_request` TLS extension) and providing a `SignedCertificateTimestampList`\n   *\n   * > [!NOTE]\n   * > When a site enables the `Expect-CT` header, they are requesting that the browser check that any certificate for that site appears in **[public CT logs](https://github.com/google/certificate-transparency-community-site/blob/master/docs/google/known-logs.md)**.\n   *\n   * > [!NOTE]\n   * > Browsers **ignore** the `Expect-CT` header over HTTP; the header only has effect on HTTPS connections.\n   *\n   * > [!NOTE]\n   * > The `Expect-CT` is mostly obsolete since June 2021. Since May 2018, all new TLS certificates are expected to support SCTs by default. Certificates issued before March 2018 were allowed to have a lifetime of 39 months, so they had expired in June 2021. Chromium plans to deprecate `Expect-CT` header and to eventually remove it.\n   */\n  'Expect-CT' = 'Expect-CT',\n\n  /**\n   * The **`Expect`** HTTP request header indicates expectations\n   * that need to be met by the server to handle the request successfully.\n   *\n   * Upon `Expect: 100-continue`, the server responds with:\n   *\n   * - [100](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100) (Continue) if the information from the request header is insufficient to\n   * resolve the response and the client should proceed with sending the body.\n   * - [417](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/417) (Expectation Failed) if the server cannot meet the expectation\n   *\n   * or any other status otherwise (e.g. a 4xx status for a client error, or a 2xx status if the\n   * request can be resolved successfully without further processing).\n   *\n   * For example, the server may reject a request if its [Content-Length](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length) is\n   * too large.\n   *\n   * No common browsers send the `Expect` header, but some other clients such as\n   * cURL do so by default.\n   */\n  'Expect' = 'Expect',\n\n  /**\n   * The **`Expires`** HTTP header contains the date/time after which the\n   * response is considered expired.\n   *\n   * Invalid expiration dates with value 0 represent a date in the past and mean that the\n   * resource is already expired.\n   *\n   * > [!NOTE]\n   * > If there is a [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) header\n   * > with the `max-age` or `s-maxage` directive in the response,\n   * > the `Expires` header is ignored.\n   */\n  'Expires' = 'Expires',\n\n  /**\n   * The **`Forwarded`** request header contains information that may be added by [reverse proxy servers](/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling) (load balancers, CDNs, and so on) that would otherwise be altered or lost when proxy servers are involved in the path of the request.\n   *\n   * For example, if a client is connecting to a web server through an HTTP proxy (or load balancer), server logs will only contain the IP address, host address, and protocol of the proxy; this header can be used to identify the IP address, host, and protocol, of the original request.\n   * The header is optional and may be added to, modified, or removed, by any of the proxy servers on the path to the server.\n   *\n   * This header is used for debugging, statistics, and generating location-dependent content.\n   * By design, it exposes privacy sensitive information, such as the IP address of the client.\n   * Therefore, the user's privacy must be kept in mind when deploying this header.\n   *\n   * The alternative and de-facto standard versions of this header are the [X-Forwarded-For](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For), [X-Forwarded-Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host) and [X-Forwarded-Proto](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto) headers.\n   */\n  'Forwarded' = 'Forwarded',\n\n  /**\n   * The **`From`** request header contains an Internet email\n   * address for a human user who controls the requesting user agent.\n   *\n   * If you are running a robotic user agent (e.g. a crawler), the `From` header\n   * must be sent, so you can be contacted if problems occur on servers, such as if the\n   * robot is sending excessive, unwanted, or invalid requests.\n   *\n   * > [!WARNING]\n   * > You must not use the `From` header for access control or authentication.\n   */\n  'From' = 'From',\n\n  /**\n   * The **`Host`** request header specifies the host and port\n   * number of the server to which the request is being sent.\n   *\n   * If no port is included, the default port for the service requested is implied (e.g.,\n   * `443` for an HTTPS URL, and `80` for an HTTP URL).\n   *\n   * A `Host` header field must be sent in all HTTP/1.1 request messages. A\n   * [400](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400) (Bad Request) status code may be sent to any HTTP/1.1 request\n   * message that lacks or contains more than one `Host` header field.\n   */\n  'Host' = 'Host',\n\n  /**\n   * The **`If-Match`** HTTP request header makes a request conditional.\n   *\n   * A server will only return requested resources for [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) and [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) methods, or upload resource for [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT) and other non-safe methods, if the resource matches one of the listed [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) values.\n   * If the conditional does not match then the [412](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) (Precondition Failed) response is returned.\n   *\n   * The comparison with the stored [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) uses the _strong comparison algorithm_, meaning two files are considered identical byte by byte only.\n   * If a listed `ETag` has the `W/` prefix indicating a weak entity tag, this comparison algorithm will never match it.\n   *\n   * There are two common use cases:\n   *\n   * - For [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) and [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) methods, used in combination with a [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) header, it can guarantee that the new ranges requested\n   * come from the same resource as the previous one.\n   * - For other methods, and in particular for [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT), `If-Match` can be used to prevent the [lost update problem](https://www.w3.org/1999/04/Editing/#3.1).\n   * It can check if the modification of a resource that the user wants to upload will not override another change that has been done since the original resource was fetched.\n   */\n  'If-Match' = 'If-Match',\n\n  /**\n   * The **`If-Modified-Since`** request HTTP header makes the\n   * request conditional: the server sends back the requested resource, with a\n   * [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) status, only if it has been last modified after the given date. If\n   * the resource has not been modified since, the response is a [304](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304)\n   * without any body; the [Last-Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified) response header of a previous\n   * request contains the date of last modification. Unlike\n   * [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since), `If-Modified-Since` can only be used\n   * with a [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) or [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD).\n   *\n   * When used in combination with [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match), it is ignored, unless\n   * the server doesn't support `If-None-Match`.\n   *\n   * The most common use case is to update a cached entity that has no associated\n   * [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag).\n   */\n  'If-Modified-Since' = 'If-Modified-Since',\n\n  /**\n   * The **`If-None-Match`** HTTP request header makes the request conditional. For [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) and [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) methods, the server will return the requested resource, with a [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) status, only if it doesn't have an [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) matching the given ones. For other methods, the request will be processed only if the eventually existing resource's [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) doesn't match any of the values listed.\n   *\n   * When the condition fails for [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) and [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) methods, then the server must return HTTP status code 304 (Not Modified). For methods that apply server-side changes, the status code 412 (Precondition Failed) is used. Note that the server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.\n   *\n   * The comparison with the stored [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) uses the _weak comparison algorithm_, meaning two files are considered identical if the content is equivalent — they don't have to be identical byte by byte. For example, two pages that differ by their creation date in the footer would still be considered identical.\n   *\n   * When used in combination with [If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since), **`If-None-Match`** has precedence (if the server supports it).\n   *\n   * There are two common use cases:\n   *\n   * - For [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) and [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) methods, to update a cached entity that has an associated [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag).\n   * - For other methods, and in particular for [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT), `If-None-Match` used with the `*` value can be used to save a file not known to exist, guaranteeing that another upload didn't happen before, losing the data of the previous put; this problem is a variation of the [lost update problem](https://www.w3.org/1999/04/Editing/#3.1).\n   */\n  'If-None-Match' = 'If-None-Match',\n\n  /**\n   * The **`If-Range`** HTTP request header makes a range request\n   * conditional: if the condition is fulfilled, the range request is issued, and the\n   * server sends back a [206](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206) `Partial Content` answer with the\n   * appropriate body. If the condition is not fulfilled, the full resource is sent back\n   * with a [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) `OK` status.\n   *\n   * This header can be used either with the [Last-Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified) validator or\n   * with [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag), but not with both.\n   *\n   * The most common use case is to resume a download, to guarantee that the stored resource\n   * has not been modified since the last fragment has been received.\n   */\n  'If-Range' = 'If-Range',\n\n  /**\n   * The HTTP **`If-Unmodified-Since`** [request header](https://developer.mozilla.org/en-US/docs/glossary/request_header) makes the request for the resource [conditional](/en-US/docs/Web/HTTP/Conditional_requests).\n   * The server will send the requested resource (or accept it in the case of a [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) or another non-[safe](https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP) method) only if the resource on the server has not been modified after the date in the request header.\n   * If the resource has been modified after the specified date, the response will be a [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) error.\n   *\n   * The `If-Unmodified-Since` header is commonly used in the following situations:\n   *\n   * - In conjunction with non-[safe](https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP) methods like [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST), this header can be used to implement an [optimistic concurrency control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control), as is done by some wikis: revision are rejected if the stored document has been modified since the original was retrieved, avoiding conflicts.\n   * - In conjunction with a range request using the [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) header, this header can be used to ensure that the new fragment requested comes from an unmodified document.\n   */\n  'If-Unmodified-Since' = 'If-Unmodified-Since',\n\n  /**\n   * The **`Keep-Alive`** general header allows the sender to hint about how the connection may be used to set a timeout and a maximum amount of requests.\n   *\n   * > [!NOTE]\n   * > Set the [Connection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection) header to \"keep-alive\" for this header to have any effect.\n   *\n   * > [!WARNING]\n   * > Connection-specific header fields such as\n   * > [Connection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection) and `Keep-Alive` are prohibited\n   * > in [HTTP/2](https://httpwg.org/specs/rfc9113.html#ConnectionSpecific) and\n   * > [HTTP/3](https://httpwg.org/specs/rfc9114.html#header-formatting). Chrome and\n   * > Firefox ignore them in HTTP/2 responses, but Safari conforms to the HTTP/2\n   * > specification requirements and does not load any response that contains them.\n   */\n  'Keep-Alive' = 'Keep-Alive',\n\n  /**\n   * The HTTP **`Last-Modified`** [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) contains a date and time when the origin server believes the resource was last modified.\n   * It is used as a validator in [conditional requests](/en-US/docs/Web/HTTP/Conditional_requests) ([If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since) or [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since)) to determine if a requested resource is the same as one already stored by the client.\n   * It is less accurate than an [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) for determining file contents, but can be used as a fallback mechanism if ETags are unavailable.\n   *\n   * `Last-Modified` is also used by [crawlers](/en-US/docs/Glossary/Crawler) to adjust crawl frequency, by browsers in [heuristic caching](/en-US/docs/Web/HTTP/Caching#heuristic_caching), and by content management systems (CMS) to display the time the content was last modified.\n   */\n  'Last-Modified' = 'Last-Modified',\n\n  /**\n   * The HTTP **`Link`** header provides a means for serializing one or more links in HTTP headers.\n   * This allows the server to point a client to another resource containing metadata about the requested resource.\n   * This header has the same semantics as the HTML [link](https://developer.mozilla.org/en-US/docs/HTMLElement/link) element.\n   * One benefit of using the `Link` header is that the browser can start preconnecting or preloading resources before the HTML itself is fetched and processed.\n   *\n   * In practice, most [`rel` link types](/en-US/docs/Web/HTML/Attributes/rel) don't have an effect when used with the HTTP header.\n   * For example, the `icon` relation only works in HTML, and `stylesheet` does not work reliably across browsers (only in Firefox).\n   * The only relations that work reliably are [`preconnect`](/en-US/docs/Web/HTML/Attributes/rel/preconnect) and [`preload`](/en-US/docs/Web/HTML/Attributes/rel/preload), which can be combined with .\n   */\n  'Link' = 'Link',\n\n  /**\n   * The HTTP **`Location`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates the URL to redirect a page to.\n   * It only provides a meaning when served with a `3XX` [redirection response](/en-US/docs/Web/HTTP/Status#redirection_messages) or a [201 Created](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201) status response.\n   *\n   * In redirections, the HTTP method used to make the redirected request to fetch the page pointed to by `Location` depends on the original method and the kind of redirection:\n   *\n   * - [303 See Other](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/303) responses always result in a [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) request in the redirection.\n   * - [307 Temporary Redirect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307) and [308 Permanent Redirect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308) use the same method as the initiating request.\n   * - [301 Moved Permanently](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301) and [302 Found](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302) should use the same request method as the initiating request, although this is not guaranteed for older user-agents.\n   *\n   * All responses with one of the above status codes include a `Location` header.\n   *\n   * In cases of resource creation, it indicates the URL of the newly-created resource so that a client can make a request for it immediately.\n   *\n   * `Location` and [Content-Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Location) are different.\n   * `Content-Location` indicates the URL to use to directly access the resource in future when [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) occurred.\n   * `Location` is associated with the response, while [Content-Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Location) is associated with the representation that was returned.\n   */\n  'Location' = 'Location',\n\n  /**\n   * The HTTP **`Max-Forwards`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is used with the [TRACE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/TRACE) method to limit the number of nodes (usually [proxies](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server)) that the request goes through.\n   * Its value is an integer indicating the _maximum amount_ of nodes it must visit.\n   * At each node, the value is decremented and the `TRACE` request is forwarded to the next node until the destination is reached or the received value of `Max-Forwards` is zero.\n   * The request is then sent back (excluding sensitive headers where appropriate) as the body of a [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) response.\n   * This allows the client to see what is being received at the other end of the request chain (the [Via](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Via) header is of particular interest) for testing or diagnostic purposes.\n   *\n   * If the `Max-Forwards` header is not present in a `TRACE` request, a node will assume that there is no maximum number of forwards.\n   */\n  'Max-Forwards' = 'Max-Forwards',\n\n  /**\n   * The HTTP **`NEL`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used to configure network request logging.\n   */\n  'NEL' = 'NEL',\n\n  /**\n   * The HTTP **`No-Vary-Search`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) specifies a set of rules that define how a URL's query parameters will affect cache matching.\n   * These rules dictate whether the same URL with different URL parameters should be saved as separate browser cache entries.\n   *\n   * > [!NOTE]\n   * > The [Speculation Rules API](/en-US/docs/Web/API/Speculation_Rules_API) can include an `expects_no_vary_search` field, which indicates to the browser what the expected `No-Vary-Search` value will be (if any) for documents that it is receiving prefetch/prerender requests for via the speculation rules.\n   * > The browser can use this to determine ahead of time whether it is more useful to wait for an existing prefetch/prerender to finish, or start a new fetch request when the speculation rule is matched.\n   */\n  'No-Vary-Search' = 'No-Vary-Search',\n\n  /**\n   * > [!WARNING]\n   * > This feature is currently opposed by two browser vendors. See the [Standards positions](/en-US/docs/Web/API/Topics_API#standards_positions) section for details of opposition.\n   *\n   * The HTTP **`Observe-Browsing-Topics`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used to mark topics of interest inferred from a calling site's URL (i.e., the site where the ad tech [iframe](https://developer.mozilla.org/en-US/docs/HTMLElement/iframe) is embedded) as observed in the response to a request generated by a [feature that enables the Topics API](/en-US/docs/Web/API/Topics_API/Using#what_api_features_enable_the_topics_api).\n   * The browser will subsequently use those topics to calculate top topics for the current user for future epochs.\n   *\n   * See [Using the Topics API](/en-US/docs/Web/API/Topics_API/Using) for more details.\n   */\n  'Observe-Browsing-Topics' = 'Observe-Browsing-Topics',\n\n  /**\n   * The HTTP **`Origin-Agent-Cluster`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used to request that the associated [Document](https://developer.mozilla.org/en-US/docs/domxref/Document) should be placed in an _origin-keyed [agent cluster](https://tc39.es/ecma262/#sec-agent-clusters)_. This means that operating system resources (for example, the operating system process) used to evaluate the document should be shared only with other documents from the same [origin](https://developer.mozilla.org/en-US/docs/glossary/origin).\n   *\n   * The effect of this is that a resource-intensive document will be less likely to degrade the performance of documents from other origins.\n   *\n   * Modern web browsers have a multiprocess architecture in which pages from different origins can run in different operating system processes. This is important for performance, because it means that a resource-intensive page will not have as much of an impact on other pages that the user has open.\n   *\n   * However, browsers can't as a general rule run [same-site](https://developer.mozilla.org/en-US/docs/glossary/site), [cross-origin](https://developer.mozilla.org/en-US/docs/glossary/origin) pages in different processes, because of certain DOM APIs that depend on same-site, cross-origin communication. For example, by default, pages from the following two origins will share the same operating system resources:\n   *\n   * ```plain\n   * https://apples.example.org\n   * https://oranges.example.org\n   * ```\n   *\n   * By setting the `Origin-Agent-Cluster` header, a page can request that the browser allocate dedicated resources to this origin that are not shared with any other origins.\n   *\n   * The browser is not required to honor the request. If it does, the [Window.originAgentCluster](https://developer.mozilla.org/en-US/docs/domxref/Window.originAgentCluster) property returns `true`, and the window is not able to do the following things, which all depend on same-site, cross-origin communication:\n   *\n   * - Use [Document.domain](https://developer.mozilla.org/en-US/docs/domxref/Document.domain).\n   * - Send [`WebAssembly.Module`](/en-US/docs/WebAssembly/JavaScript_interface/Module) objects to other same-site cross-origin pages using [postMessage()](https://developer.mozilla.org/en-US/docs/domxref/Window.postMessage()).\n   * - Send [SharedArrayBuffer](https://developer.mozilla.org/en-US/docs/jsxref/SharedArrayBuffer) or [`WebAssembly.Memory`](/en-US/docs/WebAssembly/JavaScript_interface/Memory) objects to other same-site cross-origin pages.\n   *\n   * Origin-keyed agent clusters should not be viewed as a security feature: browsers may ignore the request for various reasons, or choose to implement it in a way that does not provide memory protection (for example, using separate threads instead of separate processes). Instead, this feature is a hint that the user experience would be improved if this origin were allocated dedicated resources.\n   *\n   * For example, suppose your site includes a page from one origin that embeds a same-site, cross-origin iframe which runs a resource-intensive game. By setting `Origin-Agent-Cluster` on the document in the iframe, you can prevent the game from affecting the performance of the main page.\n   *\n   * The browser will ensure that all pages from a given origin are either origin-keyed or they are not. This means that:\n   *\n   * - If the first page from an origin does not set the header, then no other pages from that origin will be origin-keyed, even if those other pages do set the header.\n   * - If the first page from an origin sets the header and is made origin-keyed, then all other pages from that origin will be origin-keyed whether they ask for it or not.\n   *\n   * To avoid this kind of unpredictable situation, you should set this header for all pages from a given origin, or none of them.\n   */\n  'Origin-Agent-Cluster' = 'Origin-Agent-Cluster',\n\n  /**\n   * The HTTP **`Origin`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates the [origin](https://developer.mozilla.org/en-US/docs/glossary/origin) ([scheme](/en-US/docs/Web/URI/Schemes), hostname, and port) that _caused_ the request.\n   * For example, if a user agent needs to request resources included in a page, or fetched by scripts that it executes, then the origin of the page may be included in the request.\n   */\n  'Origin' = 'Origin',\n\n  /**\n   * The HTTP **`Permissions-Policy`** header provides a mechanism to allow and deny the use of browser features in a document or within any [iframe](https://developer.mozilla.org/en-US/docs/HTMLElement/iframe) elements in the document.\n   *\n   * For more information, see the main [Permissions Policy](/en-US/docs/Web/HTTP/Permissions_Policy) article.\n   */\n  'Permissions-Policy' = 'Permissions-Policy',\n\n  /**\n   * The HTTP **`Pragma`** header is an implementation-specific header that may have various effects along the request-response chain.\n   * This header serves for backwards compatibility with HTTP/1.0 caches that do not support the [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) HTTP/1.1 header.\n   *\n   * > [!NOTE]\n   * > The `Pragma` header is not specified for HTTP responses and is therefore not a reliable replacement for the HTTP/1.1 `Cache-Control` header, although its behavior is the same as `Cache-Control: no-cache` if the `Cache-Control` header field is omitted in a request.\n   * > Use `Pragma` only for backwards compatibility with HTTP/1.0 clients.\n   */\n  'Pragma' = 'Pragma',\n\n  /**\n   * The HTTP **`Priority`** header indicates a client's preference for the priority order at which the response containing the requested resource should be sent, relative to other resource requests on the same connection.\n   * If the header is not specified in the request, a default priority is assumed.\n   * The server may also include this header in responses in order to indicate it has an interest in changing the prioritization preferences the client advertized.\n   * In responses, this information can be used as an input to the prioritization process for caching servers and other servers that are forwarding the response.\n   *\n   * The server is not bound by client prioritization and might only use client priorities as hints for its own prioritization process.\n   * For example, a server may know that a specific image is vital for user experience and should be sent at the highest priority.\n   * Server prioritization might also be affected by factors such as network congestion.\n   *\n   * This request may be cached, and the server is expected to control the cacheability or the applicability of the cached response using the header fields that control the caching behavior, such as [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary).\n   *\n   * > [!NOTE]\n   * > This header is one part of the \"Extensible Prioritization Scheme for HTTP\" defined in [9218](https://developer.mozilla.org/en-US/docs/rfc/9218).\n   * > There are also HTTP/2 and HTTP/3 `PRIORITY_UPDATE` frames that can be used to re-prioritize a resource request after it has been sent.\n   * > The request can be sent in any HTTP version.\n   */\n  'Priority' = 'Priority',\n\n  /**\n   * The HTTP **`Proxy-Authenticate`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) defines the [authentication](/en-US/docs/Web/HTTP/Authentication) method (or [challenge](https://developer.mozilla.org/en-US/docs/Glossary/Challenge)) that should be used to gain access to a resource behind a [proxy server](https://developer.mozilla.org/en-US/docs/Glossary/proxy_server).\n   * It is sent in a [407 Proxy Authentication Required](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407) response so a client can identify itself to a proxy that requires authentication.\n   */\n  'Proxy-Authenticate' = 'Proxy-Authenticate',\n\n  /**\n   * The HTTP **`Proxy-Authorization`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) contains the credentials to authenticate a client with a proxy server, typically after the server has responded with a [407 Proxy Authentication Required](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407) status with the [Proxy-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authenticate) header.\n   */\n  'Proxy-Authorization' = 'Proxy-Authorization',\n\n  /**\n   * The HTTP **`Range`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates the part of a resource that the server should return.\n   * Several parts can be requested at the same time in one `Range` header, and the server may send back these ranges in a multipart document.\n   * If the server sends back ranges, it uses the [206 Partial Content](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206) status code for the response.\n   * If the ranges are invalid, the server returns the [416 Range Not Satisfiable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416) error.\n   *\n   * A server that doesn't support range requests may ignore the `Range` header and return the whole resource with a [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) status code.\n   * Older browsers used a response header of [Accept-Ranges: none](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Ranges) to disable features like 'pause' or 'resume' in download managers, but since ignoring the `Range` header has the same effect as `Accept-Ranges: none`, the header is rarely used in this way.\n   *\n   * Currently only [`bytes` units are registered](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#range-units) which are _offsets_ (zero-indexed & inclusive).\n   * If the requested data has a [content coding](/en-US/docs/Web/HTTP/Headers/Content-Encoding) applied, each byte range represents the encoded sequence of bytes, not the bytes that would be obtained after decoding.\n   *\n   * The header is a [CORS-safelisted request header](/en-US/docs/Glossary/CORS-safelisted_request_header) when the directive specifies a single byte range.\n   */\n  'Range' = 'Range',\n\n  /**\n   * The HTTP **`Referer`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) contains the absolute or partial address from which a resource has been requested.\n   * The `Referer` header allows a server to identify referring pages that people are visiting from or where requested resources are being used.\n   * This data can be used for analytics, logging, optimized caching, and more.\n   *\n   * When you click a link, the `Referer` contains the address of the page that includes the link.\n   * When you make resource requests to another domain, the `Referer` contains the address of the page that uses the requested resource.\n   *\n   * The `Referer` header can contain an _origin_, _path_, and _querystring_, and may not contain [URL fragments](/en-US/docs/Web/URI/Fragment) (i.e., `#section`) or `username:password` information.\n   * The request's _referrer policy_ defines the data that can be included. See [Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy) for more [information](/en-US/docs/Web/HTTP/Headers/Referrer-Policy#directives) and [examples](/en-US/docs/Web/HTTP/Headers/Referrer-Policy#examples).\n   *\n   * > [!NOTE]\n   * > The header name \"referer\" is actually a misspelling of the word \"referrer\".\n   * > See [HTTP referer on Wikipedia](https://en.wikipedia.org/wiki/HTTP_referer) for more details.\n   *\n   * > [!WARNING]\n   * > This header may have undesirable consequences for user security and privacy.\n   * > See [Referer header: privacy and security concerns](/en-US/docs/Web/Security/Referer_header:_privacy_and_security_concerns) for more information and mitigation hints.\n   */\n  'Referer' = 'Referer',\n\n  /**\n   * The HTTP **`Referrer-Policy`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) controls how much [referrer information](/en-US/docs/Web/Security/Referer_header:_privacy_and_security_concerns) (sent with the [Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer) header) should be included with requests.\n   * Aside from the HTTP header, you can [set this policy in HTML](#integration_with_html).\n   */\n  'Referrer-Policy' = 'Referrer-Policy',\n\n  /**\n   * The HTTP **`Refresh`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) directs a web browser to either refresh or redirect the page when a specified amount of time has passed after the page was fully loaded.\n   * It is exactly equivalent to using [`\n   */\n  'Refresh' = 'Refresh',\n\n  /**\n   * > [!WARNING]\n   * > This header has been replaced by the [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Reporting-Endpoints) HTTP response header.\n   * > It is a deprecated part of an earlier iteration of the [Reporting API](/en-US/docs/Web/API/Reporting_API) specification.\n   *\n   * The HTTP **`Report-To`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) allows website administrators to define named groups of endpoints that can be used as the destination for warning and error reports, such as CSP violation reports, [Cross-Origin-Opener-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) reports, deprecation reports, or other generic violations.\n   *\n   * `Report-To` is often used in conjunction with other headers that select a group of endpoints to use for a particular kind of report.\n   * For example, the [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) header [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive can be used to select the group used for reporting CSP violations.\n   */\n  'Report-To' = 'Report-To',\n\n  /**\n   * The HTTP **`Reporting-Endpoints`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) allows website administrators to specify one or more endpoints that can be sent reports generated by the [Reporting API](/en-US/docs/Web/API/Reporting_API).\n   *\n   * The endpoints can be used, for example, as targets for sending CSP violation reports, [Cross-Origin-Opener-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) reports, or other generic violations.\n   *\n   * When used for reporting [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/CSP#violation_reporting) errors, the header is used in combination with the [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) header [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive.\n   * For more details on setting up CSP reporting, see the [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/CSP#violation_reporting) documentation.\n   *\n   * > [!NOTE]\n   * > This header replaces [Report-To](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Report-To)  for declaring endpoints, and should be used in preference.\n   */\n  'Reporting-Endpoints' = 'Reporting-Endpoints',\n\n  /**\n   * The **`Repr-Digest`** response or request header provides a [digest](https://developer.mozilla.org/en-US/docs/Glossary/digest) of the [selected representation](https://www.rfc-editor.org/rfc/rfc9110#section-6.4) of the target resource. It is invariant under e.g., [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) or [Content-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range), which do affect the [Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Digest). Furthermore, [Content Negotiation](/en-US/docs/Web/HTTP/Content_negotiation) can result in different selected representations with different representation digests.\n   */\n  'Repr-Digest' = 'Repr-Digest',\n\n  /**\n   * The **`Retry-After`** response HTTP header indicates how long\n   * the user agent should wait before making a follow-up request. There are three main cases\n   * this header is used:\n   *\n   * - When sent with a  (Service Unavailable) response, this indicates\n   * how long the service is expected to be unavailable.\n   * - When sent with a  (Too Many Requests) response, this indicates\n   * how long to wait before making a new request.\n   * - When sent with a redirect response, such as  (Moved Permanently),\n   * this indicates the minimum time that the user agent is asked to wait before issuing\n   * the redirected request.\n   */\n  'Retry-After' = 'Retry-After',\n\n  /**\n   * The **`RTT`** [Client hint](/en-US/docs/Web/HTTP/Client_hints) request header field provides the approximate round trip time on the application layer, in milliseconds. The RTT hint, unlike transport layer RTT, includes server processing time.\n   *\n   *\n   *\n   * The RTT value is rounded to the nearest 25 milliseconds to prevent [fingerprinting](/en-US/docs/Glossary/Fingerprinting). There are many other mechanisms an attacker might use to obtain similar round-trip information.\n   *\n   * The hint allows a server to choose what information is sent based on the network responsiveness/latency. For example, it might choose to send fewer resources.\n   *\n   * > [!NOTE]\n   * > The [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header is used in responses to indicate that a different resource is sent for every different value of the header (see [HTTP Caching Vary](/en-US/docs/Web/HTTP/Caching#vary)). Even if `RTT` is used to configure what resources are sent consider omitting it in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header — it is likely to change often, which effectively makes the resource uncacheable.\n   */\n  'RTT' = 'RTT',\n\n  /**\n   * The **`Save-Data`** [network client hint](/en-US/docs/Web/HTTP/Client_hints#network_client_hints) request header field is a boolean which indicates the client's preference for reduced data usage.\n   * This could be for reasons such as high transfer costs, slow connection speeds, etc.\n   *\n   * **`Save-Data`** is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints), and hence may be sent by the client even if not requested by the server using an [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header.\n   * Further, it should be used to reduce data sent to the client irrespective of the values of other client hints that indicate network capability, like [Downlink](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Downlink) and [RTT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/RTT).\n   *\n   *\n   *\n   * A value of `On` indicates explicit user opt-in into a reduced data usage\n   * mode on the client, and when communicated to origins allows them to deliver alternative\n   * content to reduce the data downloaded such as smaller image and video resources,\n   * different markup and styling, disabled polling and automatic updates, and so on.\n   *\n   * > [!NOTE]\n   * > Disabling HTTP/2 Server Push ([Server Push\", \"8.2](https://developer.mozilla.org/en-US/docs/RFC/7540)) may reduce data downloads.\n   * > Note that this feature is no longer supported by default in most major browser engines.\n   */\n  'Save-Data' = 'Save-Data',\n\n  /**\n   * > [!WARNING]\n   * > This feature is currently opposed by two browser vendors. See the [Standards positions](/en-US/docs/Web/API/Topics_API#standards_positions) section for details of opposition.\n   *\n   * > [!NOTE]\n   * > An [Enrollment process](/en-US/docs/Web/Privacy/Privacy_sandbox/Enrollment) is required to use this feature in your applications.\n   *\n   * The **`Sec-Browsing-Topics`** request header sends the selected topics for the current user along with the associated request, which are used by an ad tech platform to choose a personalized ad to display.\n   *\n   * If the calling site does not have the Topics API included in a successful [privacy sandbox enrollment process](/en-US/docs/Web/Privacy/Privacy_sandbox/Enrollment), attempting to create or modify `Sec-Browsing-Topics` fails silently, and any existing `Sec-Browsing-Topics` header is deleted.\n   *\n   * See [Using the Topics API](/en-US/docs/Web/API/Topics_API/Using) for more details.\n   */\n  'Sec-Browsing-Topics' = 'Sec-Browsing-Topics',\n\n  /**\n   * The **`Sec-CH-Prefers-Color-Scheme`** [user preference media feature client hint](/en-US/docs/Web/HTTP/Client_hints#user_preference_media_features_client_hints) request header provides the user's preference for light or dark color themes. A user indicates their preference through an operating system setting (for example, light or dark mode) or a user agent setting.\n   *\n   * If a server signals to a client via the [Accept-CH](https://developer.mozilla.org/en-US/docs/httpheader/Accept-CH) header that it accepts `Sec-CH-Prefers-Color-Scheme`, the client can then respond with this header to indicate the user's preference for a specific color scheme. The server can send the client appropriately adapted content including images or CSS to display a light or dark mode for subsequent rendered content.\n   *\n   * This header is modeled on the [prefers-color-scheme](https://developer.mozilla.org/en-US/docs/cssxref/@media/prefers-color-scheme) media query.\n   */\n  'Sec-CH-Prefers-Color-Scheme' = 'Sec-CH-Prefers-Color-Scheme',\n\n  /**\n   * The **`Sec-CH-Prefers-Reduced-Motion`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user_preference_media_features_client_hints) request header indicates the user agent's preference for animations to be displayed with reduced motion.\n   *\n   * If a server signals to a client via the [Accept-CH](https://developer.mozilla.org/en-US/docs/httpheader/Accept-CH) header that it accepts `Sec-CH-Prefers-Reduced-Motion`, the client can then respond with this header to indicate the user's preference for reduced motion. The server can send the client appropriately adapted content, for example, JavaScript or CSS, to reduce the motion of any animations presented on subsequent rendered content. This could include reducing the speed or amplitude of movement to reduce discomfort for those with vestibular motion disorders.\n   *\n   * This header is modeled on the [prefers-reduced-motion](https://developer.mozilla.org/en-US/docs/cssxref/@media/prefers-reduced-motion) media query.\n   */\n  'Sec-CH-Prefers-Reduced-Motion' = 'Sec-CH-Prefers-Reduced-Motion',\n\n  /**\n   * The **`Sec-CH-Prefers-Reduced-Transparency`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user_preference_media_features_client_hints) request header indicates the user agent's preference for reduced transparency.\n   *\n   * If a server signals to a client via the [Accept-CH](https://developer.mozilla.org/en-US/docs/httpheader/Accept-CH) header that it accepts `Sec-CH-Prefers-Reduced-Transparency`, the client can then respond with this header to indicate the user's preference for reduced transparency. The server can send the client appropriately adapted content — for example, CSS or images — to reduce the transparency of the content.\n   *\n   * This header is modeled on the [prefers-reduced-transparency](https://developer.mozilla.org/en-US/docs/cssxref/@media/prefers-reduced-transparency) media query.\n   */\n  'Sec-CH-Prefers-Reduced-Transparency' = 'Sec-CH-Prefers-Reduced-Transparency',\n\n  /**\n   * The **`Sec-CH-UA-Arch`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the user-agent's underlying CPU architecture, such as ARM or x86.\n   *\n   * This might be used by a server, for example, to select and offer the correct binary format of an executable for a user to download.\n   */\n  'Sec-CH-UA-Arch' = 'Sec-CH-UA-Arch',\n\n  /**\n   * The **`Sec-CH-UA-Bitness`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the \"bitness\" of the user-agent's underlying CPU architecture.\n   * This is the size in bits of an integer or memory address—typically 64 or 32 bits.\n   *\n   * This might be used by a server, for example, to select and offer the correct binary format of an executable for a user to download.\n   */\n  'Sec-CH-UA-Bitness' = 'Sec-CH-UA-Bitness',\n\n  /**\n   * The **`Sec-CH-UA-Full-Version-List`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the user-agent's branding and full version information.\n   *\n   *\n   *\n   * The **`Sec-CH-UA-Full-Version-List`** header provides the brand and full version information for each brand associated with the browser, in a comma-separated list.\n   *\n   * A brand is a commercial name for the user agent like: Chromium, Opera, Google Chrome, Microsoft Edge, Firefox, and Safari.\n   * A user agent might have several associated brands.\n   * For example, Opera, Chrome, and Edge are all based on Chromium, and will provide both brands in the **`Sec-CH-UA-Full-Version-List`** header.\n   *\n   * The header therefore allows the server to customize its response based on both shared brands and on particular customizations in their specific respective builds.\n   *\n   * The header may include \"fake\" brands in any position and with any name.\n   * This is a feature designed to prevent servers from rejecting unknown user agents outright, forcing user agents to lie about their brand identity.\n   *\n   * > [!NOTE]\n   * > This is similar to [Sec-CH-UA](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-UA), but includes the full version number instead of the significant version number for each brand.\n   */\n  'Sec-CH-UA-Full-Version-List' = 'Sec-CH-UA-Full-Version-List',\n\n  /**\n   * > [!NOTE]\n   * > This is being replaced by the [Sec-CH-UA-Full-Version-List](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-UA-Full-Version-List).\n   *\n   * The **`Sec-CH-UA-Full-Version`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the user-agent's full version string.\n   */\n  'Sec-CH-UA-Full-Version' = 'Sec-CH-UA-Full-Version',\n\n  /**\n   * The **`Sec-CH-UA-Mobile`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header indicates whether the browser is on a mobile device.\n   * It can also be used by a desktop browser to indicate a preference for a \"mobile\" user experience.\n   *\n   * `Sec-CH-UA-Mobile` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints).\n   * Unless blocked by a user agent permission policy, it is sent by default, without the server opting in by sending [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH).\n   */\n  'Sec-CH-UA-Mobile' = 'Sec-CH-UA-Mobile',\n\n  /**\n   * The **`Sec-CH-UA-Model`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header indicates the device model on which the browser is running.\n   */\n  'Sec-CH-UA-Model' = 'Sec-CH-UA-Model',\n\n  /**\n   * The **`Sec-CH-UA-Platform-Version`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the version of the operating system on which the user agent is running.\n   */\n  'Sec-CH-UA-Platform-Version' = 'Sec-CH-UA-Platform-Version',\n\n  /**\n   * The **`Sec-CH-UA-Platform`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the platform or operating system on which the user agent is running.\n   * For example: \"Windows\" or \"Android\".\n   *\n   * `Sec-CH-UA-Platform` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints).\n   * Unless blocked by a user agent permission policy, it is sent by default (without the server opting in by sending [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)).\n   */\n  'Sec-CH-UA-Platform' = 'Sec-CH-UA-Platform',\n\n  /**\n   * The **`Sec-CH-UA`** [user agent client hint](/en-US/docs/Web/HTTP/Client_hints#user-agent_client_hints) request header provides the user-agent's branding and significant version information.\n   *\n   *\n   *\n   * The **`Sec-CH-UA`** header provides the brand and significant version for each brand associated with the browser in a comma-separated list.\n   *\n   * A brand is a commercial name for the user agent like: Chromium, Opera, Google Chrome, Microsoft Edge, Firefox, and Safari.\n   * A user agent might have several associated brands.\n   * For example, Opera, Chrome, and Edge are all based on Chromium, and will provide both brands in the **`Sec-CH-UA`** header.\n   *\n   * The _significant version_ is the \"marketing\" version identifier that is used to distinguish between major releases of the brand.\n   * For example a Chromium build with _full version number_ \"96.0.4664.45\" has a significant version number of \"96\".\n   *\n   * The header therefore allows the server to customize its response based on both shared brands and on particular customizations in their respective versions.\n   *\n   * `Sec-CH-UA` is a [low entropy hint](/en-US/docs/Web/HTTP/Client_hints#low_entropy_hints).\n   * Unless blocked by a user agent permission policy, it is sent by default, without the server opting in by sending [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH).\n   *\n   * The header may include \"fake\" brands in any position and with any name.\n   * This is a feature designed to prevent servers from rejecting unknown user agents outright, forcing user agents to lie about their brand identity.\n   *\n   * > **Note:** [Sec-CH-UA-Full-Version-List](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-UA-Full-Version-List) is the same as **`Sec-CH-UA`**, but includes the full version number rather than the significant version number for each brand.\n   */\n  'Sec-CH-UA' = 'Sec-CH-UA',\n\n  /**\n   * The **`Sec-Fetch-Dest`** [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header) indicates the request's _destination_. That is the initiator of the original fetch request, which is where (and how) the fetched data will be used.\n   *\n   * This allows servers to determine whether to service a request based on whether it is appropriate for how it is _expected_ to be used. For example, a request with an `audio` destination should request audio data, not some other type of resource (for example, a document that includes sensitive user information).\n   */\n  'Sec-Fetch-Dest' = 'Sec-Fetch-Dest',\n\n  /**\n   * The **`Sec-Fetch-Mode`** [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header) indicates the [mode](/en-US/docs/Web/API/Request/mode) of the request.\n   *\n   * Broadly speaking, this allows a server to distinguish between: requests originating from a user navigating between HTML pages, and requests to load images and other resources. For example, this header would contain `navigate` for top level navigation requests, while `no-cors` is used for loading an image.\n   */\n  'Sec-Fetch-Mode' = 'Sec-Fetch-Mode',\n\n  /**\n   * The **`Sec-Fetch-Site`** [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header) indicates the relationship between a request initiator's origin and the origin of the requested resource.\n   *\n   * In other words, this header tells a server whether a request for a resource is coming from the same origin, the same site, a different site, or is a \"user initiated\" request. The server can then use this information to decide if the request should be allowed.\n   *\n   * Same-origin requests would usually be allowed by default, but what happens for requests from other origins may further depend on what resource is being requested, or information in other [Fetch metadata request headers](https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header). By default, requests that are not accepted should be rejected with a [403](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403) response code.\n   */\n  'Sec-Fetch-Site' = 'Sec-Fetch-Site',\n\n  /**\n   * The **`Sec-Fetch-User`** [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header) is only sent for requests initiated by user activation, and its value will always be `?1`.\n   *\n   * A server can use this header to identify whether a navigation request from a document, iframe, etc., was originated by the user.\n   */\n  'Sec-Fetch-User' = 'Sec-Fetch-User',\n\n  /**\n   * The **`Sec-GPC`** ([**G**lobal **P**rivacy **C**ontrol](https://globalprivacycontrol.org/)) request header indicates whether the user consents to a website or service selling or sharing their personal information with third parties.\n   *\n   * The specification does not define how the user can withdraw or grant consent for website.\n   * Where possible the mechanism will be indicated in the [browser compatibility](#browser_compatibility) section below.\n   */\n  'Sec-GPC' = 'Sec-GPC',\n\n  /**\n   * The **`Sec-Purpose`** [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header) indicates the purpose for which the requested resource will be used, when that purpose is something other than immediate use by the user-agent.\n   *\n   * The only purpose that is currently defined is `prefetch`, which indicates that the resource is being requested in anticipation that it will be needed by a page that is likely to be navigated to in the near future, such as a page linked in search results or a link that a user has hovered over.\n   * The server can use this knowledge to: adjust the caching expiry for the request, disallow the request, or perhaps to treat it differently when counting page visits.\n   *\n   * The header is sent when a page is loaded that has a [`\n   */\n  'Sec-Purpose' = 'Sec-Purpose',\n\n  /**\n   * The **Sec-WebSocket-Accept** HTTP [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to indicate that the server is willing to upgrade to a WebSocket connection.\n   *\n   * This header must appear no more than once in the response, and has a directive value that is calculated from the [Sec-WebSocket-Key](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Key) request header sent in the corresponding request.\n   */\n  'Sec-WebSocket-Accept' = 'Sec-WebSocket-Accept',\n\n  /**\n   * The **Sec-WebSocket-Extensions** HTTP [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to negotiate a protocol extension used by the client and server.\n   *\n   * In a request the header specifies one or more extensions that the web application would like to use, in order of preference.\n   * These can be added as in multiple headers, or as comma separate values added to a single header.\n   *\n   * In a response the header can only appear once, where it specifies the extension selected by the server from the client's preferences.\n   * This value must be the first extension that the server supports from the list provided in the request header.\n   *\n   * The request header is automatically added by the browser based on its own capabilities, and does not depend on parameters passed to the constructor when the `WebSocket` is created.\n   */\n  'Sec-WebSocket-Extensions' = 'Sec-WebSocket-Extensions',\n\n  /**\n   * The **Sec-WebSocket-Key** HTTP [request header](https://developer.mozilla.org/en-US/docs/glossary/request_header) is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to allow a client (user agent) to confirm that it \"really wants\" to request that an HTTP client is upgraded to become a WebSocket.\n   *\n   * The value of the key is computed using an algorithm defined in the WebSocket specification, so this _does not provide security_.\n   * Instead, it helps to prevent non-WebSocket clients from inadvertently, or through misuse, requesting a WebSocket connection.\n   *\n   * This header is automatically added by user agents when a script opens a WebSocket; it cannot be added using the [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch) or [XMLHttpRequest.setRequestHeader()](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest.setRequestHeader()) methods.\n   *\n   * The server's [Sec-WebSocket-Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Accept) response header should include a value computed based upon the specified key value.\n   * The user agent can then validate this before this before confirming the connection.\n   */\n  'Sec-WebSocket-Key' = 'Sec-WebSocket-Key',\n\n  /**\n   * The **`Sec-WebSocket-Protocol`** HTTP [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to negotiate a [sub-protocol](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#subprotocols) to use in the communication.\n   * This can be a well understood protocol, such as SOAP or WAMP, or a custom protocol understood by the client and server.\n   *\n   * In a request the header specifies one or more WebSocket sub-protocols that the web application would like to use, in order of preference.\n   * These can be added as protocol values in multiple headers, or as comma separate values added to a single header.\n   *\n   * In a response it specifies the sub-protocol selected by the server.\n   * This must be the first sub-protocol that the server supports from the list provided in the request header.\n   *\n   * The request header is automatically added and populated by the browser using values specified by the application in the [`protocols`](/en-US/docs/Web/API/WebSocket/WebSocket#protocols) argument to the `WebSocket()`.\n   * The sub-protocol selected by the server is made available to the web application in [WebSocket.protocol](https://developer.mozilla.org/en-US/docs/domxref/WebSocket.protocol).\n   */\n  'Sec-WebSocket-Protocol' = 'Sec-WebSocket-Protocol',\n\n  /**\n   * The **Sec-WebSocket-Version** HTTP [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to indicate the WebSocket protocol supported by the client, and the protocol versions supported by the server if it does _not_ support the version specified in the request.\n   *\n   * The header can only appear once in a request, and specifies the WebSocket version that web application is using.\n   * The current version of the protocol at time of writing is 13.\n   * The header is automatically added to requests by user agents when a [WebSocket](https://developer.mozilla.org/en-US/docs/domxref/WebSocket) connection is established.\n   *\n   * The server uses the version to determine if it can understand the protocol.\n   * If the server doesn't support the version, or any header in the handshake is not understood or has an incorrect value, the server should send a response with status [400 Bad Request](https://developer.mozilla.org/en-US/docs/httpstatus/400) and immediately close the socket.\n   * It should also include `Sec-WebSocket-Version` in the `400` response, listing the versions that it does support.\n   * The versions can be specified in individual headers, or as comma-separate values in a single header.\n   *\n   * The header should not be sent in responses if the server understands the version specified by the client.\n   */\n  'Sec-WebSocket-Version' = 'Sec-WebSocket-Version',\n\n  /**\n   * The **`Server-Timing`** header communicates one or more metrics and descriptions for a given request-response cycle. It is used to surface any backend server timing metrics (e.g. database read/write, CPU time, file system access, etc.) in the developer tools in the user's browser or in the [PerformanceServerTiming](https://developer.mozilla.org/en-US/docs/domxref/PerformanceServerTiming) interface.\n   */\n  'Server-Timing' = 'Server-Timing',\n\n  /**\n   * The **`Server`** header describes the software used by the origin server that handled the request and generated a response.\n   *\n   * The benefits of advertising the server type and version via this header are that it helps with analytics and identifying how widespread specific interoperability issues are.\n   * Historically, clients have used the server version information to avoid known limitations, such as inconsistent support for [range requests](/en-US/docs/Web/HTTP/Range_requests) in specific software versions.\n   *\n   * > [!WARNING]\n   * > The presence of this header in responses, especially when it contains fine-grained implementation details about server software, may make known vulnerabilities easier to detect.\n   *\n   * Too much detail in the `Server` header is not advised for response latency and the security reason mentioned above.\n   * It's debatable whether obscuring the information in this header provides much benefit because fingerprinting server software is possible via other means.\n   * In general, a more robust approach to server security is to ensure software is regularly updated or patched against known vulnerabilities instead.\n   */\n  'Server' = 'Server',\n\n  /**\n   * The **`Service-Worker-Navigation-Preload`** request header indicates that the request was the result of a [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch) operation made during service worker navigation preloading.\n   * It allows a server to respond with a different resource than for a normal `fetch()`.\n   *\n   * If a different response may result from setting this header, the server must set `Vary: Service-Worker-Navigation-Preload` to ensure that the different responses are cached.\n   *\n   * For more information see [NavigationPreloadManager.setHeaderValue()](https://developer.mozilla.org/en-US/docs/domxref/NavigationPreloadManager.setHeaderValue()) (and [NavigationPreloadManager](https://developer.mozilla.org/en-US/docs/domxref/NavigationPreloadManager)).\n   */\n  'Service-Worker-Navigation-Preload' = 'Service-Worker-Navigation-Preload',\n\n  /**\n   * The **`Set-Cookie`** HTTP response header is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later.\n   * To send multiple cookies, multiple **`Set-Cookie`** headers should be sent in the same response.\n   *\n   * > [!WARNING]\n   * > Browsers block frontend JavaScript code from accessing the `Set-Cookie` header, as required by the Fetch spec, which defines `Set-Cookie` as a [forbidden response-header name](https://fetch.spec.whatwg.org/#forbidden-response-header-name) that [must be filtered out](https://fetch.spec.whatwg.org/#ref-for-forbidden-response-header-name%E2%91%A0) from any response exposed to frontend code.\n   * >\n   * > When a [Fetch API](/en-US/docs/Web/API/Fetch_API/Using_Fetch) or [XMLHttpRequest API](/en-US/docs/Web/API/XMLHttpRequest_API) request [uses CORS](/en-US/docs/Web/HTTP/CORS#what_requests_use_cors), browsers will ignore `Set-Cookie` headers present in the server's response unless the request includes credentials. Visit [Using the Fetch API - Including credentials](/en-US/docs/Web/API/Fetch_API/Using_Fetch#including_credentials) and the [XMLHttpRequest article](/en-US/docs/Web/API/XMLHttpRequest_API) to learn how to include credentials.\n   *\n   * For more information, see the guide on [Using HTTP cookies](/en-US/docs/Web/HTTP/Cookies).\n   */\n  'Set-Cookie' = 'Set-Cookie',\n\n  /**\n   * The **`Set-Login`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/Response_header) is sent by a federated identity provider (IdP) to set its login status — by this, we mean \"whether any users are logged into the IdP on the current browser or not\". This is stored by the browser and used by the [FedCM API](/en-US/docs/Web/API/FedCM_API) to reduce the number of requests it makes to the IdP (because it does not need to waste time requesting accounts when there are no users logged in to the IdP). It also mitigates [potential timing attacks](https://github.com/w3c-fedid/FedCM/issues/447).\n   *\n   * The header may be set on any response resulting from a top-level navigation or a same-origin subresource request on the IdP's origin site — basically, any interaction with the IdP site may result in this header being set, and the login status being stored by the browser.\n   *\n   * See [Update login status using the Login Status API](/en-US/docs/Web/API/FedCM_API/IDP_integration#update_login_status_using_the_login_status_api) for more information about FedCM login status.\n   */\n  'Set-Login' = 'Set-Login',\n\n  /**\n   * The **`SourceMap`** [HTTP](/en-US/docs/Web/HTTP) response header links generated code to a [source map](https://firefox-source-docs.mozilla.org/devtools-user/debugger/how_to/use_a_source_map/index.html), enabling the browser to reconstruct the original source and present the reconstructed original in the debugger.\n   */\n  'SourceMap' = 'SourceMap',\n\n  /**\n   * The **`Speculation-Rules`** response header provides one or more URLs pointing to text resources containing speculation rule JSON definitions. When the response is an HTML document, these rules will be added to the document's speculation rule set. See the [Speculation Rules API](/en-US/docs/Web/API/Speculation_Rules_API) for more information.\n   *\n   * The resource file containing the speculation rules JSON can have any valid name and extension, but it must be served with an `application/speculationrules+json` MIME type.\n   *\n   * > [!NOTE]\n   * > This mechanism provides an alternative to specifying the JSON definition inside an inline [`\n   */\n  'Speculation-Rules' = 'Speculation-Rules',\n\n  /**\n   * The HTTP **`Strict-Transport-Security`** response header (often abbreviated as [HSTS](https://developer.mozilla.org/en-US/docs/Glossary/HSTS)) informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS.\n   *\n   * > [!NOTE]\n   * > This is more secure than simply configuring a HTTP to HTTPS (301) redirect on your server, where the initial HTTP connection is still vulnerable to a man-in-the-middle attack.\n   */\n  'Strict-Transport-Security' = 'Strict-Transport-Security',\n\n  /**\n   * The **`Supports-Loading-Mode`** header allows a response to opt-in to being loaded in a novel, higher-risk context that it would otherwise fail to be loaded in.\n   */\n  'Supports-Loading-Mode' = 'Supports-Loading-Mode',\n\n  /**\n   * The **`TE`** request header specifies the transfer encodings\n   * the user agent is willing to accept. (you could informally call it\n   * `Accept-Transfer-Encoding`, which would be more intuitive).\n   *\n   * > [!NOTE]\n   * > In\n   * > [HTTP/2](https://httpwg.org/specs/rfc9113.html#ConnectionSpecific) and\n   * > [HTTP/3](https://httpwg.org/specs/rfc9114.html#header-formatting), the `TE`\n   * > header field is only accepted if the `trailers` value is set.\n   *\n   * See also the [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding) response header for more details on\n   * transfer encodings. Note that `chunked` is always acceptable for HTTP/1.1\n   * recipients and you don't have to specify `\"chunked\"` using the\n   * `TE` header. However, it is useful for setting if the client is accepting\n   * trailer fields in a chunked transfer coding using the \"trailers\" value.\n   */\n  'TE' = 'TE',\n\n  /**\n   * The **`Timing-Allow-Origin`** response header specifies origins that are allowed to see values of attributes retrieved via features of the [Resource Timing API](/en-US/docs/Web/API/Performance_API/Resource_timing), which would otherwise be reported as zero due to cross-origin restrictions.\n   */\n  'Timing-Allow-Origin' = 'Timing-Allow-Origin',\n\n  /**\n   * > [!NOTE]\n   * > The DNT (Do Not Track) specification has been discontinued. See [Navigator.doNotTrack](https://developer.mozilla.org/en-US/docs/domxref/Navigator.doNotTrack) for more information.\n   *\n   * The **`Tk`** response header indicates the tracking status that\n   * applied to the corresponding request.\n   */\n  'Tk' = 'Tk',\n\n  /**\n   * The **Trailer** response header allows the sender to include additional\n   * fields at the end of chunked messages in order to supply metadata that might be\n   * dynamically generated while the message body is sent, such as a message integrity check,\n   * digital signature, or post-processing status.\n   *\n   * > [!NOTE]\n   * > The [TE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/TE) request header needs to be set to \"trailers\" to allow\n   * > trailer fields.\n   */\n  'Trailer' = 'Trailer',\n\n  /**\n   * The **`Transfer-Encoding`** header specifies the form of encoding used to transfer messages between nodes on the network.\n   *\n   * > [!WARNING]\n   * > HTTP/2 disallows all uses of the Transfer-Encoding header other than the HTTP/2 specific: `\"trailers\"`.\n   * > HTTP/2 and later provides its own more efficient mechanisms for data streaming than chunked transfer and forbids the use of the header.\n   * > Usage of the header in HTTP/2 may likely result in a specific `protocol error` as HTTP/2 Protocol prohibits the use.\n   *\n   * `Transfer-Encoding` is a [hop-by-hop header](/en-US/docs/Web/HTTP/Headers#hop-by-hop_headers), that is applied to a message between two nodes, not to a resource itself.\n   * Each segment of a multi-node connection can use different `Transfer-Encoding` values.\n   * If you want to compress data over the whole connection, use the end-to-end [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) header instead.\n   *\n   * When present on a response to a [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) request that has no body, it indicates the value that would have applied to the corresponding [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) message.\n   */\n  'Transfer-Encoding' = 'Transfer-Encoding',\n\n  /**\n   * The HTTP **`Upgrade-Insecure-Requests`** request header sends a signal to the server expressing the client's preference for an encrypted and authenticated response, and that it can successfully handle the [upgrade-insecure-requests](https://developer.mozilla.org/en-US/docs/CSP/upgrade-insecure-requests) [CSP](/en-US/docs/Web/HTTP/CSP) directive.\n   */\n  'Upgrade-Insecure-Requests' = 'Upgrade-Insecure-Requests',\n\n  /**\n   * The HTTP 1.1 (only) `Upgrade` header can be used to upgrade an already established client/server connection to a different protocol (over the same transport protocol). For example, it can be used by a client to upgrade a connection from HTTP 1.1 to HTTP 2.0, or an HTTP or HTTPS connection into a WebSocket.\n   *\n   * > [!WARNING]\n   * > HTTP/2 explicitly disallows the use of this mechanism/header; it is specific to HTTP/1.1.\n   */\n  'Upgrade' = 'Upgrade',\n\n  /**\n   * The **User-Agent** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a characteristic string that lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting [user agent](https://developer.mozilla.org/en-US/docs/Glossary/user_agent).\n   *\n   * > [!WARNING]\n   * > Please read [Browser detection using the user agent](/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent) for why serving different Web pages or services to different browsers is usually a bad idea.\n   */\n  'User-Agent' = 'User-Agent',\n\n  /**\n   * The **`Vary`** HTTP response header describes the parts of the request message aside from the method and URL that influenced the content of the response it occurs in. Most often, this is used to create a cache key when [content negotiation](/en-US/docs/Web/HTTP/Content_negotiation) is in use.\n   *\n   * The same `Vary` header value should be used on all responses for a given URL, including [304](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304) `Not Modified` responses and the \"default\" response.\n   */\n  'Vary' = 'Vary',\n\n  /**\n   * The **`Via`** general header is added by proxies, both forward\n   * and reverse, and can appear in the request or response headers. It\n   * is used for tracking message forwards, avoiding request loops, and identifying the\n   * protocol capabilities of senders along the request/response chain.\n   */\n  'Via' = 'Via',\n\n  /**\n   * The **`Viewport-Width`** [device client hint](/en-US/docs/Web/HTTP/Client_hints) request header provides the client's layout viewport width in [CSS pixels](https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel). The value is rounded up to the smallest following integer (i.e. ceiling value).\n   *\n   *\n   *\n   * The hint can be used with other screen-specific hints to deliver images optimized for a specific screen size, or to omit resources that are not needed for a particular screen width.\n   *\n   * If the `Viewport-Width` header appears more than once in a message the last occurrence is used.\n   *\n   * > [!NOTE]\n   * >\n   * > - Client Hints are accessible only on secure origins (via TLS).\n   * > - A server has to opt in to receive the `Viewport-Width` header from the client, by sending the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header.\n   * > - Servers that opt in to the `Viewport-Width` client hint will typically also specify it in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header. This informs caches that the server may send different responses based on the header value in a request.\n   * > - `Viewport-Width` was removed from the original client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07). The proposed replacement is [`Sec-CH-Viewport-Width`](https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-width) (Responsive Image Client Hints).\n   */\n  'Viewport-Width' = 'Viewport-Width',\n\n  /**\n   * The **`Want-Content-Digest`** request or response header states the wish for a [Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Digest) header. It is the `Content-` analogue of [Want-Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Repr-Digest).\n   */\n  'Want-Content-Digest' = 'Want-Content-Digest',\n\n  /**\n   * > [!NOTE]\n   * > This header was removed from the specification in [draft 8](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-digest-headers-08).\n   * > Use [Want-Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Content-Digest) instead.\n   * > For `id-*` digest algorithms, use [Want-Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Repr-Digest).\n   *\n   * The **`Want-Digest`** request or response HTTP header requests the other side to provide a [digest](https://developer.mozilla.org/en-US/docs/Glossary/digest) using the [Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Digest) header.\n   *\n   * The header contains identifiers for one or more digest algorithms that the sender wishes the server to use to create the digest.\n   * The request may use [quality values](https://developer.mozilla.org/en-US/docs/Glossary/quality_values) to indicate its preference/order for particular digest algorithms.\n   *\n   * If `Want-Digest` does not include any digest algorithms that the server supports, the server may respond with:\n   *\n   * - a digest calculated using a different digest algorithm, or\n   * - a [`400 Bad Request`](/en-US/docs/Web/HTTP/Status/400) error, and include another `Want-Digest` header with that response, listing the algorithms that it does support.\n   *\n   * See also the [Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Digest) header.\n   */\n  'Want-Digest' = 'Want-Digest',\n\n  /**\n   * The **`Want-Repr-Digest`** request or response header states the wish for a [Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Repr-Digest) header.\n   */\n  'Want-Repr-Digest' = 'Want-Repr-Digest',\n\n  /**\n   * > [!NOTE]\n   * > The header was deprecated because it is not widely generated or surfaced to users (see [RFC9111](https://www.rfc-editor.org/rfc/rfc9111#field.warning)).\n   * > Some of the information can be inferred from other headers such as [Age](https://developer.mozilla.org/en-US/docs/httpheader/Age).\n   *\n   * The **`Warning`** HTTP header contains information about possible problems with the status of the message.\n   * More than one `Warning` header may appear in a response.\n   *\n   * `Warning` header fields can, in general, be applied to any message.\n   * However, some warn-codes are specific to caches and can only be applied to response messages.\n   */\n  'Warning' = 'Warning',\n\n  /**\n   * The **`Width`** [device client hint](/en-US/docs/Web/HTTP/Client_hints#device_client_hints) request header field indicates the desired resource width in physical pixels — the intrinsic size of an image. The provided pixel value is a number rounded to the smallest following integer (i.e. ceiling value).\n   *\n   *\n   *\n   * The hint is particularly useful because it allows the client to request a resource that is optimal for both the screen and the layout: taking into account both the density-corrected width of the screen and the image's extrinsic size within the layout.\n   *\n   * If the desired resource width is not known at the time of the request or the resource does not have a display width, the `Width` header field can be omitted.\n   *\n   * If the `Width` header appears more than once in a message the last occurrence is used.\n   *\n   * > [!NOTE]\n   * >\n   * > - Client Hints are accessible only on secure origins (via TLS).\n   * > - A server has to opt in to receive the `Width` header from the client, by sending the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header.\n   * > - Servers that opt in to the `Width` client hint will typically also specify it in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header. This informs caches that the server may send different responses based on the header value in a request.\n   * > - `Width` was removed from the client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07). The proposed replacement is [`Sec-CH-Width`](https://wicg.github.io/responsive-image-client-hints/#sec-ch-width) (Responsive Image Client Hints).\n   */\n  'Width' = 'Width',\n\n  /**\n   * The HTTP **`WWW-Authenticate`** response header defines the [HTTP authentication](/en-US/docs/Web/HTTP/Authentication) methods (\"challenges\") that might be used to gain access to a specific resource.\n   *\n   * > [!NOTE]\n   * > This header is part of the [General HTTP authentication framework](/en-US/docs/Web/HTTP/Authentication#the_general_http_authentication_framework), which can be used with a number of [authentication schemes](/en-US/docs/Web/HTTP/Authentication#authentication_schemes).\n   * > Each \"challenge\" lists a scheme supported by the server and additional parameters that are defined for that scheme type.\n   *\n   * A server using [HTTP authentication](/en-US/docs/Web/HTTP/Authentication) will respond with a [401](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401) `Unauthorized` response to a request for a protected resource.\n   * This response must include at least one `WWW-Authenticate` header and at least one [challenge](https://developer.mozilla.org/en-US/docs/Glossary/challenge), to indicate what authentication schemes can be used to access the resource (and any additional data that each particular scheme needs).\n   *\n   * Multiple challenges are allowed in one `WWW-Authenticate` header, and multiple `WWW-Authenticate` headers are allowed in one response.\n   * A server may also include the `WWW-Authenticate` header in other response messages to indicate that supplying credentials might affect the response.\n   *\n   * After receiving the `WWW-Authenticate` header, a client will typically prompt the user for credentials, and then re-request the resource.\n   * This new request uses the [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) header to supply the credentials to the server, encoded appropriately for the selected \"challenge\" authentication method.\n   * The client is expected to select the most secure of the challenges it understands (note that in some cases the \"most secure\" method is debatable).\n   */\n  'WWW-Authenticate' = 'WWW-Authenticate',\n\n  /**\n   * The **`X-Content-Type-Options`** response HTTP header is a\n   * marker used by the server to indicate that the [MIME types](/en-US/docs/Web/HTTP/MIME_types) advertised in the\n   * [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) headers should be followed and not be changed. The header allows you to avoid [MIME type sniffing](/en-US/docs/Web/HTTP/MIME_types#mime_sniffing) by saying that the MIME types are deliberately\n   * configured.\n   *\n   * This header was introduced by Microsoft in IE 8 as a way for webmasters to block\n   * content sniffing that was happening and could transform non-executable MIME types into\n   * executable MIME types. Since then, other browsers have introduced it, even if their MIME\n   * sniffing algorithms were less aggressive.\n   *\n   * Starting with Firefox 72, top-level\n   * documents also avoid MIME sniffing (if [Content-type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-type) is provided). This can cause HTML web pages\n   * to be downloaded instead of being rendered when they are served with a MIME type other\n   * than `text/html`. Make sure to set both headers correctly.\n   *\n   * Site security testers usually expect this header to be set.\n   *\n   * > **Note:** `X-Content-Type-Options` only apply request-blocking [due to `nosniff`](https://fetch.spec.whatwg.org/#ref-for-determine-nosniff) for [request destinations](/en-US/docs/Web/API/Request/destination) of `\"script\"` and `\"style\"`.\n   * > However, it also [enables Cross-Origin Read Blocking (CORB)](https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md#determining-whether-a-response-is-corb_protected) protection for HTML, TXT, JSON and XML files (excluding SVG `image/svg+xml`).\n   */\n  'X-Content-Type-Options' = 'X-Content-Type-Options',\n\n  /**\n   * The **`X-DNS-Prefetch-Control`** HTTP response header controls\n   * DNS prefetching, a feature by which browsers proactively perform domain name resolution\n   * on both links that the user may choose to follow as well as URLs for items referenced by\n   * the document, including images, CSS, JavaScript, and so forth.\n   *\n   * This prefetching is performed in the background, so that the [DNS](https://developer.mozilla.org/en-US/docs/glossary/DNS) is\n   * likely to have been resolved by the time the referenced items are needed. This reduces\n   * latency when the user clicks a link.\n   */\n  'X-DNS-Prefetch-Control' = 'X-DNS-Prefetch-Control',\n\n  /**\n   * The **`X-Forwarded-For`** (XFF) request header is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through a proxy server.\n   *\n   * > [!WARNING]\n   * > Improper use of this header can be a security risk. For details, see the [Security and privacy concerns](#security_and_privacy_concerns) section.\n   *\n   * When a client connects directly to a server, the\n   * client's IP address is sent to the server (and is often written to server\n   * access logs). But if a client connection passes through any [forward or reverse](https://en.wikipedia.org/wiki/Proxy_server) proxies, the server only\n   * sees the final proxy's IP address, which is often of little use. That's especially true if\n   * the final proxy is a load balancer which is part of the same installation\n   * as the server. So, to provide a more-useful client IP address to the server, the `X-Forwarded-For` request header is\n   * used.\n   *\n   * For detailed guidance on using this header, see the [Parsing](#parsing) and [Selecting an IP address](#selecting_an_ip_address) sections.\n   *\n   *\n   *\n   * A standardized version of this header is the HTTP [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded) header.\n   */\n  'X-Forwarded-For' = 'X-Forwarded-For',\n\n  /**\n   * The **`X-Forwarded-Host`** (XFH) header is a de-facto standard\n   * header for identifying the original host requested by the client in the\n   * [Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host) HTTP request header.\n   *\n   * Host names and ports of reverse proxies (load balancers, CDNs) may differ from the\n   * origin server handling the request, in that case the `X-Forwarded-Host`\n   * header is useful to determine which Host was originally used.\n   */\n  'X-Forwarded-Host' = 'X-Forwarded-Host',\n\n  /**\n   * The **`X-Forwarded-Proto`** (XFP) header is a de-facto standard\n   * header for identifying the protocol (HTTP or HTTPS) that a client used to connect to\n   * your proxy or load balancer. Your server access logs contain the protocol used between\n   * the server and the load balancer, but not the protocol used between the client and the\n   * load balancer. To determine the protocol used between the client and the load balancer,\n   * the `X-Forwarded-Proto` request header can be used.\n   *\n   * A standardized version of this header is the HTTP [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded) header.\n   */\n  'X-Forwarded-Proto' = 'X-Forwarded-Proto',\n\n  /**\n   * > [!WARNING]\n   * > Instead of this header, use the [frame-ancestors](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) directive in a [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) header.\n   *\n   * The **`X-Frame-Options`** [HTTP](/en-US/docs/Web/HTTP) response header can be used to indicate whether a browser should be allowed to render a page in a [frame](https://developer.mozilla.org/en-US/docs/HTMLElement/frame), [iframe](https://developer.mozilla.org/en-US/docs/HTMLElement/iframe), [embed](https://developer.mozilla.org/en-US/docs/HTMLElement/embed) or [object](https://developer.mozilla.org/en-US/docs/HTMLElement/object). Sites can use this to avoid [click-jacking](/en-US/docs/Web/Security/Types_of_attacks#click-jacking) attacks, by ensuring that their content is not embedded into other sites.\n   *\n   * The added security is provided only if the user accessing the document is using a browser that supports `X-Frame-Options`.\n   */\n  'X-Frame-Options' = 'X-Frame-Options',\n\n  /**\n   * The HTTP **`X-XSS-Protection`** response header was a feature of Internet Explorer, Chrome and Safari that stopped pages from loading when they detected reflected cross-site scripting ([XSS](https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting)) attacks. These protections are largely unnecessary in modern browsers when sites implement a strong [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) that disables the use of inline JavaScript (`'unsafe-inline'`).\n   *\n   * > [!WARNING]\n   * > Even though this feature can protect users of older web browsers that don't yet support [CSP](https://developer.mozilla.org/en-US/docs/Glossary/CSP), in some cases, **XSS protection can create XSS vulnerabilities** in otherwise safe websites. See the section below for more information.\n   *\n   * > [!NOTE]\n   * >\n   * > - Chrome has [removed their XSS Auditor](https://chromestatus.com/feature/5021976655560704)\n   * > - Firefox has not, and [will not implement `X-XSS-Protection`](https://bugzil.la/528661)\n   * > - Edge has [retired their XSS filter](https://blogs.windows.com/windows-insider/2018/07/25/announcing-windows-10-insider-preview-build-17723-and-build-18204/)\n   * >\n   * > This means that if you do not need to support legacy browsers, it is recommended that you use [`Content-Security-Policy`](/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) without allowing `unsafe-inline` scripts instead.\n   */\n  'X-XSS-Protection' = 'X-XSS-Protection',\n}\n"],"names":["HttpHeader"],"mappings":"AACY,IAAA,+BAAAA,iBAMVA,YAAA,eAAc,aAYdA,YAAA,gBAAmB,IAAA,kBAoBnBA,YAAA,iBAAA,IAAoB,mBAqBpBA,YAAA,iBAAA,IAAoB,mBAapBA,YAAA,cAAiB,IAAA,gBAajBA,YAAA,aAAgB,IAAA,eAQhBA,YAAA,eAAA,IAAkB,iBAYlBA,YAAA,SAAW,UAoBXA,YAAA,kCAAqC,IAAA,oCASrCA,YAAA,8BAAA,IAAiC,gCAKjCA,YAAA,8BAAA,IAAiC,gCAKjCA,YAAA,6BAAgC,IAAA,+BAOhCA,YAAA,+BAAkC,IAAA,iCAKlCA,YAAA,wBAAA,IAA2B,0BAK3BA,YAAA,oCAAmC,kCAMnCA,YAAA,+BAAkC,IAAA,iCAQlCA,YAAA,MAAQ,OAORA,YAAA,QAAU,SAOVA,YAAA,SAAA,IAAY,WASZA,YAAA,UAAA,IAAa,YASbA,YAAA,gCAAmC,IAAA,kCAUnCA,YAAA,uCAA0C,IAAA,yCAU1CA,YAAA,wCAAA,IAA2C,0CAgB3CA,YAAA,gBAAkB,iBAKlBA,YAAA,eAAkB,IAAA,iBAMlBA,YAAA,iBAAA,IAAoB,mBAwBpBA,YAAA,aAAe,cAWfA,YAAA,gBAAmB,IAAA,kBASnBA,YAAA,qBAAwB,IAAA,uBAcxBA,YAAA,aAAA,IAAgB,eAchBA,YAAA,sBAAqB,oBAarBA,YAAA,kBAAqB,IAAA,oBAKrBA,YAAA,gBAAA,IAAmB,kBAUnBA,YAAA,kBAAA,IAAqB,oBAKrBA,YAAA,eAAkB,IAAA,iBAgBlBA,YAAA,qCAAwC,IAAA,uCAWxCA,YAAA,yBAA4B,IAAA,2BAqB5BA,YAAA,cAAiB,IAAA,gBAOjBA,YAAA,SAAW,UASXA,YAAA,iBAAgB,eAKhBA,YAAA,8BAAiC,IAAA,gCAajCA,YAAA,4BAAA,IAA+B,8BAK/BA,YAAA,8BAAA,IAAiC,gCAkBjCA,YAAA,OAAS,QAaTA,YAAA,eAAkB,IAAA,iBAmBlBA,YAAA,SAAW,UAYXA,YAAA,MAAQ,OAcRA,YAAA,WAAa,YAoBbA,YAAA,MAAQ,OAURA,YAAA,YAAA,IAAe,cAcfA,YAAA,MAAQ,OAaRA,YAAA,OAAS,QAsBTA,YAAA,WAAA,IAAc,aAqBdA,YAAA,SAAW,UAcXA,YAAA,UAAY,WAcZA,YAAA,YAAc,aAadA,YAAA,OAAS,QAaTA,YAAA,OAAS,QAkBTA,YAAA,UAAa,IAAA,YAkBbA,YAAA,mBAAA,IAAsB,qBAgBtBA,YAAA,mBAAkB,iBAelBA,YAAA,UAAa,IAAA,YAYbA,YAAA,qBAAA,IAAwB,uBAgBxBA,YAAA,YAAA,IAAe,cASfA,YAAA,eAAkB,IAAA,iBAYlBA,YAAA,OAAS,QAoBTA,YAAA,WAAa,YAWbA,YAAA,kBAAiB,gBAKjBA,YAAA,MAAQ,OAURA,YAAA,gBAAA,IAAmB,kBAWnBA,YAAA,yBAAA,IAA4B,2BAmC5BA,YAAA,sBAAyB,IAAA,wBAMzBA,YAAA,SAAW,UAOXA,YAAA,oBAAuB,IAAA,sBAUvBA,YAAA,SAAW,UAmBXA,YAAA,WAAa,YAMbA,YAAA,wBAAuB,sBAKvBA,YAAA,qBAAwB,IAAA,uBAgBxBA,YAAA,QAAU,SAqBVA,YAAA,UAAY,WAMZA,YAAA,iBAAoB,IAAA,mBAMpBA,YAAA,UAAY,WAYZA,YAAA,WAAA,IAAc,aAadA,YAAA,yBAAwB,uBAKxBA,YAAA,aAAgB,IAAA,eAehBA,YAAA,aAAA,IAAgB,eAchBA,YAAA,MAAQ,OAoBRA,YAAA,WAAc,IAAA,aAedA,YAAA,qBAAwB,IAAA,uBASxBA,YAAA,6BAAA,IAAgC,+BAShCA,YAAA,mCAAkC,iCASlCA,YAAA,yCAAwC,uCAOxCA,YAAA,oBAAmB,kBAQnBA,YAAA,mBAAsB,IAAA,qBAqBtBA,YAAA,6BAAA,IAAgC,+BAQhCA,YAAA,wBAAA,IAA2B,0BAS3BA,YAAA,kBAAqB,IAAA,oBAKrBA,YAAA,iBAAoB,IAAA,mBAKpBA,YAAA,4BAAA,IAA+B,8BAS/BA,YAAA,wBAAuB,sBA0BvBA,YAAA,WAAc,IAAA,aAOdA,YAAA,gBAAA,IAAmB,kBAOnBA,YAAA,gBAAA,IAAmB,kBASnBA,YAAA,gBAAmB,IAAA,kBAOnBA,YAAA,gBAAmB,IAAA,kBAQnBA,YAAA,SAAA,IAAY,WAUZA,YAAA,iBAAgB,eAOhBA,YAAA,sBAAyB,IAAA,wBAazBA,YAAA,0BAAA,IAA6B,4BAa7BA,YAAA,mBAAA,IAAsB,qBAetBA,YAAA,wBAAA,IAA2B,0BAgB3BA,YAAA,uBAAA,IAA0B,yBAK1BA,YAAA,eAAkB,IAAA,iBAelBA,YAAA,SAAW,UAUXA,YAAA,mCAAA,IAAsC,qCAatCA,YAAA,gBAAe,cASfA,YAAA,WAAc,IAAA,aAKdA,YAAA,YAAc,aAUdA,YAAA,mBAAA,IAAsB,qBAQtBA,YAAA,2BAA8B,IAAA,6BAK9BA,YAAA,uBAA0B,IAAA,yBAmB1BA,YAAA,KAAO,MAKPA,YAAA,yBAAwB,uBASxBA,YAAA,KAAO,MAYPA,YAAA,UAAY,WAgBZA,YAAA,mBAAA,IAAsB,qBAKtBA,YAAA,2BAA8B,IAAA,6BAQ9BA,YAAA,UAAY,WAQZA,YAAA,YAAA,IAAe,cAOfA,YAAA,OAAS,QAQTA,YAAA,MAAQ,OAkBRA,YAAA,gBAAA,IAAmB,kBAKnBA,YAAA,qBAAA,IAAwB,uBAoBxBA,YAAA,aAAgB,IAAA,eAKhBA,YAAA,kBAAqB,IAAA,oBAarBA,YAAA,UAAY,WAoBZA,YAAA,QAAU,SAmBVA,YAAA,kBAAqB,IAAA,oBAuBrBA,YAAA,wBAAA,IAA2B,0BAY3BA,YAAA,wBAAA,IAA2B,0BAsB3BA,YAAA,iBAAoB,IAAA,mBAWpBA,YAAA,kBAAqB,IAAA,oBAYrBA,YAAA,mBAAA,IAAsB,qBAUtBA,YAAA,qBAAoB,mBAgBpBA,YAAA,kBAAqB,IAAA,oBApqDXA,cAAA,cAAA,CAAA,CAAA;"}
+{"version":3,"file":"HttpHeaders.js","sources":["../HttpHeaders.ts"],"sourcesContent":["/* eslint-disable unicorn/prevent-abbreviations */\n/* eslint-disable jsdoc/check-indentation */\nexport enum HttpHeader {\n\n  /**\n   * The HTTP **`Accept-CH`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) may be set by a server to specify which [client hint](/en-US/docs/Web/HTTP/Guides/Client_hints) headers should be included by the client in subsequent requests.\n   * To ensure client hints are sent reliably, the `Accept-CH` header should be persisted for all secure requests.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Accept-CH: <client-hints-headers>\n   *\n   * // Client hint headers in a comma-separated list\n   * Accept-CH: <ch-header-one>, <ch-header-two>\n   * ```\n   *\n   * ## Examples\n   *\n   * ### Client hint response headers\n   *\n   * The following response headers indicate that the server accepts `Viewport-Width` and `Width` [device client hints](/en-US/docs/Web/HTTP/Guides/Client_hints#device_client_hints) in subsequent requests.\n   * The [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header indicates which values were used to [vary the response](/en-US/docs/Web/HTTP/Guides/Client_hints#caching_and_client_hints) based on the accepted client hints.\n   *\n   * ```http\n   * Accept-CH: Viewport-Width, Width\n   * Vary: Viewport-Width, Width\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   */\n  'Accept-CH' = 'Accept-CH',\n\n  /**\n   * The HTTP **`Accept-Encoding`** [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) indicates the content encoding (usually a compression algorithm) that the sender can understand.\n   * In requests, the server uses [content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation) to select one of the encoding proposals from the client and informs the client of that choice with the [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) response header.\n   * In responses, it provides information about which content encodings the server can understand in messages to the requested resource, so that the encoding can be used in subsequent requests to the resource.\n   * For example, `Accept-Encoding` is included in a [415 Unsupported Media Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415) response if a request to a resource (e.g., [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT)) used an unsupported encoding.\n   *\n   * Even if both the client and the server support the same compression algorithms, the server may choose not to compress the body of a response if the `identity` value is also acceptable.\n   * This happens in two common cases:\n   *\n   * 1. The data is already compressed, meaning a second round of compression will not reduce the transmitted data size, and may actually increase the size of the content in some cases.\n   *    This is true for pre-compressed image formats (JPEG, for instance).\n   * 2. The server is overloaded and cannot allocate computing resources to perform the compression. For example, Microsoft recommends not to compress if a server uses more than 80% of its computational power.\n   *\n   * As long as the `identity;q=0` or `*;q=0` directives do not explicitly forbid the `identity` value that means no encoding, the server must never return a [406 Not Acceptable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406) error.\n   *\n   * > [!NOTE]\n   * > IANA maintains [a list of official content encodings](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding).\n   * > The `bzip` and `bzip2` encodings are non-standard, but may be used in some cases, particularly for legacy support.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Accept-Encoding: gzip\n   * Accept-Encoding: compress\n   * Accept-Encoding: deflate\n   * Accept-Encoding: br\n   * Accept-Encoding: zstd\n   * Accept-Encoding: dcb\n   * Accept-Encoding: dcz\n   * Accept-Encoding: identity\n   * Accept-Encoding: *\n   *\n   * // Multiple algorithms, weighted with the quality value syntax:\n   * Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5\n   * ```\n   *\n   * ## Directives\n   *\n   * - `gzip`\n   *   - : A compression format that uses the [Lempel-Ziv coding](https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) (LZ77) with a 32-bit CRC.\n   * - `compress`\n   *   - : A compression format that uses the [Lempel-Ziv-Welch](https://en.wikipedia.org/wiki/LZW) (LZW) algorithm.\n   * - `deflate`\n   *   - : A compression format that uses the [zlib](https://en.wikipedia.org/wiki/Zlib) structure with the [_deflate_](https://en.wikipedia.org/wiki/DEFLATE) compression algorithm.\n   * - `br`\n   *   - : A compression format that uses the [Brotli](https://en.wikipedia.org/wiki/Brotli) algorithm.\n   * - `zstd`\n   *   - : A compression format that uses the [Zstandard](https://en.wikipedia.org/wiki/Zstd) algorithm.\n   * - `dcb`\n   *   - : A format that uses the [Dictionary-Compressed Brotli](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-compression-dictionary#name-dictionary-compressed-brotl) algorithm. See [Compression Dictionary Transport](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport).\n   * - `dcz`\n   *   - : A format that uses the [Dictionary-Compressed Zstandard](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-compression-dictionary#name-dictionary-compressed-zstan) algorithm. See [Compression Dictionary Transport](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport).\n   * - `identity`\n   *   - : Indicates the identity function (that is, without modification or compression). This value is always considered as acceptable, even if omitted.\n   * - `*` (wildcard)\n   *   - : Matches any content encoding not already listed in the header. This is the default value if the header is not present. This directive does not suggest that any algorithm is supported but indicates that no preference is expressed.\n   * - `;q=` (qvalues weighting)\n   *   - : Any value is placed in an order of preference expressed using a relative [quality value](/en-US/docs/Glossary/Quality_values) called _weight_.\n   *\n   * ## Examples\n   *\n   * ### Default Accept-Encoding values\n   *\n   * Browser navigation typically has the following `Accept-Encoding` request header value:\n   *\n   * ```http\n   * GET /en-US/ HTTP/2\n   * Host: developer.mozilla.org\n   * Accept-Encoding: gzip, deflate, br, zstd\n   * ```\n   *\n   * ### Weighted Accept-Encoding values\n   *\n   * The following header shows `Accept-Encoding` preferences using a quality value between `0` (lowest priority) and `1` (highest-priority).\n   * Brotli compression is weighted at `1.0`, making `br` the client's first choice, followed by `gzip` at `0.8` priority, and then any other content encoding at `0.1`:\n   *\n   * ```http\n   * Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [415 Unsupported Media Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415)\n   * - HTTP [content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation)\n   * - A header with the result of the content negotiation: [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding)\n   * - Other similar headers: [TE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/TE), [Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept), [Accept-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language)\n   * - [Brotli compression](https://developer.mozilla.org/en-US/docs/Glossary/Brotli_compression)\n   * - [GZip compression](https://developer.mozilla.org/en-US/docs/Glossary/GZip_compression)\n   * - [Zstandard compression](https://developer.mozilla.org/en-US/docs/Glossary/Zstandard_compression)\n   * - [Compression Dictionary Transport guide](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport)\n   */\n  'Accept-Encoding' = 'Accept-Encoding',\n\n  /**\n   * The HTTP **`Accept-Language`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates the natural language and locale that the client prefers.\n   * The server uses [content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation) to select one of the proposals and informs the client of the choice with the [Content-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Language) response header.\n   * Browsers set required values for this header according to their active user interface language.\n   * Users can also configure additional preferred languages through browser settings.\n   *\n   * The `Accept-Language` header generally lists the same locales as the [navigator.languages](https://developer.mozilla.org/en-US/docs/domxref/navigator.languages) property, with decreasing `q` values ([quality values](/en-US/docs/Glossary/Quality_values)). Some browsers, like Chrome and Safari, add language-only fallback tags in `Accept-Language`. For example, `en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7` when `navigator.languages` is `[\"en-US\", \"zh-CN\"]`. For privacy purposes (reducing [fingerprinting](https://developer.mozilla.org/en-US/docs/Glossary/fingerprinting)), both `Accept-Language` and `navigator.languages` may not include the full list of user preferences. For example, in Safari (always) and Chrome's incognito mode, only one language is listed.\n   *\n   * This header serves as a hint when the server cannot determine the target content language otherwise (for example, use a specific URL that depends on an explicit user decision).\n   * The server should never override an explicit user language choice. The content of `Accept-Language` is often out of a user's control (when traveling, for instance).\n   * A user may also want to visit a page in a language different from the user interface language.\n   *\n   * The server may send back a [406 Not Acceptable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406) error code when unable to serve content in a matching language, but this is rarely implemented.\n   * Servers often ignore the `Accept-Language` header in such cases and send a successful response with the most appropriate resource instead for a better user experience.\n   *\n   *\n   *\n   * \\* Values can only be `0-9`, `A-Z`, `a-z`, space, or the characters `*,-.;=`.\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Accept-Language: <language>\n   * Accept-Language: *\n   *\n   * // Multiple types, weighted with the quality value syntax:\n   * Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<language>`\n   *   - : A language tag (which is sometimes referred to as a \"locale identifier\").\n   *     This consists of a 2-3 letter base language tag that indicates a language, optionally followed by additional subtags separated by `-`.\n   *     The most common extra information is the country or region variant (like `en-US` or `fr-CA`) or the type of alphabet to use (like `sr-Latn`).\n   *     Other variants, like the type of orthography (`de-DE-1996`), are usually not used in the context of this header.\n   * - `*` (wildcard)\n   *   - : Any language not matched by any other language present in the `Accept-Language` field.\n   * - `;q=` (q-factor weighting)\n   *   - : Any value placed in an order of preference expressed using a relative [quality value](https://developer.mozilla.org/en-US/docs/Glossary/Quality_values) called _weight_.\n   *     The quality value defaults to `1`.\n   *\n   * ## Examples\n   *\n   * ### Using Accept-Language headers\n   *\n   * The following request has a preference for German using the `de` base language:\n   *\n   * ```http\n   * Accept-Language: de\n   * ```\n   *\n   * ### Using quality values in Accept-Language\n   *\n   * The following request indicates a stronger preference for Danish, but accepts British English and other types of English at a lower priority:\n   *\n   * ```http\n   * Accept-Language: da, en-gb;q=0.8, en;q=0.7\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - HTTP [content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation)\n   * - A header with the result of the content negotiation: [Content-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Language)\n   * - Other similar headers: [TE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/TE), [Accept-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding), [Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept)\n   */\n  'Accept-Language' = 'Accept-Language',\n\n  /**\n   * The HTTP **`Accept-Patch`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) advertises which [media types](/en-US/docs/Web/HTTP/Guides/MIME_types) the server is able to understand in a [PATCH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PATCH) request.\n   * For example, a server receiving a `PATCH` request with an unsupported media type could reply with [415 Unsupported Media Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415) and an `Accept-Patch` header referencing one or more supported media types.\n   *\n   * The header should appear in [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS) requests to a resource that supports the `PATCH` method.\n   * An `Accept-Patch` header in a response to any request method implicitly means that a `PATCH` is allowed on the target resource in the request.\n   *\n   * > [!NOTE]\n   * > IANA maintains [a list of official content encodings](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding).\n   * > The `bzip` and `bzip2` encodings are non-standard but may be used in some cases, particularly for legacy support.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Accept-Patch: <media-type>/<subtype>\n   * Accept-Patch: <media-type>/*\n   * Accept-Patch: * /*\n   *\n   * // Comma-separated list of media types\n   * Accept-Patch: <media-type>/<subtype>, <media-type>/<subtype>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<media-type>/<subtype>`\n   *   - : A single, precise [media type](/en-US/docs/Web/HTTP/Guides/MIME_types), like `text/html`.\n   * - `<media-type>/*`\n   *   - : A media type without a subtype.\n   *     For example, `image/*` corresponds to `image/png`, `image/svg`, `image/gif`, and other image types.\n   * - `* /*`\n   *   - : Any media type.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Accept-Patch: application/json\n   * Accept-Patch: application/json, text/plain\n   * Accept-Patch: text/plain;charset=utf-8\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * Browser compatibility is not relevant for this header.\n   * The server sends the header, and the specification doesn't define client behavior.\n   *\n   * ## See also\n   *\n   * - [Accept-Post](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Post)\n   * - [415 Unsupported Media Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415)\n   * - [PATCH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PATCH) request method\n   */\n  'Accept-Patch' = 'Accept-Patch',\n\n  /**\n   * The HTTP **`Accept-Post`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) advertises which [media types](/en-US/docs/Web/HTTP/Guides/MIME_types) are accepted by the server in a [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) request.\n   * For example, a server receiving a `POST` request with an unsupported media type could reply with [415 Unsupported Media Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415) and an `Accept-Post` header referencing one or more supported media types.\n   *\n   * The header should appear in [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS) requests to a resource that supports the `POST` method.\n   * An `Accept-Post` header in a response to any request method implicitly means that a `POST` is allowed on the target resource in the request.\n   *\n   * > [!NOTE]\n   * > IANA maintains [a list of official content encodings](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding).\n   * > The `bzip` and `bzip2` encodings are non-standard but may be used in some cases, particularly for legacy support.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Accept-Post: <media-type>/<subtype>\n   * Accept-Post: <media-type>/*\n   * Accept-Post: * /*\n   *\n   * // Comma-separated list of media types\n   * Accept-Post: <media-type>/<subtype>, <media-type>/<subtype>\n   * ```\n   *\n   * > [!NOTE]\n   * > The `Accept-Post` header specifies a media range in the same way as [Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept), except that it has no notion of preference via `q` ([quality values](https://developer.mozilla.org/en-US/docs/Glossary/quality_values)) arguments.\n   * > This is because `Accept-Post` is a response header while `Accept` is a request header.\n   *\n   * ## Directives\n   *\n   * - `<media-type>/<subtype>`\n   *   - : A single, precise [media type](/en-US/docs/Web/HTTP/Guides/MIME_types), like `text/html`.\n   * - `<media-type>/*`\n   *   - : A media type without a subtype.\n   *     For example, `image/*` corresponds to `image/png`, `image/svg`, `image/gif`, and other image types.\n   * - `* /*`\n   *   - : Any media type.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Accept-Post: application/json, text/plain\n   * Accept-Post: image/webp\n   * Accept-Post: * /*\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * Browser compatibility is not relevant for this header.\n   * The header is sent by the server and the specification does not define client behavior.\n   *\n   * ## See also\n   *\n   * - [Accept-Patch](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Patch)\n   * - [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) request method\n   */\n  'Accept-Post' = 'Accept-Post',\n\n  /**\n   * The HTTP **`Accept-Ranges`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used by the server to advertise its support for [range requests](/en-US/docs/Web/HTTP/Guides/Range_requests), allowing clients to request part or several parts of a resource.\n   * The value of this header indicates the unit that can be used to define a range.\n   *\n   * For example, a response with an `Accept-Ranges` header indicates that the server is capable of _resuming_ an interrupted download instead of a client restarting the transfer in full.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Accept-Ranges: <range-unit>\n   * Accept-Ranges: none\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<range-unit>`\n   *   - : The range unit that the server supports, although `bytes` is the only range unit formally defined by [7233](https://developer.mozilla.org/en-US/docs/RFC/7233).\n   *     Range units are registered in the [HTTP Range Unit Registry](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#range-units).\n   * - `none`\n   *   - : No range unit is supported.\n   *     This is equivalent to omitting the header and is, therefore, rarely used.\n   *     This value was used in legacy browsers to disable or remove the pause buttons in the download manager if servers had no support for range requests.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Accept-Ranges: bytes\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTTP range requests](/en-US/docs/Web/HTTP/Guides/Range_requests) guide\n   * - [HTTP conditional requests](/en-US/docs/Web/HTTP/Guides/Conditional_requests) guide\n   * - [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range), [If-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Range) request headers\n   * - [IANA HTTP Range Unit Registry](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#range-units)\n   */\n  'Accept-Ranges' = 'Accept-Ranges',\n\n  /**\n   * The HTTP **`Accept`** [request](https://developer.mozilla.org/en-US/docs/Glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates which content types, expressed as [MIME types](/en-US/docs/Web/HTTP/Guides/MIME_types), the sender is able to understand.\n   * In requests, the server uses [content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation) to select one of the proposals and informs the client of the choice with the [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) response header.\n   * In responses, it provides information about which content types the server can understand in messages to the requested resource, so that the content type can be used in subsequent requests to the resource.\n   *\n   * Browsers set required values for this header based on the context of the request.\n   * For example, a browser uses different values in a request when fetching a CSS stylesheet, image, video, or a script.\n   *\n   *\n   *\n   * \\* Values can't contain [CORS-unsafe request header bytes](https://fetch.spec.whatwg.org/#cors-unsafe-request-header-byte), including `\"():<>?@[\\]{},`, Delete `0x7F`, and control characters `0x00` to `0x19`, except for Tab `0x09`.\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Accept: <media-type>/<MIME_subtype>\n   * Accept: <media-type>/*\n   * Accept: * /*\n   *\n   * // Multiple types, weighted with the quality value syntax\n   * Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, * /*;q=0.8\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<media-type>/<subtype>`\n   *   - : A single, precise [media type](/en-US/docs/Web/HTTP/Guides/MIME_types), like `text/html`.\n   * - `<media-type>/*`\n   *   - : A media type without a subtype.\n   *     For example, `image/*` corresponds to `image/png`, `image/svg`, `image/gif`, and other image types.\n   * - `* /*`\n   *   - : Any media type.\n   * - `;q=` (q-factor weighting)\n   *   - : A value in order of preference expressed using a relative [quality value](https://developer.mozilla.org/en-US/docs/Glossary/quality_values) called the _weight_.\n   *\n   * ## Examples\n   *\n   * ### Using default Accept request headers\n   *\n   * HTTP requests made using command line tools such as [curl](https://curl.se/) and [wget](https://www.gnu.org/software/wget/) use `* /*` as the default `Accept` value:\n   *\n   * ```http\n   * GET / HTTP/1.1\n   * Host: example.com\n   * User-Agent: curl/8.7.1\n   * Accept: * /*\n   * ```\n   *\n   * Browser navigation typically has the following `Accept` request header value:\n   *\n   * ```http\n   * GET /en-US/ HTTP/2\n   * Host: developer.mozilla.org\n   * Accept: text/html,application/xhtml+xml,application/xml;q=0.9,* /*;q=0.8\n   * …\n   * ```\n   *\n   * After receiving the document, the default `Accept` values in requests for images on the `developer.mozilla.org` example look like this:\n   *\n   * ```http\n   * Accept: image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,* /*;q=0.5\n   * ```\n   *\n   * ### Configuring Accept request headers for JSON responses\n   *\n   * Systems that involve API interaction commonly request `application/json` responses.\n   * Here's an example of a [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) request where the client specifically requests a JSON response:\n   *\n   * ```http\n   * GET /users/123 HTTP/1.1\n   * Host: example.com\n   * Authorization: Bearer abcd123\n   * Accept: application/json\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - HTTP [content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation)\n   * - [List of default Accept values](/en-US/docs/Web/HTTP/Guides/Content_negotiation/List_of_default_Accept_values)\n   * - [CORS safelist request header restrictions](/en-US/docs/Glossary/CORS-safelisted_request_header#additional_restrictions)\n   * - A header with the result of the content negotiation: [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type)\n   * - Other similar headers: [TE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/TE), [Accept-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding), [Accept-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language)\n   */\n  'Accept' = 'Accept',\n\n  /**\n   * The HTTP **`Access-Control-Allow-Credentials`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) tells browsers whether the server allows credentials to be included in cross-origin HTTP requests.\n   *\n   * Credentials include cookies, [Transport Layer Security (TLS)](https://developer.mozilla.org/en-US/docs/glossary/TLS) client certificates, or authentication headers containing a username and password.\n   * By default, these credentials are not sent in cross-origin requests, and doing so can make a site vulnerable to [Cross-Site Request Forgery (CSRF)](https://developer.mozilla.org/en-US/docs/Glossary/CSRF) attacks.\n   *\n   * A client can ask for credentials to be included in cross-site requests in several ways:\n   *\n   * - Using [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch), by setting the [`credentials`](/en-US/docs/Web/API/RequestInit#credentials) option to `\"include\"`.\n   * - Using [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest), by setting the [XMLHttpRequest.withCredentials](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest.withCredentials) property to `true`.\n   * - Using [EventSource()](https://developer.mozilla.org/en-US/docs/domxref/EventSource()), by setting the [EventSource.withCredentials](https://developer.mozilla.org/en-US/docs/domxref/EventSource.withCredentials) property to `true`.\n   *\n   * When credentials are included:\n   *\n   * - For [preflighted](https://developer.mozilla.org/en-US/docs/glossary/Preflight_request) requests: The preflight request does not include credentials.\n   *   If the server's response to the preflight request sets the `Access-Control-Allow-Credentials` header to `true`, then the real request will include credentials; otherwise, the browser reports a network error.\n   * - For non-preflighted requests: The request will include credentials, and if the server's response does not set the `Access-Control-Allow-Credentials` header to `true`, the browser reports a network error.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Access-Control-Allow-Credentials: true\n   * ```\n   *\n   * ## Directives\n   *\n   * - `true`\n   *   - : The server allows credentials to be included in cross-origin HTTP requests.\n   *     This is the only valid value for this header and is case-sensitive.\n   *     If you don't need credentials, omit this header entirely rather than setting its value to `false`.\n   *\n   * ## Examples\n   *\n   * Allow credentials:\n   *\n   * ```http\n   * Access-Control-Allow-Credentials: true\n   * ```\n   *\n   * Using [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch) with credentials:\n   *\n   * ```js\n   * fetch(url, {\n   *   credentials: \"include\",\n   * });\n   * ```\n   *\n   * Using [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest) with credentials:\n   *\n   * ```js\n   * const xhr = new XMLHttpRequest();\n   * xhr.open(\"GET\", \"http://example.com/\", true);\n   * xhr.withCredentials = true;\n   * xhr.send(null);\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [XMLHttpRequest.withCredentials](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest.withCredentials)\n   * - [Request()](https://developer.mozilla.org/en-US/docs/domxref/Request.Request())\n   */\n  'Access-Control-Allow-Credentials' = 'Access-Control-Allow-Credentials',\n\n  /**\n   * The HTTP **`Access-Control-Allow-Headers`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used in response to a [preflight request](https://developer.mozilla.org/en-US/docs/Glossary/preflight_request) to indicate the HTTP headers that can be used during the actual request.\n   * This header is required if the preflight request contains [Access-Control-Request-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Headers).\n   *\n   * > [!NOTE]\n   * > The [CORS-safelisted request headers](https://developer.mozilla.org/en-US/docs/glossary/CORS-safelisted_request_header) are always allowed and usually aren't listed in `Access-Control-Allow-Headers` unless there is a need to circumvent the [additional safelist restrictions](/en-US/docs/Glossary/CORS-safelisted_request_header#additional_restrictions).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Access-Control-Allow-Headers: <header-name>\n   * Access-Control-Allow-Headers: <header-name>, <header-name>\n   * Access-Control-Allow-Headers: *\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<header-name>`\n   *   - : The name of a supported request header. The header may list any number of headers, separated by commas.\n   * - `*` (wildcard)\n   *   - : Any header.\n   *     The value `*` only counts as a special wildcard value for requests without credentials (requests without [HTTP cookies](/en-US/docs/Web/HTTP/Guides/Cookies) or HTTP authentication information).\n   *     In requests with credentials, it is treated as the literal header name `*` without special semantics.\n   *     The [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) header doesn't accept wildcard and always needs to be listed explicitly.\n   *\n   * ## Examples\n   *\n   * ### Implementing a custom header\n   *\n   * Below is an example of an `Access-Control-Allow-Headers` header.\n   * It indicates that a custom header named `X-Custom-Header` is supported by CORS requests to the server, in addition to the [CORS-safelisted request headers](https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_request_header).\n   *\n   * ```http\n   * Access-Control-Allow-Headers: X-Custom-Header\n   * ```\n   *\n   * ### Supporting multiple headers\n   *\n   * This example shows `Access-Control-Allow-Headers` when it specifies support for multiple headers.\n   *\n   * ```http\n   * Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests\n   * ```\n   *\n   * ### Bypassing additional restrictions on CORS-safelisted headers\n   *\n   * Although [CORS-safelisted request headers](https://developer.mozilla.org/en-US/docs/glossary/CORS-safelisted_request_header) are always allowed and don't usually need to be listed in `Access-Control-Allow-Headers`, listing them anyway will circumvent the [additional restrictions](/en-US/docs/Glossary/CORS-safelisted_request_header#additional_restrictions) that apply.\n   *\n   * ```http\n   * Access-Control-Allow-Headers: Accept\n   * ```\n   *\n   * ### Handling preflight requests\n   *\n   * Let's look at an example of a [preflight request](https://developer.mozilla.org/en-US/docs/glossary/preflight_request) involving `Access-Control-Allow-Headers`.\n   *\n   * #### Request\n   *\n   * First, the preflight request is an [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS) request that includes some combination of the three preflight request headers: [Access-Control-Request-Method](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Method), [Access-Control-Request-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Headers), and [Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin).\n   *\n   * The preflight request below tells the server that we want to send a CORS `GET` request with the headers listed in [Access-Control-Request-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Headers) ([Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) and `X-Requested-With`).\n   *\n   * ```http\n   * OPTIONS /resource/foo\n   * Access-Control-Request-Method: GET\n   * Access-Control-Request-Headers: content-type,x-requested-with\n   * Origin: https://foo.bar.org\n   * ```\n   *\n   * #### Response\n   *\n   * If the CORS request indicated by the preflight request is authorized, the server will respond to the preflight request with a message that indicates the allowed origin, methods, and headers. Below, we see that `Access-Control-Allow-Headers` includes the headers that were requested.\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Length: 0\n   * Connection: keep-alive\n   * Access-Control-Allow-Origin: https://foo.bar.org\n   * Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE\n   * Access-Control-Allow-Headers: Content-Type, x-requested-with\n   * Access-Control-Max-Age: 86400\n   * ```\n   *\n   * If the requested method isn't supported, the server will respond with an error.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin)\n   * - [Access-Control-Expose-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers)\n   * - [Access-Control-Allow-Methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods)\n   * - [Access-Control-Request-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Headers)\n   */\n  'Access-Control-Allow-Headers' = 'Access-Control-Allow-Headers',\n\n  /**\n   * The HTTP **`Access-Control-Allow-Methods`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) specifies one or more [HTTP request methods](/en-US/docs/Web/HTTP/Reference/Methods) allowed when accessing a resource in response to a [preflight request](https://developer.mozilla.org/en-US/docs/glossary/preflight_request).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Access-Control-Allow-Methods: <method>, <method>, …\n   * Access-Control-Allow-Methods: *\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<method>`\n   *   - : A comma-separated list of the allowed request methods. `GET`, `HEAD`, and `POST` are always allowed, regardless of whether they are specified in this header, as they are defined as [CORS-safelisted method](https://fetch.spec.whatwg.org/#cors-safelisted-method)s.\n   * - `*` (wildcard)\n   *   - : All HTTP methods.\n   *     It has this meaning only for requests without credentials (requests without [HTTP cookies](/en-US/docs/Web/HTTP/Guides/Cookies) or HTTP authentication information). In requests with credentials, it is\n   *     treated as the literal method name `*` without special semantics.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Access-Control-Allow-Methods: PUT, DELETE\n   * Access-Control-Allow-Methods: *\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin)\n   * - [Access-Control-Expose-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers)\n   * - [Access-Control-Allow-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers)\n   * - [Access-Control-Request-Method](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Method)\n   * - [HTTP request methods](/en-US/docs/Web/HTTP/Reference/Methods)\n   */\n  'Access-Control-Allow-Methods' = 'Access-Control-Allow-Methods',\n\n  /**\n   * The HTTP **`Access-Control-Allow-Origin`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates whether the response can be shared with requesting code from the given [origin](https://developer.mozilla.org/en-US/docs/Glossary/origin).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Access-Control-Allow-Origin: *\n   * Access-Control-Allow-Origin: <origin>\n   * Access-Control-Allow-Origin: null\n   * ```\n   *\n   * ## Directives\n   *\n   * - `*` (wildcard)\n   *   - : The requesting code from any origin is allowed to access the resource.\n   *     For requests _without credentials_, the literal value `*` can be specified as a wildcard.\n   *     Attempting to use the wildcard with credentials [results in an error](/en-US/docs/Web/HTTP/Guides/CORS/Errors/CORSNotSupportingCredentials).\n   * - `<origin>`\n   *   - : Specifies a single origin. If the server supports clients from multiple origins, it must return the origin for the specific client making the request.\n   * - `null`\n   *   - : Specifies the origin \"null\".\n   *     > [!NOTE]\n   *     > The value `null` should not be used. It may seem safe to return `Access-Control-Allow-Origin: \"null\"`; however, the origin of resources that use a non-hierarchical scheme (such as `data:` or `file:`) and sandboxed documents is serialized as `null`.\n   *     > Many browsers will grant such documents access to a response with an `Access-Control-Allow-Origin: null` header, and any origin can create a hostile document with a `null` origin.\n   *     > Therefore, the `null` value for the `Access-Control-Allow-Origin` header should be avoided.\n   *\n   * ## Examples\n   *\n   * A response that tells the browser to allow code from any origin to access a resource will include the following:\n   *\n   * ```http\n   * Access-Control-Allow-Origin: *\n   * ```\n   *\n   * A response that tells the browser to allow requesting code from the origin `https://developer.mozilla.org` to access a resource will include the following:\n   *\n   * ```http\n   * Access-Control-Allow-Origin: https://developer.mozilla.org\n   * ```\n   *\n   * Limiting the possible `Access-Control-Allow-Origin` values to a set of allowed origins requires code on the server side to check the value of the [Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin) request header, compare that to a list of allowed origins, and then if the [Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin) value is in the list, set the `Access-Control-Allow-Origin` value to the same value as the [Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin) value.\n   *\n   * ### CORS and caching\n   *\n   * Suppose the server sends a response with an `Access-Control-Allow-Origin` value with an explicit origin (rather than the `*` wildcard). In that case, the response should also include a [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) response header with the value `Origin` — to indicate to browsers that server responses can differ based on the value of the `Origin` request header.\n   *\n   * ```http\n   * Access-Control-Allow-Origin: https://developer.mozilla.org\n   * Vary: Origin\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin)\n   * - [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   * - [Cross-Origin Resource Sharing (CORS)](/en-US/docs/Web/HTTP/Guides/CORS)\n   * - [Cross-Origin-Resource-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy)\n   */\n  'Access-Control-Allow-Origin' = 'Access-Control-Allow-Origin',\n\n  /**\n   * The HTTP **`Access-Control-Expose-Headers`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) allows a server to indicate which response headers should be made available to scripts running in the browser in response to a cross-origin request.\n   *\n   * Only the [CORS-safelisted response headers](https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_response_header) are exposed by default. For clients to be able to access other headers, the server must list them using the `Access-Control-Expose-Headers` header.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Access-Control-Expose-Headers: [<header-name>[, <header-name>]*]\n   * Access-Control-Expose-Headers: *\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<header-name>`\n   *   - : A list of zero or more comma-separated [header names](/en-US/docs/Web/HTTP/Reference/Headers) that clients are allowed to access from a response.\n   *     These are _in addition_ to the [CORS-safelisted response headers](https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_response_header).\n   * - `*` (wildcard)\n   *   - : Any header.\n   *     The value `*` only counts as a special wildcard value for requests without credentials (requests without [HTTP cookies](/en-US/docs/Web/HTTP/Guides/Cookies) or HTTP authentication information).\n   *     In requests with credentials, it is treated as the literal header name `*`.\n   *\n   * ## Examples\n   *\n   * The [CORS-safelisted response headers](https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_response_header) are: [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control), [Content-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Language), [Content-Length](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length), [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type), [Expires](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires), [Last-Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified), [Pragma](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma). To expose a non-CORS-safelisted response header, you can specify:\n   *\n   * ```http\n   * Access-Control-Expose-Headers: Content-Encoding\n   * ```\n   *\n   * To additionally expose a custom header, like `Kuma-Revision`, you can specify multiple headers separated by a comma:\n   *\n   * ```http\n   * Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision\n   * ```\n   *\n   * For requests without credentials, a server can also respond with a wildcard value:\n   *\n   * ```http\n   * Access-Control-Expose-Headers: *\n   * ```\n   *\n   * A server can also respond with the `*` value for requests with credentials, but in this case it would refer to a header named `*`.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Access-Control-Allow-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers)\n   * - [Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin)\n   */\n  'Access-Control-Expose-Headers' = 'Access-Control-Expose-Headers',\n\n  /**\n   * The HTTP **`Access-Control-Max-Age`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates how long the results of a [preflight request](https://developer.mozilla.org/en-US/docs/glossary/preflight_request) (that is, the information contained in the [Access-Control-Allow-Methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods) and [Access-Control-Allow-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers) headers) can be cached.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Access-Control-Max-Age: <delta-seconds>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<delta-seconds>`\n   *   - : Maximum number of seconds for which the results can be cached as an unsigned non-negative integer.\n   *     Firefox [caps this at 24 hours](https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsCORSListenerProxy.cpp#1207) (86400 seconds).\n   *     Chromium (prior to v76) [caps at 10 minutes](https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/cors/preflight_result.cc;drc=52002151773d8cd9ffc5f557cd7cc880fddcae3e;l=36) (600 seconds).\n   *     Chromium (starting in v76) [caps at 2 hours](https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/cors/preflight_result.cc;drc=49e7c0b4886cac1f3d09dc046bd528c9c811a0fa;l=31) (7200 seconds).\n   *     The default value is 5 seconds.\n   *\n   * ## Examples\n   *\n   * Cache results of a preflight request for 10 minutes:\n   *\n   * ```http\n   * Access-Control-Max-Age: 600\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Access-Control-Allow-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers)\n   * - [Access-Control-Allow-Methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods)\n   */\n  'Access-Control-Max-Age' = 'Access-Control-Max-Age',\n\n  /**\n   * The HTTP **`Access-Control-Request-Headers`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is used by browsers when issuing a [preflight request](https://developer.mozilla.org/en-US/docs/glossary/preflight_request) to let the server know which [HTTP headers](/en-US/docs/Web/HTTP/Reference/Headers) the client might send when the actual request is made (such as with [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch) or [XMLHttpRequest.setRequestHeader()](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest.setRequestHeader())). The complementary server-side header of [Access-Control-Allow-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers) will answer this browser-side header.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Access-Control-Request-Headers: <header-name>,<header-name>,…\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<header-name>`\n   *   - : A sorted list of unique, comma-separated, lowercase [HTTP headers](/en-US/docs/Web/HTTP/Reference/Headers) that are included in the request.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Access-Control-Request-Headers: content-type,x-pingother\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Access-Control-Request-Method](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Method)\n   */\n  'Access-Control-Request-Headers' = 'Access-Control-Request-Headers',\n\n  /**\n   * The HTTP **`Access-Control-Request-Method`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is used by browsers when issuing a [preflight request](https://developer.mozilla.org/en-US/docs/glossary/preflight_request) to let the server know which [HTTP method](/en-US/docs/Web/HTTP/Reference/Methods) will be used when the actual request is made.\n   * This header is necessary because the preflight request is always an [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS) and doesn't use the same method as the actual request.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Access-Control-Request-Method: <method>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<method>`\n   *   - : An [HTTP request method](/en-US/docs/Web/HTTP/Reference/Methods); for example, [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET), [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST), or [DELETE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/DELETE).\n   *\n   * ## Examples\n   *\n   * ```http\n   * Access-Control-Request-Method: POST\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Access-Control-Request-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Headers)\n   */\n  'Access-Control-Request-Method' = 'Access-Control-Request-Method',\n\n  /**\n   * The HTTP **`Age`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates the time in seconds for which an object was in a proxy cache.\n   *\n   * The header value is usually close to zero.\n   * If the value is `0`, the object was probably fetched from the origin server; otherwise, the value is usually calculated as a difference between the proxy's current date and the [Date](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date) general header included in the HTTP response.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Age: <delta-seconds>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<delta-seconds>`\n   *   - : A non-negative integer that represents the time in seconds for which the object was in a proxy cache.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Age: 24\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)\n   * - [Expires](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires)\n   */\n  'Age' = 'Age',\n\n  /**\n   * The HTTP **`Allow`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) lists the set of [request methods](/en-US/docs/Web/HTTP/Reference/Methods) supported by a resource.\n   * This header must be sent if the server responds with a [405 Method Not Allowed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405) status code to indicate which request methods can be used instead.\n   * An empty `Allow` value indicates that the resource allows no request methods, which might occur temporarily for a given resource.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Allow: <http-methods>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<http-methods>`\n   *   - : A comma-separated list of allowed request methods supported by a resource.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Allow: GET, POST, HEAD\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## See also\n   *\n   * - [405 Method Not Allowed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405) status code\n   * - [Server](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server)\n   * - [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS)\n   */\n  'Allow' = 'Allow',\n\n  /**\n   * The HTTP **`Alt-Svc`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) lets a server indicate that another network location (the \"alternative service\") can be treated as authoritative for that origin when making future requests.\n   *\n   * Doing so allows new protocol versions to be advertised without affecting in-flight requests and can also help servers manage traffic. Using an alternative service is not visible to the end user; it does not change the URL or the origin of the request and does not introduce additional round trips.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Alt-Svc: clear\n   * Alt-Svc: <protocol-id>=<alt-authority>; ma=<max-age>\n   * Alt-Svc: <protocol-id>=<alt-authority>; ma=<max-age>; persist=1\n   * ```\n   *\n   * - `clear`\n   *   - : All alternative services of the origin are invalidated.\n   * - `<protocol-id>`\n   *   - : The [Application-Layer Protocol Negotiation (ALPN)](https://developer.mozilla.org/en-US/docs/Glossary/ALPN) protocol identifier. Examples include `h2` for HTTP/2 and `h3-25` for draft 25 of the HTTP/3 protocol.\n   * - `<alt-authority>`\n   *   - : A quoted string specifying the alternative authority, consisting of an optional host override, a colon, and a mandatory port number.\n   * - `ma=<max-age>`\n   *   - : The number of seconds for which the alternative service is considered fresh.\n   *     If omitted, it defaults to 24 hours.\n   *     Alternative service entries can be cached for up to `<max-age>` seconds, minus the age of the response (from the [Age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Age) header).\n   *     Once the cached entry expires, the client can no longer use this alternative service for new connections.\n   * - `persist=1`\n   *   - : Entries are not deleted by network configuration changes.\n   *     Cached alternative service entries are usually cleared on such changes.\n   *\n   * Multiple entries can be specified in a single `Alt-Svc` header using comma as separator.\n   * In that case, early entries are considered more preferable.\n   *\n   * ## Example\n   *\n   * ```http\n   * Alt-Svc: h2=\":443\"; ma=2592000;\n   * Alt-Svc: h2=\":443\"; ma=2592000; persist=1\n   * Alt-Svc: h2=\"alt.example.com:443\", h2=\":443\"\n   * Alt-Svc: h3-25=\":443\"; ma=3600, h2=\":443\"; ma=3600\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Alternative Services](https://www.mnot.net/blog/2016/03/09/alt-svc) by HTTP Working Group chair, Mark Nottingham (2016)\n   */\n  'Alt-Svc' = 'Alt-Svc',\n\n  /**\n   * The HTTP **`Alt-Used`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is used to identify the alternative service in use, just as the [Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host) HTTP header field identifies the host and port of the origin.\n   *\n   * The 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.\n   *\n   * When a client uses an alternative service for a request, it can indicate this to the server using the `Alt-Used` HTTP header.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Alt-Used: <host>:<port>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<host>`\n   *   - : The domain name of the server.\n   * - `<port>`\n   *   - : The TCP port number on which the server is listening.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Alt-Used: alternate.example.net\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## See also\n   *\n   * - [Alt-Svc](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Alt-Svc)\n   * - [Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host)\n   */\n  'Alt-Used' = 'Alt-Used',\n\n  /**\n   * The HTTP **`Attribution-Reporting-Eligible`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates that the corresponding response is eligible to register an attribution source or trigger.\n   *\n   * This header is never set manually and is instead sent by the browser in response to various HTML element or JavaScript request settings. Depending on the allowed registrations specified in the `Attribution-Reporting-Eligible` value, the server is expected to respond with either an [Attribution-Reporting-Register-Source](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Source) or [Attribution-Reporting-Register-Trigger](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Trigger) header to complete the registration of an attribution source or trigger, respectively.\n   *\n   * See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Attribution-Reporting-Eligible: <allowed-registrations>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<allowed-registrations>`\n   *   - : A structured-header dictionary representing the registrations allowed in the corresponding response. Possible keys are:\n   *     - `event-source`\n   *       - : An [event-based attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#event-based_attribution_sources) can be registered.\n   *     - `navigation-source`\n   *       - : A [navigation-based attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#navigation-based_attribution_sources) can be registered.\n   *     - `trigger`\n   *       - : An [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers) can be registered.\n   *\n   * Every response in a redirect chain can register at most one source or one trigger.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Attribution-Reporting-Eligible: trigger\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Attribution-Reporting-Register-Source](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Source)\n   * - [Attribution-Reporting-Register-Trigger](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Trigger)\n   * - [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API)\n   */\n  'Attribution-Reporting-Eligible' = 'Attribution-Reporting-Eligible',\n\n  /**\n   * The HTTP **`Attribution-Reporting-Register-Source`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) registers a page feature as an [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources). This header is included as part of a response to a request that contains the [Attribution-Reporting-Eligible](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Eligible) header. It provides the information that the browser should store when a user interacts with the attribution source. The information you include in this header also determines the types of reports the browser can generate.\n   *\n   * See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details.\n   *\n   * > [!NOTE]\n   * > If the calling site does not have the Attribution Reporting API included in a successful [privacy sandbox enrollment process](/en-US/docs/Web/Privacy/Guides/Privacy_sandbox/Enrollment), the `Attribution-Reporting-Register-Source` header is ignored and attribution sources are not registered.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Attribution-Reporting-Register-Source: <json-string>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<json-string>`\n   *   - : A JSON string providing the information that the browser should store when the attribution source is interacted with. Available fields are as follows:\n   *     - `\"source_event_id\"`\n   *       - : A string representing an ID for the attribution source, which can be used to map it to other information when the attribution source is interacted with, or aggregate information at the reporting endpoint. The string must consist solely of a base-10-formatted 64-bit unsigned integer.\n   *     - `\"destination\"`\n   *       - : A single string or an array of 1–3 strings. These strings must contain a complete URL corresponding to the site (scheme + [eTLD+1](/en-US/docs/Glossary/eTLD)) on which a trigger is expected to occur. These are used to match the attribution trigger to the source when a trigger is interacted with.\n   *     - `\"aggregation_keys\"`\n   *       - : An object containing user-provided keys representing different data points to aggregate report values under.\n   *     - `\"aggregatable_report_window\"`\n   *       - : A string representing a time in seconds after which trigger data will no longer be included in generated aggregatable reports (this is called a **report window**). If not set, this defaults to the `\"expiry\"` value.\n   *     - `\"debug_key\"`\n   *       - : A base-10-formatted 64-bit unsigned integer representing a debug key. Set this if you want to generate a [debug report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#debug_reports) alongside the associated attribution report.\n   *     - `\"debug_reporting\"`\n   *       - : A boolean value. If a `debug_key` is set, set this to `true` to specify that the generated debug report should be a verbose debug report.\n   *     - `\"event_level_epsilon\"`\n   *       - : A number equal to or greater than `0`, which controls the amount of [noise added to reports](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#adding_noise_to_reports). Lower values of epsilon result in more noise and therefore provide greater privacy protection. The maximum and default values will vary across implementations; Chrome for example has a maximum and default value of `14`.\n   *     - `\"event_report_window\"`\n   *       - : A string representing a time in seconds, after which subsequent triggers won't be attributable to this source for the purpose of producing event-level reports (this is called a **report window**). If not set, the event report window falls back to the `\"expiry\"` value.\n   *         > [!NOTE]\n   *         > If `\"event_report_window\"` is specified, `\"event_report_windows\"` cannot be specified, otherwise the source registration will fail.\n   *     - `\"event_report_windows\"`\n   *       - : An object representing a series of report windows, starting at `\"start_time\"`, with reports for this source being delivered after each specified end time in `\"end_times\"`. This can be used to vary the time of report delivery across multiple reports. If not set, the event report window falls back to the `\"expiry\"` value. Properties are as follows:\n   *         - `\"start_time\"` : A non-negative number specifying the start time for the reporting windows. If not specified, it defaults to `0`.\n   *         - `\"end_times\"`: An array of positive numbers specifying end times for subsequent report windows. The values must be increasing, and greater than `\"start_time\"`.\n   *           > [!NOTE]\n   *           > If `\"event_report_windows\"` is specified, `\"event_report_window\"` cannot be specified, otherwise the source registration will fail.\n   *     - `\"expiry\"`\n   *       - : A string representing an expiry time in seconds for the attribution source, after which it will no longer be active (i.e., subsequent triggers won't be attributable to this source). The maximum allowable expiry time is 2592000 seconds (30 days), which is also the default value if `\"expiry\"` is not explicitly set.\n   *     - `\"filter_data\"`\n   *       - : An object defining custom data that can be used to filter which conversions generate reports. See [Filters](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters) for more details.\n   *     - `\"max_event_level_reports\"`\n   *       - : A number between `0` and `20`, inclusive, which specifies the total number of event-level reports this source can generate. After this maximum is reached, the source is no longer capable of producing any new data. If not specified, `\"max_event_level_reports\"` defaults to `3` for navigation-based sources and `1` for event-based (image- or script-based) sources.\n   *     - `\"priority\"`\n   *       - : A string representing a priority value for the attribution source. By default, conversions are attributed to the most recent matching source. For both event-level and summary reports you set a higher priority number to prioritize specific sources. For example, a value of `2` takes priority over the default value of `1`. See [Report priorities and limits](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#report_priorities_and_limits) for more information.\n   *     - `\"trigger_data\"`\n   *       - : An array of 32-bit unsigned integers representing data that describes the different trigger events that could match this source. For example, \"user added item to shopping cart\" or \"user signed up to mailing list\" could be actions happening at the trigger site that could match this source and indicate a conversion of some kind that the advertiser is trying to measure. These must be matched against `\"trigger_data\"` specified in [triggers](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Trigger#trigger_data) for event-level attribution to take place. If omitted, `\"trigger_data\"` defaults to `[0, 1, 2, 3, 4, 5, 6, 7]` for navigation-based sources and `[0, 1]` for event-based (image- or script-based) sources.\n   *\n   *         > [!NOTE]\n   *         > The values used to represent each event, and the number of elements in the array, are completely arbitrary and defined by you as the developer. The array may contain values that are not used, but values must be present in the array to be attributed to the source by the browser when a trigger is registered.\n   *\n   *     - `\"trigger_data_matching\"`\n   *       - : A string that specifies how the `\"trigger_data\"` from the trigger is matched against the source's `\"trigger_data\"`. Possible values are:\n   *         - `\"exact\"`: The `\"trigger_data\"` from the trigger must exactly match a value contained in the source's `\"trigger_data\"`; if there is no such match, no event-level attribution takes place.\n   *         - `\"modulus\"`: In this case, the following calculation is performed — `d % allowedValues.size` — where `d` is the `\"trigger_data\"` from the trigger, and `allowedValues` is the sequence of values in the source's `\"trigger_data\"` array. If the result of this calculation matches a value in the source's `\"trigger_data\"` array, the match is a success. In such a case, the value will always match, unless `allowedValues` is empty.\n   *\n   *         `\"modulus\"` mode exists primarily for backwards compatibility with the API's behavior before `\"exact\"` was introduced, and as such, you'd be unlikely to use it. It is still useful in particular cases that require a very specific kind of compression resulting in smaller registration headers. This can be required when using complex filtering logic that needs to set different trigger data based on the source type according to the maximum number of source `\"trigger_data\"` items.\n   *\n   *         > [!NOTE]\n   *         > If `\"modulus\"` is used, the source's `\"trigger_data\"` must form a contiguous sequence of integers starting at 0. If the trigger data does not form such a sequence, an error occurs.\n   *\n   *         If not specified, `\"trigger_data_matching\"` defaults to `\"modulus\"`. Again, the reason for this is backwards compatibility: omitting the `\"trigger_data_matching\"` field needs to result in the same behavior observed before this field was introduced.\n   *\n   * ## Examples\n   *\n   * ### Registering a source for an event-level report\n   *\n   * A Node.js server might set the `Attribution-Reporting-Register-Source` response header as follows to make a browser generate an event-level report when a trigger is matched to a source:\n   *\n   * ```js\n   * res.set(\n   *   \"Attribution-Reporting-Register-Source\",\n   *   JSON.stringify({\n   *     source_event_id: \"412444888111012\",\n   *     destination: \"https://shop.example\",\n   *     trigger_data: [0, 1, 2, 3, 4],\n   *     trigger_data_matching: \"exact\",\n   *     expiry: \"604800\",\n   *     priority: \"100\",\n   *     debug_key: \"122939999\",\n   *     event_report_window: \"86400\",\n   *   }),\n   * );\n   * ```\n   *\n   * ### Registering a source for a summary report\n   *\n   * To make the browser generate a summary report when a trigger is matched to a source, you need to include some extra fields, _in addition_ to those required for event-level report generation.\n   *\n   * ```js\n   * res.set(\n   *   \"Attribution-Reporting-Register-Source\",\n   *   JSON.stringify({\n   *     source_event_id: \"412444888111012\",\n   *     destination: \"https://shop.example\",\n   *     trigger_data: [0, 1, 2, 3, 4],\n   *     trigger_data_matching: \"exact\",\n   *     expiry: \"604800\",\n   *     priority: \"100\",\n   *     debug_key: \"122939999\",\n   *     event_report_window: \"86400\",\n   *\n   *     aggregation_keys: {\n   *       campaignCounts: \"0x159\",\n   *       geoValue: \"0x5\",\n   *     },\n   *     aggregatable_report_window: \"86400\",\n   *   }),\n   * );\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Attribution-Reporting-Eligible](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Eligible)\n   * - [Attribution-Reporting-Register-Trigger](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Trigger)\n   * - [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API)\n   */\n  'Attribution-Reporting-Register-Source' = 'Attribution-Reporting-Register-Source',\n\n  /**\n   * The HTTP **`Attribution-Reporting-Register-Trigger`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) registers a page feature as an [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers). This header is included as part of a response to a request that contains the [Attribution-Reporting-Eligible](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Eligible) header.\n   *\n   * See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details.\n   *\n   * > [!NOTE]\n   * > If the calling site does not have the Attribution Reporting API included in a successful [privacy sandbox enrollment process](/en-US/docs/Web/Privacy/Guides/Privacy_sandbox/Enrollment), the `Attribution-Reporting-Register-Trigger` header is ignored and attribution triggers are not registered.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Attribution-Reporting-Register-Trigger: <json-string>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<json-string>`\n   *   - : A JSON string providing data that can be included in generated reports, such as the ID of the trigger, and priority and deduplication values. Available fields are as follows:\n   *     - `\"aggregatable_trigger_data\"`\n   *       - : An array of objects, each one defining an aggregation key to apply to different source keys. Each object contains the following properties:\n   *         - `\"key_piece\"`\n   *           - : A hexadecimal value representing a key.\n   *         - `\"source_keys\"`\n   *           - : An array containing one or more key values for the data.\n   *     - `\"aggregatable_values\"`\n   *       - : An object containing properties representing a value for each data point defined in `\"aggregatable_trigger_data\"`. In each case, the property name is equal to the name defined in `\"source_keys\"`, and the property value is whatever arbitrary value you require.\n   *     - `\"debug_key\"`\n   *       - : A number representing a debug key. Set this if you want to generate a [debug report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#debug_reports) alongside the associated attribution report.\n   *     - `\"debug_reporting\"`\n   *       - : A boolean value. If a `debug_key` is set, set this to `true` to specify that the generated debug report should be a verbose debug report.\n   *     - `\"filters\"`\n   *       - : An object containing custom data that can be used to filter which triggers generate reports. See [Filters](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters) for more details.\n   *     - `\"event_trigger_data\"`\n   *       - : An object representing data about the trigger. Available sub-fields are as follows:\n   *         - `\"trigger_data\"`\n   *           - : A string representing data that describes the trigger, which is typically used to indicate events such as \"user added item to shopping cart\" or \"user signed up to mailing list\". This value will be included in the generated event-level report, if any, although it will be subject to modification based on the attributed source's [`\"trigger_data_matching\"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#trigger_data_matching) field.\n   *\n   *             > [!NOTE]\n   *             > The values used to represent each event, and the number of elements in the array, are completely arbitrary and defined by you as the developer. The array may contain values that are not used, but values must be present in the array to be attributed to the source by the browser when a trigger is registered.\n   *\n   *         - `\"priority\"`\n   *           - : A string representing a priority value for the attribution trigger. By default, triggers are attributed to the most recent matching source. For both event-level and summary reports you set a higher priority number to make the trigger match older sources. For example, a value of `2` takes priority over the default value of `1`. See [Report priorities and limits](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#report_priorities_and_limits) for more information.\n   *         - `\"deduplication_key\"`\n   *           - : A string representing a unique key that can be used to prevent attributions from being duplicated — for example if a user were to add the same item to a shopping cart multiple times. See [Prevent duplication in reports](https://privacysandbox.google.com/private-advertising/attribution-reporting/prevent-duplication) for more information.\n   *         - `\"filters\"`\n   *           - : An object containing filters that perform selective filtering to set `\"trigger_data\"`, `\"priority\"`, and `\"deduplication_key\"` based on the `filter_data` set in a corresponding [Attribution-Reporting-Register-Source](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Source) header. See [Filters](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters) for more information.\n   *\n   * ## Examples\n   *\n   * ### Registering a trigger for an event-level report\n   *\n   * A Node.js server might set the `Attribution-Reporting-Register-Trigger` response header as follows to register a trigger intended to match an event-level report attribution source:\n   *\n   * ```js\n   * res.set(\n   *   \"Attribution-Reporting-Register-Trigger\",\n   *   JSON.stringify({\n   *     event_trigger_data: [\n   *       {\n   *         trigger_data: \"4\",\n   *         priority: \"1000000000000\",\n   *         deduplication_key: \"2345698765\",\n   *       },\n   *     ],\n   *     debug_key: \"1115698977\",\n   *   }),\n   * );\n   * ```\n   *\n   * ### Registering a trigger for a summary report\n   *\n   * When registering a trigger intended to match with a summary report attribution source, you need to include the following fields:\n   *\n   * ```js\n   * res.set(\n   *   \"Attribution-Reporting-Register-Trigger\",\n   *   JSON.stringify({\n   *     aggregatable_trigger_data: [\n   *       {\n   *         key_piece: \"0x400\",\n   *         source_keys: [\"campaignCounts\"],\n   *       },\n   *       {\n   *         key_piece: \"0xA80\",\n   *         source_keys: [\"geoValue\", \"nonMatchingKeyIdsAreIgnored\"],\n   *       },\n   *     ],\n   *     aggregatable_values: {\n   *       campaignCounts: 32768,\n   *       geoValue: 1664,\n   *     },\n   *     debug_key: \"1115698977\",\n   *   }),\n   * );\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Attribution-Reporting-Eligible](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Eligible)\n   * - [Attribution-Reporting-Register-Source](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Attribution-Reporting-Register-Source)\n   * - [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API)\n   */\n  'Attribution-Reporting-Register-Trigger' = 'Attribution-Reporting-Register-Trigger',\n\n  /**\n   * The HTTP **`Authorization`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) can be used to provide credentials that authenticate a user agent with a server, allowing access to protected resources.\n   *\n   * The `Authorization` header is usually, but not always, sent after the user agent first attempts to request a protected resource without credentials.\n   * The server responds with a [401 Unauthorized](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401) message that includes at least one [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate) header.\n   * This header indicates the authentication schemes that can be used to access the resource and any additional information needed by the client to use them.\n   * The user-agent should select the most secure authentication scheme that it supports from those offered, prompt the user for their credentials, and then re-request the resource with the encoded credentials in the `Authorization` header.\n   *\n   * This header is stripped from cross-origin redirects.\n   *\n   * > [!NOTE]\n   * > This header is part of the [General HTTP authentication framework](/en-US/docs/Web/HTTP/Guides/Authentication#the_general_http_authentication_framework).\n   * > It can be used with a number of [authentication schemes](/en-US/docs/Web/HTTP/Guides/Authentication#authentication_schemes).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Authorization: <auth-scheme> <authorization-parameters>\n   *\n   * // Basic authentication\n   * Authorization: Basic <credentials>\n   *\n   * // Digest authentication\n   * Authorization: Digest username=<username>,\n   *     realm=\"<realm>\",\n   *     uri=\"<url>\",\n   *     algorithm=<algorithm>,\n   *     nonce=\"<nonce>\",\n   *     nc=<nc>,\n   *     cnonce=\"<cnonce>\",\n   *     qop=<qop>,\n   *     response=\"<response>\",\n   *     opaque=\"<opaque>\"\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<auth-scheme>`\n   *   - : The [Authentication scheme](/en-US/docs/Web/HTTP/Guides/Authentication#authentication_schemes) that defines how the credentials are encoded.\n   *     Some of the more common types are (case-insensitive): [`Basic`](/en-US/docs/Web/HTTP/Guides/Authentication#basic_authentication_scheme), `Digest`, `Negotiate` and `AWS4-HMAC-SHA256`.\n   *\n   *     > [!NOTE]\n   *     > For more information/options see [HTTP Authentication > Authentication schemes](/en-US/docs/Web/HTTP/Guides/Authentication#authentication_schemes)\n   *\n   * Other than `<auth-scheme>`, the remaining directives are specific to each [authentication scheme](/en-US/docs/Web/HTTP/Guides/Authentication#authentication_schemes).\n   * Generally, you will need to check the relevant specifications for these (keys for a small subset of schemes are listed below).\n   *\n   * ### Basic authentication\n   *\n   * - `<credentials>`\n   *   - : The credentials, encoded according to the specified scheme.\n   *\n   *     > [!NOTE]\n   *     > For information about the encoding algorithm, see the examples: below, in [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate), in [HTTP Authentication](/en-US/docs/Web/HTTP/Guides/Authentication), and in the relevant specifications.\n   *\n   * ### Digest authentication\n   *\n   * - `<response>`\n   *   - : A string of the hex digits that proves that the user knows a password.\n   *     The algorithm encodes the username and password, realm, cnonce, qop, nc, and so on.\n   *     It is described in detail in the specification.\n   * - `username`\n   *   - : A quoted string containing user's name for the specified `realm` in either plain text or the hash code in hexadecimal notation.\n   *     If the name contains characters that aren't allowed in the field, then `username*` can be used instead (not \"as well\").\n   * - `username*`\n   *   - : The user's name formatted using an extended notation defined in RFC5987.\n   *     This should be used only if the name can't be encoded in `username` and if `userhash` is set `\"false\"`.\n   * - `uri`\n   *   - : The _Effective Request URI_. See the specification for more information.\n   * - `realm`\n   *   - : Realm of the requested username/password (again, should match the value in the corresponding [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate) response for the resource being requested).\n   * - `opaque`\n   *   - : The value in the corresponding [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate) response for the resource being requested.\n   * - `algorithm`\n   *   - : The algorithm used to calculate the digest. Must be a supported algorithm from the [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate) response for the resource being requested.\n   * - `qop`\n   *   - : A token indicating the _quality of protection_ applied to the message.\n   *     Must match the one value in the set specified in the [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate) response for the resource being requested.\n   *     - `\"auth\"`: Authentication\n   *     - `\"auth-int\"`: Authentication with integrity protection\n   * - `cnonce`\n   *   - : An quoted [ASCII](https://developer.mozilla.org/en-US/docs/Glossary/ASCII)-only string value provided by the client.\n   *     This is used by both the client and server to provide mutual authentication, provide some message integrity protection, and avoid \"chosen plaintext\n   *     attacks\".\n   *     See the specification for additional information.\n   * - `nc`\n   *   - : Nonce count. The hexadecimal count of requests in which the client has sent the current `cnonce` value (including the current request).\n   *     The server can use duplicate `nc` values to recognize replay requests.\n   * - `userhash`\n   *   - : `\"true\"` if the username has been hashed. `\"false\"` by default.\n   *\n   * ## Examples\n   *\n   * ### Basic authentication\n   *\n   * For `Basic` authentication, the credentials are constructed by first combining the username and the password with a colon (e.g., `aladdin:opensesame`), and then by encoding the resulting string in [`base64`](/en-US/docs/Glossary/Base64) (e.g., `YWxhZGRpbjpvcGVuc2VzYW1l`).\n   *\n   * ```http\n   * Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l\n   * ```\n   *\n   * > [!WARNING]\n   * > [Base64](https://developer.mozilla.org/en-US/docs/Glossary/Base64)-encoding can easily be reversed to obtain the original name and password, so `Basic` authentication offers no cryptographic security.\n   * > [HTTPS](https://developer.mozilla.org/en-US/docs/Glossary/HTTPS) is always recommended when using authentication, but is even more so when using `Basic` authentication.\n   *\n   * See also [HTTP authentication](/en-US/docs/Web/HTTP/Guides/Authentication) for examples on how to configure Apache or Nginx servers to password protect your site with HTTP basic authentication.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTTP authentication](/en-US/docs/Web/HTTP/Guides/Authentication)\n   * - [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate)\n   * - [Proxy-Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authorization)\n   * - [Proxy-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authenticate)\n   * - [401](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401), [403](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403), [407](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407)\n   */\n  'Authorization' = 'Authorization',\n\n  /**\n   * The HTTP **`Available-Dictionary`** request header allows the browser to specify the best matching dictionary it has to allow the server to use [Compression Dictionary Transport](https://developer.mozilla.org/en-US/docs/glossary/Compression_Dictionary_Transport) for a resource request.\n   *\n   * Clients can send an `Available-Dictionary` header when they support `dcb` or `dcz` encodings. The header is a colon-surrounded base-64 encoded SHA-256 [hash](https://developer.mozilla.org/en-US/docs/glossary/Hash_function) of the dictionary contents.\n   *\n   * See the [Compression Dictionary Transport guide](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport) for more information.\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Available-Dictionary: :<base64-hash>:\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<base64-hash>`\n   *   - : A base-64 encoded SHA-256 [hash](https://developer.mozilla.org/en-US/docs/glossary/Hash_function) of the dictionary contents.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Accept-Encoding: gzip, br, zstd, dcb, dcz\n   * Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Compression Dictionary Transport guide](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport)\n   * - [Use-As-Dictionary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Use-As-Dictionary)\n   * - [Dictionary-ID](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Dictionary-ID)\n   */\n  'Available-Dictionary' = 'Available-Dictionary',\n\n  /**\n   * The HTTP **`Cache-Control`** header holds _directives_ (instructions) in both requests and responses that control [caching](/en-US/docs/Web/HTTP/Guides/Caching) in browsers and shared caches (e.g., Proxies, CDNs).\n   *\n   *\n   * <img src=\"/assets/hero.png?hash=deadbeef\" width=\"900\" height=\"400\" />\n   * ```\n   *\n   * You can add a long `max-age` value and `immutable` because the content will never change.\n   *\n   * ```http\n   * # /assets/*\n   * Cache-Control: max-age=31536000, immutable\n   * ```\n   *\n   * When you update the library or edit the picture, new content should have a new URL, and caches aren't reused. That is called the \"cache busting\" pattern.\n   *\n   * Use a `no-cache` to make sure that the HTML response itself is not cached. `no-cache` could cause revalidation, and the client will correctly receive a new version of the HTML response and static assets.\n   *\n   * ```http\n   * # /index.html\n   * Cache-Control: no-cache\n   * ```\n   *\n   * Note: If `index.html` is controlled under Basic Authentication or Digest Authentication, files under `/assets` are not stored in the shared cache. If `/assets/` files are suitable for storing in a shared cache, you also need one of `public`, `s-maxage` or `must-revalidate`.\n   *\n   * ### Up-to-date contents always\n   *\n   * For content that's generated dynamically, or that's static but updated often, you want a user to always receive the most up-to-date version.\n   *\n   * If you don't add a `Cache-Control` header because the response is not intended to be cached, that could cause an unexpected result. Cache storage is allowed to cache it heuristically — so if you have any requirements on caching, you should always indicate them explicitly, in the `Cache-Control` header.\n   *\n   * Adding `no-cache` to the response causes revalidation to the server, so you can serve a [fresh](/en-US/docs/Web/HTTP/Guides/Caching#fresh_and_stale_based_on_age) response every time — or if the client already has a new one, just respond `304 Not Modified`.\n   *\n   * ```http\n   * Cache-Control: no-cache\n   * ```\n   *\n   * Most HTTP/1.0 caches don't support `no-cache` directives, so historically `max-age=0` was used as a workaround. But only `max-age=0` could cause a [stale response](/en-US/docs/Web/HTTP/Guides/Caching#fresh_and_stale_based_on_age) to be reused when caches disconnected from the origin server. `must-revalidate` addresses that. That's why the example below is equivalent to `no-cache`.\n   *\n   * ```http\n   * Cache-Control: max-age=0, must-revalidate\n   * ```\n   *\n   * But for now, you can simply use `no-cache` instead.\n   *\n   * ### Clearing an already-stored cache\n   *\n   * There are no cache directives for clearing already-stored responses from caches on _intermediate_ servers.\n   *\n   * Imagine that clients/caches store a [fresh](/en-US/docs/Web/HTTP/Guides/Caching#fresh_and_stale_based_on_age) response for a path, with no request flight to the server. There is nothing a server could do to that path.\n   *\n   * [`Clear-Site-Data: cache`](/en-US/docs/Web/HTTP/Reference/Headers/Clear-Site-Data#cache) can be used to clear every stored response for a site in the browser cache, so use this with care.\n   * Note that this will not affected shared or intermediate caches.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTTP caching](/en-US/docs/Web/HTTP/Guides/Caching)\n   * - [Caching Tutorial for Web Authors and Webmasters](https://www.mnot.net/cache_docs/)\n   * - [Caching best practices & max-age gotchas](https://jakearchibald.com/2016/caching-best-practices/)\n   * - [Cache-Control for Civilians](https://csswizardry.com/2019/03/cache-control-for-civilians/)\n   * - [RFC 9111 – HTTP Caching](https://httpwg.org/specs/rfc9111.html)\n   * - [RFC 5861 – HTTP Cache-Control Extensions for Stale Content](https://httpwg.org/specs/rfc5861.html)\n   * - [RFC 8246 – HTTP Immutable Responses](https://httpwg.org/specs/rfc8246.html)\n   */\n  'Cache-Control' = 'Cache-Control',\n\n  /**\n   * The HTTP **`Clear-Site-Data`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) sends a signal to the client that it should remove all browsing data of certain types (cookies, storage, cache) associated with the requesting website.\n   * It allows web developers to have more control over the data stored by browsers for their origins.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * // Single directive\n   * Clear-Site-Data: \"cache\"\n   *\n   * // Multiple directives (comma separated)\n   * Clear-Site-Data: \"cache\", \"cookies\"\n   *\n   * // Wild card\n   * Clear-Site-Data: \"*\"\n   * ```\n   *\n   * ## Directives\n   *\n   * > [!NOTE]\n   * > All directives must comply with the [quoted-string grammar](https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.6). A directive that does not include the double quotes is invalid.\n   *\n   * - `\"cache\"`\n   *   - : The server signals that the client should remove locally cached data (the browser cache, see [HTTP caching](/en-US/docs/Web/HTTP/Guides/Caching)) for the origin of the response URL.\n   *     Depending on the browser, this might also clear out things like pre-rendered pages, [backwards-forwards cache](https://developer.mozilla.org/en-US/docs/glossary/bfcache), script caches, WebGL shader caches, or address bar suggestions.\n   *\n   * - `\"clientHints\"`\n   *   - : Indicates that the server will remove all [client hints](/en-US/docs/Web/HTTP/Guides/Client_hints) (requested via [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)) stored for the origin of the response URL.\n   *\n   *     > [!NOTE]\n   *     > In browsers that support the `\"clientHints\"` data type, client hints are also cleared when the `\"cache\"`, `\"cookies\"`, or `\"*\"` types are specified. `\"clientHints\"` is therefore only needed when none of those other types are specified.\n   *\n   * - `\"cookies\"`\n   *   - : The server signals that the client should remove all cookies for the origin of the response URL. HTTP authentication credentials are also cleared out. This affects the entire registered domain, including subdomains. So `https://example.com` as well as `https://stage.example.com`, will have cookies cleared.\n   *\n   * - `\"executionContexts\"`\n   *   - : The server signals that the client should reload all browsing contexts for the origin of the response ([Location.reload](https://developer.mozilla.org/en-US/docs/domxref/Location.reload)).\n   *\n   * - `\"prefetchCache\"`\n   *   - : Used to clear [speculation rules\", \"\", \"nocode](https://developer.mozilla.org/en-US/docs/domxref/Speculation_Rules_API) prefetches that are scoped to the referrer origin.\n   *\n   * - `\"prerenderCache\"`\n   *   - : Used to clear [speculation rules\",\"\", \"nocode](https://developer.mozilla.org/en-US/docs/domxref/Speculation_Rules_API) prerenders that are scoped to the referrer origin.\n   *\n   * - `\"storage\"`\n   *   - : The server signals that the client should remove all DOM storage for the origin of the response URL. This includes storage mechanisms such as:\n   *     - localStorage (executes `localStorage.clear`),\n   *     - sessionStorage (executes `sessionStorage.clear`),\n   *     - IndexedDB (for each database execute [IDBFactory.deleteDatabase](https://developer.mozilla.org/en-US/docs/domxref/IDBFactory.deleteDatabase)),\n   *     - Service worker registrations (for each service worker registration, execute [ServiceWorkerRegistration.unregister](https://developer.mozilla.org/en-US/docs/domxref/ServiceWorkerRegistration.unregister)),\n   *     - Web SQL databases (deprecated),\n   *     - [FileSystem API data](/en-US/docs/Web/API/File_and_Directory_Entries_API),\n   *     - Plugin data (Flash via [`NPP_ClearSiteData`](https://wiki.mozilla.org/NPAPI:ClearSiteData)).\n   *\n   * - `\"*\"` (wildcard)\n   *   - : The server signals that the client should clear all types of data for the origin of the response. If more data types are added in future versions of this header, they will also be covered by it.\n   *\n   * ## Examples\n   *\n   * ### Sign out of a website\n   *\n   * If a user signs out of your website or service, you might want to remove locally stored data, including any prefetched or prerendered content for [speculated navigations\",\"\", \"nocode](https://developer.mozilla.org/en-US/docs/domxref/Speculation_Rules_API).\n   * To do this, add the `Clear-Site-Data` header to the page that confirms the logging out from the site has been accomplished successfully (`https://example.com/logout`, for example):\n   *\n   * ```http\n   * Clear-Site-Data: \"cache\", \"cookies\", \"storage\", \"executionContexts\", \"prefetchCache\", \"prerenderCache\"\n   * ```\n   *\n   * ### Clearing cookies\n   *\n   * If this header is delivered with the response at `https://example.com/clear-cookies`, all cookies on the same domain `https://example.com` and any subdomains (like `https://stage.example.com`, etc.), will be cleared out.\n   *\n   * ```http\n   * Clear-Site-Data: \"cookies\"\n   * ```\n   *\n   * ### Clearing speculations\n   *\n   * If this header is delivered with the response at `https://example.com/change-state.json`, all [speculated navigations\",\"\", \"nocode](https://developer.mozilla.org/en-US/docs/domxref/Speculation_Rules_API) prerenders on the same domain `https://example.com` and any subdomains (such as `https://stage.example.com`), will be cleared.\n   *\n   * ```http\n   * Clear-Site-Data: \"prerenderCache\"\n   * ```\n   *\n   * To clear both prefetch and prerender speculations, both `prefetchCache` and `prerenderCache` must be sent:\n   *\n   * ```http\n   * Clear-Site-Data: \"prefetchCache\", \"prerenderCache\"\n   * ```\n   *\n   * There are cases where clearing one or the other, or both, is appropriate.\n   *\n   * For example, a client-side rendered application that pulls in data from JavaScript might use `prerenderCache` on state change to discard the prerendered pages, but keep the prefetched HTML to use when the page is rendered (or prerendered again).\n   *\n   * On the other hand, if the prefetched HTML document contains stale data but the corresponding prerendered page is set up to refresh the data when it is displayed, you may not need to use `prerenderCache` but you probably will want to use the `prefetchCache` directive: so that the stale HTML isn't used in a future prerender.\n   *\n   * Finally, if the prefetched HTML document contains stale data, and also does not refresh stale content on prerendered pages, then specifying both `prefetchCache` and `prerenderCache` is most appropriate.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)\n   */\n  'Clear-Site-Data' = 'Clear-Site-Data',\n\n  /**\n   * The HTTP **`Connection`** header controls whether the network connection stays open after the current transaction finishes.\n   * If the value sent is `keep-alive`, the connection is persistent and not closed, allowing subsequent requests to the same server on the same connection.\n   *\n   * > [!WARNING]\n   * > Connection-specific header fields such as\n   * > `Connection` and [Keep-Alive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive) are prohibited\n   * > in [HTTP/2](https://httpwg.org/specs/rfc9113.html#ConnectionSpecific) and\n   * > [HTTP/3](https://httpwg.org/specs/rfc9114.html#header-formatting). Chrome and\n   * > Firefox ignore them in HTTP/2 responses, but Safari conforms to the HTTP/2\n   * > spec requirements and does not load any response that contains them.\n   *\n   * All [hop-by-hop headers](/en-US/docs/Web/HTTP/Guides/Compression#hop-by-hop_compression), including the standard hop-by-hop headers ([Keep-Alive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive),\n   * [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding), [TE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/TE), `Connection`,\n   * [Trailer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer), [Upgrade](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade),\n   * [Proxy-Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authorization), and [Proxy-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authenticate)) must be listed in the `Connection`\n   * header, so that the first proxy knows it has to consume them and not forward them\n   * further.\n   *\n   * The default value of `Connection` changed between HTTP/1.0 and HTTP/1.1.\n   * Therefore, to ensure backwards compatibility, browsers often send `Connection: keep-alive` explicitly, even though it's the default in HTTP/1.1.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Connection: keep-alive\n   * Connection: close\n   * ```\n   *\n   * ## Directives\n   *\n   * - `close`\n   *   - : Indicates that either the client or the server would like to close the connection.\n   *     This is the default on HTTP/1.0 requests.\n   * - any comma-separated list of HTTP headers (usually `keep-alive` only)\n   *   - : Indicates that the client would like to keep the connection open. Keeping a connection open\n   *     is the default on HTTP/1.1 requests. The list of headers are the\n   *     name of the header to be removed by the first non-transparent proxy or cache\n   *     in-between: these headers define the connection between the emitter and the first\n   *     entity, not the destination node.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Connection management in HTTP/1.x](/en-US/docs/Web/HTTP/Guides/Connection_management_in_HTTP_1.x)\n   * - [Protocol upgrade mechanism](/en-US/docs/Web/HTTP/Guides/Protocol_upgrade_mechanism)\n   */\n  'Connection' = 'Connection',\n\n  /**\n   * The HTTP **`Content-Digest`** [request](https://developer.mozilla.org/en-US/docs/Glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) provides a [digest](https://developer.mozilla.org/en-US/docs/Glossary/hash_function) calculated using a hashing algorithm applied to the message content.\n   * A recipient can use the `Content-Digest` to validate the HTTP message content for integrity purposes.\n   *\n   * The [Want-Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Content-Digest) field lets a sender request a `Content-Digest` along with their hashing algorithm preferences.\n   * A content digest will differ based on [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) and [Content-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range), but not [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding).\n   *\n   * In certain cases, a [Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Repr-Digest) can be used to validate the integrity of partial or multipart messages against the full representation.\n   * For example, in [range requests](/en-US/docs/Web/HTTP/Guides/Range_requests), a `Repr-Digest` will always have the same value if only the requested byte ranges differ, whereas the content digest will be different for each part.\n   * For this reason, a `Content-Digest` is identical to a [Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Repr-Digest) when a representation is sent in a single message.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Content-Digest: <digest-algorithm>=<digest-value>\n   *\n   * // Multiple digest algorithms\n   * Content-Digest: <digest-algorithm>=<digest-value>,<digest-algorithm>=<digest-value>, …\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<digest-algorithm>`\n   *   - : The algorithm used to create a digest of the message content.\n   *     Only two registered digest algorithms are considered secure: `sha-512` and `sha-256`.\n   *     The insecure (legacy) registered digest algorithms are: `md5`, `sha` (SHA-1), `unixsum`, `unixcksum`, `adler` (ADLER32) and `crc32c`.\n   * - `<digest-value>`\n   *   - : The digest in bytes of the message content using the `<digest-algorithm>`.\n   *     The choice of digest algorithm also determines the encoding to use: `sha-512` and `sha-256` use [base64](https://developer.mozilla.org/en-US/docs/Glossary/base64) encoding, while some legacy digest algorithms such as `unixsum` use a decimal integer.\n   *     In contrast to earlier drafts of the specification, the standard base64-encoded digest bytes are wrapped in colons (`:`, ASCII 0x3A) as part of the [dictionary syntax](https://www.rfc-editor.org/rfc/rfc8941#name-byte-sequences).\n   *\n   * ## Description\n   *\n   * A `Digest` header was defined in previous specifications, but it proved problematic as the scope of what the digest applied to was not clear.\n   * Specifically, it was difficult to distinguish whether a digest applied to the entire resource representation or to the specific content of a HTTP message.\n   * As such, two separate headers were specified (`Content-Digest` and `Repr-Digest`) to convey HTTP message content digests and resource representation digests, respectively.\n   *\n   * ## Examples\n   *\n   * ### User-agent request for a SHA-256 Content-Digest\n   *\n   * In the following example, a user-agent requests a digest of the message content with a preference for SHA-256, followed by SHA-1 at a lower preference:\n   *\n   * ```http\n   * GET /items/123 HTTP/1.1\n   * Host: example.com\n   * Want-Content-Digest: sha-256=10, sha=3\n   * ```\n   *\n   * The server responds with a `Content-Digest` of the message content using the SHA-256 algorithm:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Type: application/json\n   * Content-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:\n   *\n   * {\"hello\": \"world\"}\n   * ```\n   *\n   * ### Identical Content-Digest and Repr-Digest values\n   *\n   * A user-agent requests a resource without a `Want-Content-Digest` field:\n   *\n   * ```http\n   * GET /items/123 HTTP/1.1\n   * Host: example.com\n   * ```\n   *\n   * The server is configured to send unsolicited digest headers in responses.\n   * The `Repr-Digest` and `Content-Digest` fields have matching values because they are using the same algorithm, and in this case the whole resource is sent in one message:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Type: application/json\n   * Content-Length: 19\n   * Content-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:\n   * Repr-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:\n   *\n   * {\"hello\": \"world\"}\n   * ```\n   *\n   * ### Diverging Content-Digest and Repr-Digest values\n   *\n   * If the same request is repeated as the previous example, but uses a [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) method instead of a [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET), the `Repr-Digest` and `Content-Digest` fields will be different:\n   *\n   * ```http\n   * GET /items/123 HTTP/1.1\n   * Host: example.com\n   * ```\n   *\n   * The `Repr-Digest` value will be the same as before, but there is no message body, so a different `Content-Digest` would be sent by the server:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Type: application/json\n   * Content-Digest: sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:\n   * Repr-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:\n   * ```\n   *\n   * ### User-agent sending a Content-Digest in requests\n   *\n   * In the following example, a user-agent sends a digest of the message content using SHA-512.\n   * It sends both a `Content-Digest` and a `Repr-Digest`, which differ from each other because of the `Content-Encoding`:\n   *\n   * ```http\n   * POST /bank_transfer HTTP/1.1\n   * Host: example.com\n   * Content-Encoding: zstd\n   * Content-Digest: sha-512=:ABC…=:\n   * Repr-Digest: sha-512=:DEF…=:\n   *\n   * {\n   *  \"recipient\": \"Alex\",\n   *  \"amount\": 900000000\n   * }\n   * ```\n   *\n   * The server may calculate a digest of the content it has received and compare the result with the `Content-Digest` or `Repr-Digest` headers to validate the message integrity.\n   * In requests like the example above, the `Repr-Digest` is more useful to the server as this is calculated over the decoded representation and would be more consistent in different scenarios.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * This header has no specification-defined browser integration (\"browser compatibility\" does not apply).\n   * Developers can set and get HTTP headers using `fetch()` in order to provide application-specific implementation behavior.\n   *\n   * ## See also\n   *\n   * - [Want-Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Content-Digest) header to request a content digest\n   * - [Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Repr-Digest), [Want-Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Repr-Digest) representation digest headers\n   * - [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag)\n   * - [Digital Signatures for APIs](https://developer.ebay.com/develop/guides/digital-signatures-for-apis) SDK guide uses `Content-Digest`s for digital signatures in HTTP calls (developer.ebay.com)\n   */\n  'Content-Digest' = 'Content-Digest',\n\n  /**\n   * The HTTP **`Content-Disposition`** header indicates whether content should be displayed _inline_ in the browser as a web page or part of a web page or downloaded as an _attachment_ locally.\n   *\n   * In a multipart body, the header must be used on each subpart to provide information about its corresponding field. The subpart is delimited by the _boundary_ defined in the [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) header. When used on the body itself, `Content-Disposition` has no effect.\n   *\n   * The `Content-Disposition` header is defined in the larger context of MIME messages for email, but only a subset of the possible parameters apply to HTTP forms and [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) requests. Only the value `form-data`, as well as the optional directive `name` and `filename`, can be used in the HTTP context.\n   *\n   *\n   * ```\n   *\n   * The HTML file will be downloaded rather than displayed in the browser.\n   * Most browsers will prompt users to save it with the `cool.html` file name by default (as specified in the `filename` directive).\n   *\n   * ### HTML posting multipart/form-data content type\n   *\n   * The following example shows an HTML form sent using `multipart/form-data` using the `Content-Disposition` header.\n   * In practice, the boundary value `delimiter123` would be a browser-generated string like `----8721656041911415653955004498`:\n   *\n   * ```http\n   * POST /test.html HTTP/1.1\n   * Host: example.org\n   * Content-Type: multipart/form-data;boundary=\"delimiter123\"\n   *\n   * --delimiter123\n   * Content-Disposition: form-data; name=\"field1\"\n   *\n   * value1\n   * --delimiter123\n   * Content-Disposition: form-data; name=\"field2\"; filename=\"example.txt\"\n   *\n   * value2\n   * --delimiter123--\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTML Forms](/en-US/docs/Learn_web_development/Extensions/Forms)\n   * - The [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) defining the boundary of the multipart body.\n   * - The [FormData](https://developer.mozilla.org/en-US/docs/domxref/FormData) interface used to prepare form data for use in the [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch) or [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest) APIs.\n   */\n  'Content-Disposition' = 'Content-Disposition',\n\n  /**\n   * The HTTP **`Content-DPR`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used to confirm the _image_ device to pixel ratio (DPR) in requests where the screen [DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DPR) client hint was used to select an image resource.\n   *\n   * > [!NOTE]\n   * > The `Content-DPR` header was removed from the client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07).\n   * > The [Responsive Image Client Hints](https://wicg.github.io/responsive-image-client-hints/) specification proposes to replace this header by specifying intrinsic resolution/dimensions in EXIF metadata.\n   *\n   * If the `DPR` client hint is used to select an image, the server must specify `Content-DPR` in the response.\n   * If the value in `Content-DPR` is different from the [DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DPR) value in the request (i.e., image DPR is not the same as screen DPR), the client must use the `Content-DPR` for determining intrinsic image size and scaling the image.\n   *\n   * If the `Content-DPR` header appears more than once in a message, the last occurrence is used.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Content-DPR: <number>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<number>`\n   *   - : The image device pixel ratio, calculated according to the following formula:\n   *     Content-DPR = _Selected image resource size_ / (_Width_ / _DPR_)\n   *\n   * ## Examples\n   *\n   * See the [`DPR`](/en-US/docs/Web/HTTP/Reference/Headers/DPR#examples) header example.\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - Device client hints\n   *   - [Device-Memory](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Device-Memory)\n   *   - [DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DPR)\n   *   - [Viewport-Width](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Viewport-Width)\n   *   - [Width](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Width)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) on developer.chrome.com (2020)\n   */\n  'Content-DPR' = 'Content-DPR',\n\n  /**\n   * The HTTP **`Content-Encoding`** [representation header](https://developer.mozilla.org/en-US/docs/Glossary/representation_header) lists the encodings and the order in which they have been applied to a resource.\n   * This lets the recipient know how to decode the data in order to obtain the original content format described in the [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) header.\n   * Content encoding is mainly used to compress content without losing information about the original media type.\n   *\n   * Servers should compress data as much as possible, and should use content encoding where appropriate.\n   * Compressing already compressed media types, such as .zip or .jpeg, is usually not appropriate because it can increase the file size.\n   * If the original media is already encoded (e.g., as a .zip file), this information is not included in the `Content-Encoding` header.\n   *\n   * When the `Content-Encoding` header is present, other metadata (e.g., [Content-Length](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length)) refer to the encoded form of the data, not the original resource, unless explicitly stated.\n   * Content encoding differs to [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding) in that `Transfer-Encoding` handles how HTTP messages themselves are delivered across the network on a [hop-by-hop basis](/en-US/docs/Web/HTTP/Reference/Headers#hop-by-hop_headers).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Content-Encoding: gzip\n   * Content-Encoding: compress\n   * Content-Encoding: deflate\n   * Content-Encoding: br\n   * Content-Encoding: zstd\n   * Content-Encoding: dcb\n   * Content-Encoding: dcz\n   *\n   * // Multiple, in the order in which they were applied\n   * Content-Encoding: deflate, gzip\n   * ```\n   *\n   * ## Directives\n   *\n   * - `gzip`\n   *   - : A format using the [Lempel-Ziv coding](https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) (LZ77), with a 32-bit CRC.\n   *     This is the original format of the UNIX _gzip_ program.\n   *     The HTTP/1.1 standard also recommends that the servers supporting this content-encoding should recognize `x-gzip` as an alias, for compatibility purposes.\n   * - `compress`\n   *   - : A format using the [Lempel-Ziv-Welch](https://en.wikipedia.org/wiki/LZW) (LZW) algorithm.\n   *     The value name was taken from the UNIX _compress_ program, which implemented this algorithm.\n   *     Like the compress program, which has disappeared from most UNIX distributions, this content-encoding is not used by many browsers today, partly because of a patent issue (it expired in 2003).\n   * - `deflate`\n   *   - : Using the [zlib](https://en.wikipedia.org/wiki/Zlib) structure (defined in ) with the [deflate](https://en.wikipedia.org/wiki/Deflate) compression algorithm (defined in ).\n   * - `br`\n   *   - : A format using the [Brotli](https://developer.mozilla.org/en-US/docs/glossary/Brotli_compression) algorithm structure (defined in ).\n   * - `zstd`\n   *   - : A format using the [Zstandard](https://developer.mozilla.org/en-US/docs/glossary/Zstandard_compression) algorithm structure (defined in ).\n   * - `dcb`\n   *   - : A format that uses the [Dictionary-Compressed Brotli algorithm](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-compression-dictionary#name-dictionary-compressed-brotl). See [Compression Dictionary Transport](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport).\n   *\n   * - `dcz`\n   *   - : A format that uses the [Dictionary-Compressed Zstandard algorithm](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-compression-dictionary#name-dictionary-compressed-zstan). See [Compression Dictionary Transport](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport).\n   *\n   * ## Examples\n   *\n   * ### Compressing with gzip\n   *\n   * On the client side, you can advertise a list of compression schemes that will be sent along in an HTTP request. The [Accept-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding) header is used for negotiating content encoding.\n   *\n   * ```http\n   * Accept-Encoding: gzip, deflate\n   * ```\n   *\n   * The server responds with the scheme used, indicated by the `Content-Encoding` response header.\n   *\n   * ```http\n   * Content-Encoding: gzip\n   * ```\n   *\n   * Whether a server uses compression methods requested by the client depends on server configuration and capabilities.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Accept-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding)\n   * - [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding)\n   * - [Brotli compression](https://developer.mozilla.org/en-US/docs/Glossary/Brotli_compression)\n   * - [GZip compression](https://developer.mozilla.org/en-US/docs/Glossary/GZip_compression)\n   * - [Zstandard compression](https://developer.mozilla.org/en-US/docs/Glossary/Zstandard_compression)\n   * - [Compression Dictionary Transport guide](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport)\n   */\n  'Content-Encoding' = 'Content-Encoding',\n\n  /**\n   * The HTTP **`Content-Language`** [representation header](https://developer.mozilla.org/en-US/docs/Glossary/representation_header) is used to describe the language(s) intended for the audience, so users can differentiate it according to their own preferred language.\n   *\n   * For example, `Content-Language: de-DE` indicates that the document is intended for German language speakers. The document may be written in English, not German, as part of a language course for German speakers. To indicate the language the document is **written in**, use the [`lang`](/en-US/docs/Web/HTML/Reference/Global_attributes/lang) attribute instead.\n   *\n   * If no `Content-Language` is specified, the default is that the content is intended for all language audiences. Multiple language tags are also possible, as well as applying the `Content-Language` header to various media types and not only to textual documents.\n   *\n   *\n   * ```\n   *\n   * Do **not** use this meta element to state the document language, as shown below:\n   *\n   * ```html example-bad\n   * <meta http-equiv=\"content-language\" content=\"de\" />\n   * ```\n   *\n   * ### Indicating a target audience for a resource\n   *\n   * The `Content-Language` header is used to specify the **page's intended audience** and can indicate that this is more than one language.\n   *\n   * ```http\n   * Content-Language: de, en\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Accept-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language)\n   * - [HTTP headers, meta elements and language information](https://www.w3.org/International/questions/qa-http-and-lang.en)\n   * - [HTML `lang` attribute](/en-US/docs/Web/HTML/Reference/Global_attributes/lang)\n   */\n  'Content-Language' = 'Content-Language',\n\n  /**\n   * The HTTP **`Content-Length`** header indicates the size, in bytes, of the message body sent to the recipient.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Content-Length: <length>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<length>`\n   *   - : The length in octets.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding)\n   */\n  'Content-Length' = 'Content-Length',\n\n  /**\n   * The HTTP **`Content-Location`** [representation header](https://developer.mozilla.org/en-US/docs/Glossary/representation_header) indicates an alternate location for the returned data.\n   * It's main use is to indicate the URL of a resource transmitted as the result of [content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation).\n   *\n   * The `Content-Location` header is different from the [Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location) header.\n   * `Content-Location` indicates the direct URL to access the resource when [content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation) has happened, allowing the client to bypass future content negotiation for this resource.\n   * `Location`, on the other hand, indicates either the target of a `3XX` redirection or the URL of a newly created resource in a [201 Created](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201) response.\n   *\n   *\n   *\n   * (Lots more HTML…)\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location)\n   */\n  'Content-Location' = 'Content-Location',\n\n  /**\n   * The HTTP **`Content-Range`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used in [range requests](/en-US/docs/Web/HTTP/Guides/Range_requests) to indicate where the content of a response body belongs in relation to a complete resource.\n   *\n   * It should only be included in [206 Partial Content](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206) or [416 Range Not Satisfiable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416) responses.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Content-Range: <unit> <range>/<size>\n   * Content-Range: <unit> <range>/*\n   * Content-Range: <unit> * /<size>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<unit>`\n   *   - : The unit for specifying ranges.\n   *     Currently, only `bytes` is supported.\n   * - `<range>`\n   *   - : A range with the format `<range-start>-<range-end>`, where `<range-start>` and `<range-end>` are integers for the start and end position (zero-indexed & inclusive) of the range in the given `<unit>`, respectively.\n   *     `*` is used in a [416 Range Not Satisfiable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416) response to indicate that the value is not a range.\n   * - `<size>`\n   *   - : The total length of the document (or `*` if unknown).\n   *\n   * ## Examples\n   *\n   * ### Partial content response\n   *\n   * This [206 Partial Content](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206) response shows a partial response, with the `Content-Range` indicating that it contains the first 1024 bytes of a 146515 byte file.\n   *\n   * ```http\n   * HTTP/2 206\n   * content-type: image/jpeg\n   * content-length: 1024\n   * content-range: bytes 0-1023/146515\n   * …\n   *\n   * (binary content)\n   * ```\n   *\n   * ### Range not satisfiable\n   *\n   * If the server cannot satisfy the requested range request, it should respond with a [416 Range Not Satisfiable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416) status, and the `Content-Range` should specify `*` for the range along with the total size of the resource.\n   *\n   * ```http\n   * HTTP/2 416\n   *\n   * Content-Range: bytes * /67589\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTTP range requests](/en-US/docs/Web/HTTP/Guides/Range_requests) guide\n   * - [If-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Range), [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) headers\n   * - [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type)\n   * - [206 Partial Content](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206), [416 Range Not Satisfiable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416) status codes\n   */\n  'Content-Range' = 'Content-Range',\n\n  /**\n   * The HTTP **`Content-Security-Policy-Report-Only`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) helps to monitor Content Security Policy (CSP) violations and their effects without enforcing the security policies.\n   * This header allows you to test or repair violations before a specific [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) is applied and enforced.\n   *\n   * The CSP [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive must be specified for reports to be sent: if not, the operation won't have any effect.\n   *\n   * Violation reports are sent using the [Reporting API](/en-US/docs/Web/API/Reporting_API) to endpoints defined in a [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Reporting-Endpoints) HTTP response header and selected using the CSP [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive.\n   *\n   * For more information, see our [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/Guides/CSP) guide.\n   *\n   * > [!NOTE]\n   * > The header can also be used with the deprecated [report-uri](https://developer.mozilla.org/en-US/docs/CSP/report-uri) directive (this is being replaced by [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to)).\n   * > The usage and resulting report syntax is slightly different; see the [report-uri](https://developer.mozilla.org/en-US/docs/CSP/report-uri) topic for more details.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Content-Security-Policy-Report-Only: <policy-directive>; …; <policy-directive>; report-to <endpoint-name>\n   * ```\n   *\n   * ## Directives\n   *\n   * The `Content-Security-Policy-Report-Only` header supports all [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) directives except `sandbox`, which is ignored.\n   *\n   * > [!NOTE]\n   * > The CSP [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive should be used with this header or it will have no effect.\n   *\n   * ## Examples\n   *\n   * ### Using Content-Security-Policy-Report-Only to send CSP reports\n   *\n   * To use the [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive, you first need to define a corresponding endpoint using the [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Reporting-Endpoints) response header.\n   * In the example below, we define a single endpoint named `csp-endpoint`.\n   *\n   * ```http\n   * Reporting-Endpoints: csp-endpoint=\"https://example.com/csp-reports\"\n   * ```\n   *\n   * We can then define the destination of the report using [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) and [report-uri](https://developer.mozilla.org/en-US/docs/CSP/report-uri), as shown below.\n   * Note that this particular report would be triggered if the page loaded resources insecurely, or from inline code.\n   *\n   * ```http\n   * Content-Security-Policy-Report-Only: default-src https:;\n   *   report-uri /csp-report-url/;\n   *   report-to csp-endpoint;\n   * ```\n   *\n   * > [!NOTE]\n   * > The `report-to` directive is preferred over the deprecated `report-uri`, but we declare both because `report-to` does not yet have full cross-browser support.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)\n   * - CSP [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive\n   * - CSP [report-uri](https://developer.mozilla.org/en-US/docs/CSP/report-uri) directive\n   */\n  'Content-Security-Policy-Report-Only' = 'Content-Security-Policy-Report-Only',\n\n  /**\n   * The HTTP **`Content-Security-Policy`** response header allows website administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints.\n   * This helps guard against [cross-site scripting](https://developer.mozilla.org/en-US/docs/Glossary/cross-site_scripting) attacks.\n   *\n   * See the [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/Guides/CSP) guide for details about how a CSP is delivered to the browser, what it looks like, along with use cases and deployment strategies.\n   *\n   *\n   * > ```\n   * >\n   * > If an attacker can inject an inline `<script>` element containing this code, the CSP will allow it to execute automatically.\n   * >\n   * > However, `'unsafe-hashes'` is much safer than `'unsafe-inline'`.\n   *\n   * ### 'inline-speculation-rules'\n   *\n   * By default, if a CSP contains a `default-src` or a `script-src` directive, then inline JavaScript is not allowed to execute. The `'inline-speculation-rules'` allows the browser to load inline `<script>` elements that have a [`type`](/en-US/docs/Web/HTML/Reference/Elements/script/type) attribute of [`speculationrules`](/en-US/docs/Web/HTML/Reference/Elements/script/type/speculationrules).\n   *\n   * See the [Speculation Rules API](/en-US/docs/Web/API/Speculation_Rules_API) for more information.\n   *\n   * ### 'strict-dynamic'\n   *\n   * The `'strict-dynamic'` keyword makes the trust conferred on a script by a [nonce](#nonce-nonce_value) or a [hash](#hash_algorithm-hash_value) extend to scripts that this script dynamically loads, for example by creating new `<script>` tags using [Document.createElement()](https://developer.mozilla.org/en-US/docs/domxref/Document.createElement()) and then inserting them into the document using [Node.appendChild()](https://developer.mozilla.org/en-US/docs/domxref/Node.appendChild()).\n   *\n   * If this keyword is present in a directive, then the following source expression values are all ignored:\n   *\n   * - [\\<host-source>](#host-source)\n   * - [\\<scheme-source>](#scheme-source)\n   * - [`'self'`](#self)\n   * - [`'unsafe-inline'`](#unsafe-inline)\n   *\n   * See [The `strict-dynamic` keyword](/en-US/docs/Web/HTTP/Guides/CSP#the_strict-dynamic_keyword) in the CSP guide for more usage information.\n   *\n   * ### 'report-sample'\n   *\n   * If this expression is included in a directive controlling scripts or styles, and the directive causes the browser to block any inline scripts, inline styles, or event handler attributes, then the [violation report](/en-US/docs/Web/HTTP/Guides/CSP#violation_reporting) that the browser generates will contain a [sample](https://developer.mozilla.org/en-US/docs/domxref/CSPViolationReportBody.sample) property containing the first 40 characters of the blocked resource.\n   *\n   * ## CSP in workers\n   *\n   * [Workers](/en-US/docs/Web/API/Worker) are in general _not_ governed\n   * by the content security policy of the document (or parent worker) that created them. To\n   * specify a content security policy for the worker, set a\n   * `Content-Security-Policy` response header for the request which requested the\n   * worker script itself.\n   *\n   * The exception to this is if the worker script's origin is a globally unique identifier\n   * (for example, if its URL has a scheme of data or blob). In this case, the worker does\n   * inherit the content security policy of the document or worker that created it.\n   *\n   * ## Multiple content security policies\n   *\n   * The CSP mechanism allows multiple policies being specified for a resource, including\n   * via the `Content-Security-Policy` header, the\n   * [Content-Security-Policy-Report-Only](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only) header and a\n   * [meta](https://developer.mozilla.org/en-US/docs/HTMLElement/meta) element.\n   *\n   * You can use the `Content-Security-Policy` header more than once, as in the\n   * example below. Pay special attention to the [connect-src](https://developer.mozilla.org/en-US/docs/CSP/connect-src) directive here. Even\n   * though the second policy would allow the connection, the first policy contains\n   * `connect-src 'none'`. Adding additional policies _can only further\n   * restrict_ the capabilities of the protected resource, which means that there will\n   * be no connection allowed and, as the strictest policy, `connect-src 'none'`\n   * is enforced.\n   *\n   * ```http\n   * Content-Security-Policy: default-src 'self' http://example.com;\n   *                           connect-src 'none';\n   * Content-Security-Policy: connect-src http://example.com/;\n   *                           script-src http://example.com/\n   * ```\n   *\n   * ## Examples\n   *\n   * ### Disable unsafe inline code and only allow HTTPS resources\n   *\n   * This HTTP header sets the default policy to only allow resource loading (images, fonts, scripts, etc.) over HTTPS.\n   * Because the `unsafe-inline` and `unsafe-eval` directives are not set, inline scripts will be blocked.\n   *\n   * ```http\n   * Content-Security-Policy: default-src https:\n   * ```\n   *\n   * The same restrictions can be applied using the HTML [meta](https://developer.mozilla.org/en-US/docs/htmlelement/meta) element.\n   *\n   * ```html\n   * <meta http-equiv=\"Content-Security-Policy\" content=\"default-src https:\" />\n   * ```\n   *\n   * ### Allow inline code and HTTPS resources, but disable plugins\n   *\n   * This policy could be used on a pre-existing site that uses too much inline code to fix, to ensure resources are loaded only over HTTPS and disable plugins:\n   *\n   * ```http\n   * Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'\n   * ```\n   *\n   * ### Report but don't enforce violations when testing\n   *\n   * This example sets the same restrictions as the previous example, but using the [Content-Security-Policy-Report-Only](https://developer.mozilla.org/en-US/docs/httpheader/Content-Security-Policy-Report-Only) header and the [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive.\n   * This approach is used during testing to report violations but not block code from executing.\n   *\n   * Endpoints (URLs) to send reports to are defined using the [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Reporting-Endpoints) HTTP response header.\n   *\n   * ```http\n   * Reporting-Endpoints: csp-endpoint=\"https://example.com/csp-reports\"\n   * ```\n   *\n   * A particular endpoint is then selected as the report target in the CSP policy using the [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive.\n   *\n   * ```http\n   * Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-url/; report-to csp-endpoint\n   * ```\n   *\n   * Note that the [report-uri](https://developer.mozilla.org/en-US/docs/CSP/report-uri)  directive is also specified above because `report-to` is not yet broadly supported by browsers.\n   *\n   * See [Content Security Policy (CSP) implementation](/en-US/docs/Web/Security/Practical_implementation_guides/CSP) for more examples.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Content-Security-Policy-Report-Only](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only)\n   * - [Learn about: Content Security Policy](/en-US/docs/Web/HTTP/Guides/CSP)\n   * - [Content Security in WebExtensions](/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy)\n   * - [Adopting a strict policy](https://csp.withgoogle.com/docs/strict-csp.html)\n   * - [CSP Evaluator](https://github.com/google/csp-evaluator) - Evaluate your\n   *   Content Security Policy\n   */\n  'Content-Security-Policy' = 'Content-Security-Policy',\n\n  /**\n   * The HTTP **`Content-Type`** [representation header](https://developer.mozilla.org/en-US/docs/Glossary/representation_header) is used to indicate the original [media type](https://developer.mozilla.org/en-US/docs/Glossary/MIME_type) of a resource before any content encoding is applied.\n   *\n   * In responses, the `Content-Type` header informs the client about the media type of the returned data.\n   * In requests such as [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) or [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT), the client uses the `Content-Type` header to specify the type of content being sent to the server.\n   * If a server implementation or configuration is strict about content type handling, a [415](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415) client error response may be returned.\n   *\n   * The `Content-Type` header differs from [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) in that `Content-Encoding` helps the recipient understand how to decode data to its original form.\n   *\n   * > [!NOTE]\n   * > This value may be ignored if browsers perform [MIME sniffing](/en-US/docs/Web/HTTP/Guides/MIME_types#mime_sniffing) (or content sniffing) on responses.\n   * > To prevent browsers from using MIME sniffing, set the [X-Content-Type-Options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options) header value to `nosniff`.\n   * > See [MIME type verification](/en-US/docs/Web/Security/Practical_implementation_guides/MIME_types) for more details.\n   *\n   *\n   * ```\n   *\n   * ```http\n   * POST /submit HTTP/1.1\n   * Host: example.com\n   * Content-Type: application/x-www-form-urlencoded\n   * Content-Length: 15\n   *\n   * comment=Hello!\n   * ```\n   *\n   * ### `Content-Type` in a REST API using JSON\n   *\n   * Many [REST](https://developer.mozilla.org/en-US/docs/Glossary/REST) APIs use `application/json` as a content type which is convenient for machine-to-machine communication or programmatic interaction.\n   * The following example shows a [201 Created](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201) response showing the result of a successful request:\n   *\n   * ```http\n   * HTTP/1.1 201 Created\n   * Content-Type: application/json\n   *\n   * {\n   *   \"message\": \"New user created\",\n   *   \"user\": {\n   *     \"id\": 123,\n   *     \"firstName\": \"Paul\",\n   *     \"lastName\": \"Klee\",\n   *     \"email\": \"p.klee@example.com\"\n   *   }\n   * }\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept), [Accept-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding), [Accept-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language) headers\n   * - [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   * - [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding)\n   * - [Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)\n   * - [206 Partial Content](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206)\n   * - [X-Content-Type-Options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options)\n   */\n  'Content-Type' = 'Content-Type',\n\n  /**\n   * The HTTP **`Cookie`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) contains stored [HTTP cookies](/en-US/docs/Web/HTTP/Guides/Cookies) associated with the server (i.e., previously sent by the server with the [Set-Cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie) header or set in JavaScript using [Document.cookie](https://developer.mozilla.org/en-US/docs/domxref/Document.cookie)).\n   *\n   * The `Cookie` header is optional and may be omitted if, for example, the browser's privacy settings block cookies.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Cookie: <cookie-list>\n   * Cookie: name=value\n   * Cookie: name=value; name2=value2; name3=value3\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<cookie-list>`\n   *   - : A list of name-value pairs in the form of `<cookie-name>=<cookie-value>`.\n   *     Pairs in the list are separated by a semicolon and a space.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [413 Content Too Large](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413)\n   * - [Set-Cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie)\n   * - [Document.cookie](https://developer.mozilla.org/en-US/docs/domxref/Document.cookie)\n   */\n  'Cookie' = 'Cookie',\n\n  /**\n   * The HTTP **`Critical-CH`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used along with [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) to identify the accepted [client hints](/en-US/docs/Web/HTTP/Guides/Client_hints) that are [critical](/en-US/docs/Web/HTTP/Guides/Client_hints#critical_client_hints).\n   *\n   * User agents receiving a response with `Critical-CH` must check if the indicated critical headers were sent in the original request. If not, the user agent will retry the request along with the critical headers rather than render the page. This approach ensures that client preferences set using critical client hints are always used, even if not included in the first request, or following server configuration changes.\n   *\n   * Each header listed in the `Critical-CH` header should also be present in the `Accept-CH` and `Vary` headers.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Critical-CH: <ch-list>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<ch-list>`\n   *   - : A list of one or more comma-delimited client hint headers that the server considers to be critical client hints.\n   *\n   * ## Examples\n   *\n   * The client makes an initial request to the server:\n   *\n   * ```http\n   * GET / HTTP/1.1\n   * Host: example.com\n   * ```\n   *\n   * The server responds, indicating via [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) that it accepts [Sec-CH-Prefers-Reduced-Motion](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-Prefers-Reduced-Motion). In this example, `Critical-CH` is also used to specify that `Sec-CH-Prefers-Reduced-Motion` is considered a critical client hint.\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Type: text/html\n   * Accept-CH: Sec-CH-Prefers-Reduced-Motion\n   * Vary: Sec-CH-Prefers-Reduced-Motion\n   * Critical-CH: Sec-CH-Prefers-Reduced-Motion\n   * ```\n   *\n   * > [!NOTE]\n   * > We've specified `Sec-CH-Prefers-Reduced-Motion` in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header to indicate that responses should be separately cached based on the value of this header (even if the URL stays the same).\n   * > Each header listed in the `Critical-CH` header should also be present in the `Accept-CH` and `Vary` headers.\n   *\n   * The client automatically retries the request (due to `Critical-CH` being specified above), telling the server via `Sec-CH-Prefers-Reduced-Motion` that it has a user preference for reduced-motion animations:\n   *\n   * ```http\n   * GET / HTTP/1.1\n   * Host: example.com\n   * Sec-CH-Prefers-Reduced-Motion: \"reduce\"\n   * ```\n   *\n   * The client will include the header in subsequent requests in the current session unless the `Accept-CH` changes in responses to indicate that it is no longer supported by the server.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   * - [PerformanceNavigationTiming.criticalCHRestart](https://developer.mozilla.org/en-US/docs/domxref/PerformanceNavigationTiming.criticalCHRestart)\n   */\n  'Critical-CH' = 'Critical-CH',\n\n  /**\n   * The HTTP **`Cross-Origin-Embedder-Policy`** (COEP) [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) configures the current document's policy for loading and embedding cross-origin resources.\n   *\n   * The policy for whether a particular resource is embeddable cross-site may be defined for that resource using the [Cross-Origin-Resource-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy) (CORP) header for a `no-cors` fetch, or using [CORS](/en-US/docs/Web/HTTP/Guides/CORS).\n   * If neither of these policies are set, then by default, resources can be loaded or embedded into a document as though they had a CORP value of `cross-site`.\n   *\n   * The **`Cross-Origin-Embedder-Policy`** allows you to require that CORP or CORS headers be set in order to load cross-site resources into the current document.\n   * You can also set the policy to keep the default behavior, or to allow the resources to be loaded, but strip any credentials that might otherwise be sent.\n   * The policy applies to loaded resources, and resources in [iframe](https://developer.mozilla.org/en-US/docs/htmlelement/iframe)s and nested frames.\n   *\n   * > [!NOTE]\n   * > The `Cross-Origin-Embedder-Policy` doesn't override or affect the embedding behavior for a resource for which CORP or CORS has been set.\n   * > If CORP restricts a resource to being embedded only `same-origin`, it won't be loaded cross-origin into a resource irrespective of the COEP value.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Cross-Origin-Embedder-Policy: unsafe-none | require-corp | credentialless\n   * ```\n   *\n   * ### Directives\n   *\n   * - `unsafe-none`\n   *   - : Allows the document to load cross-origin resources **without** giving explicit permission through the CORS protocol or the [Cross-Origin-Resource-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy) header.\n   *     This is the default value.\n   * - `require-corp`\n   *   - : A document can only load resources from the same origin, or resources explicitly marked as loadable from another origin.\n   *\n   *     Cross-origin resource loading will be blocked by COEP unless:\n   *     - The resource is requested in `no-cors` mode and the response includes a [Cross-Origin-Resource-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy) header that allows it to be loaded into the document origin.\n   *     - The resource is requested in `cors` mode and the resource supports and is permitted by CORS.\n   *       This can be done, for example, in HTML using the [`crossorigin`](/en-US/docs/Web/HTML/Reference/Attributes/crossorigin) attribute, or in JavaScript by making a request with [`{mode=\"cors\"}`](/en-US/docs/Web/API/RequestInit#cors).\n   *\n   * - `credentialless`\n   *   - : A document can load cross-origin resources that are requested in [`no-cors` mode](/en-US/docs/Web/API/Request/mode) **without** an explicit permission via the [Cross-Origin-Resource-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy) header.\n   *     In this case requests are sent without credentials: cookies are omitted in the request, and ignored in the response.\n   *\n   *     The cross-origin loading behavior for other [request modes](/en-US/docs/Web/API/Request/mode#cors) is the same as for [`require-corp`](#require-corp).\n   *     For example, a cross-origin resource requested in `cors` mode must support (and be permitted by) CORS.\n   *\n   * ## Examples\n   *\n   * ### Features that depend on cross-origin isolation\n   *\n   * Certain features, such as access to [SharedArrayBuffer](https://developer.mozilla.org/en-US/docs/jsxref/SharedArrayBuffer) objects or using [Performance.now()](https://developer.mozilla.org/en-US/docs/domxref/Performance.now()) with unthrottled timers, are only available if your document is [cross-origin isolated\",\"\",\"nocode](https://developer.mozilla.org/en-US/docs/domxref/Window.crossOriginIsolated).\n   *\n   * To use these features in a document, you will need to set the COEP header with a value of `require-corp` or `credentialless`, and the [Cross-Origin-Opener-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) header to `same-origin`.\n   * In addition the feature must not be blocked by [Permissions-Policy: cross-origin-isolated](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/cross-origin-isolated).\n   *\n   * ```http\n   * Cross-Origin-Opener-Policy: same-origin\n   * Cross-Origin-Embedder-Policy: require-corp\n   * ```\n   *\n   * You can use the [Window.crossOriginIsolated](https://developer.mozilla.org/en-US/docs/domxref/Window.crossOriginIsolated) and [WorkerGlobalScope.crossOriginIsolated](https://developer.mozilla.org/en-US/docs/domxref/WorkerGlobalScope.crossOriginIsolated) properties to check if the features are restricted in window and worker contexts, respectively:\n   *\n   * ```js\n   * const myWorker = new Worker(\"worker.js\");\n   *\n   * if (crossOriginIsolated) {\n   *   const buffer = new SharedArrayBuffer(16);\n   *   myWorker.postMessage(buffer);\n   * } else {\n   *   const buffer = new ArrayBuffer(16);\n   *   myWorker.postMessage(buffer);\n   * }\n   * ```\n   *\n   * ### Avoiding COEP blockage with CORS\n   *\n   * If you enable COEP using `require-corp` and want to embed a cross origin resource that supports [CORS](/en-US/docs/Web/HTTP/Guides/CORS), you will need to explicitly specify that it is requested in `cors` mode.\n   *\n   * For example, to fetch an image declared in HTML from a third-party site that supports CORS, you can use the [`crossorigin`](/en-US/docs/Web/HTML/Reference/Attributes/crossorigin) attribute so that it is requested in `cors` mode:\n   *\n   * ```html\n   * <img src=\"https://thirdparty.com/img.png\" crossorigin />\n   * ```\n   *\n   * You can similarly use the [`HTMLScriptElement.crossOrigin`](/en-US/docs/Web/API/HTMLScriptElement/crossOrigin) attribute or fetch with `{ mode: 'cors' }` to request a file in CORS mode using JavaScript.\n   *\n   * If CORS is not supported for some images, a COEP value of `credentialless` can be used as an alternative to load the image without any explicit opt-in from the cross-origin server, at the cost of requesting it without cookies.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Cross-Origin-Opener-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy)\n   * - [Window.crossOriginIsolated](https://developer.mozilla.org/en-US/docs/domxref/Window.crossOriginIsolated) and [WorkerGlobalScope.crossOriginIsolated](https://developer.mozilla.org/en-US/docs/domxref/WorkerGlobalScope.crossOriginIsolated)\n   * - [Cross Origin Opener Policy](https://web.dev/articles/why-coop-coep#coep) in _Why you need \"cross-origin isolated\" for powerful features_ on web.dev (2020)\n   * - [COOP and COEP explained: Artur Janc, Charlie Reis, Anne van Kesteren](https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit?tab=t.0) (2020)\n   */\n  'Cross-Origin-Embedder-Policy' = 'Cross-Origin-Embedder-Policy',\n\n  /**\n   * The HTTP **`Cross-Origin-Opener-Policy`** (COOP) [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) allows a website to control whether a new top-level document, opened using [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()) or by navigating to a new page, is opened in the same [browsing context group](https://developer.mozilla.org/en-US/docs/glossary/Browsing_context) (BCG) or in a new browsing context group.\n   *\n   * When opened in a new BCG, any references between the new document and its opener are severed, and the new document may be process-isolated from its opener.\n   * This ensures that potential attackers can't open your documents with [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()) and then use the returned value to access its global object, and thereby prevents a set of cross-origin attacks referred to as [XS-Leaks](https://xsleaks.dev/).\n   *\n   * It also means that any object opened by your document in a new BCG can't access it using [`window.opener`](/en-US/docs/Web/API/Window/opener).\n   * This allows you to have more control over references to a window than [`rel=noopener`](/en-US/docs/Web/HTML/Reference/Attributes/rel/noopener), which affects outgoing navigations but not documents opened with [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()).\n   *\n   * The behavior depends on the policies of both the new document and its opener, and whether the new document is opened following a navigation or using [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Cross-Origin-Opener-Policy: unsafe-none\n   * Cross-Origin-Opener-Policy: same-origin-allow-popups\n   * Cross-Origin-Opener-Policy: same-origin\n   * Cross-Origin-Opener-Policy: noopener-allow-popups\n   * ```\n   *\n   * ### Directives\n   *\n   * - `unsafe-none`\n   *   - : The document permits sharing its browsing context group with any other document, and may therefore be unsafe.\n   *     It is used to opt-out a document from using COOP for process isolation.\n   *     This is the default value.\n   *\n   *     On navigations, documents with `unsafe-none` will always open and be opened into a new BCG — unless the other document also has `unsafe-none` (or no COOP directive value).\n   *\n   *     Using `Window.open()`, documents with `unsafe-none` will always open documents with any other value into a new BCG.\n   *     However documents with `unsafe-none` can be opened in the same BCG if the opener has the directive `same-origin-allow-popups`, `noopener-allow-popups`, or `unsafe-none`.\n   *     A document with `same-origin` will always open a document with `unsafe-none` in a new BCG.\n   *\n   * - `same-origin`\n   *   - : The document permits loading into BCGs that use COOP and contain only same-origin documents.\n   *     This is used to provide [cross-origin isolation](/en-US/docs/Web/API/Window/crossOriginIsolated) for a BCG.\n   *\n   *     Documents with `same-origin` will only open and be opened in the same BCG if both documents are same-origin and have the `same-origin` directive.\n   *\n   * - `same-origin-allow-popups`\n   *   - : This is similar to [`same-origin`](#same-origin) directive, except that it allows the opening of documents using [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()) in the same BCG if they have a COOP value of `unsafe-none`.\n   *\n   *     The directive is used to relax the `same-origin` restriction for integrations where a document needs the benefits of cross-origin isolation but also needs to open and retain a reference to trusted cross-origin documents.\n   *     For example, when using a cross-origin service for OAuth or payments.\n   *\n   *     A document with this directive can open a document in the same BCG using [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()) if it has a COOP value of `unsafe-none`.\n   *     In this case it does not matter if the opened document is cross-site or same-site.\n   *\n   *     Otherwise documents with `same-origin-allow-popups` will only open and be opened in the same BCG if both documents are same-origin and have the `same-origin-allow-popups` directive.\n   *\n   * - `noopener-allow-popups`\n   *   - : Documents with this directive are always opened into a new BCG, except when opened by navigating from a document that also has `noopener-allow-popups`.\n   *     It is used to support cases where there is a need to process-isolate _same-origin_ documents.\n   *\n   *     This severs the connections between the new document and its opener, isolating the browsing context for the current document regardless of the opener document's origin.\n   *     This ensures that the opener can't run scripts in opened documents and vice versa — even if they are same-origin.\n   *\n   *     On navigations, a document with this directive will always open other documents in a new BCG unless they are same-origin and have the directive `noopener-allow-popups`.\n   *     Using [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()), a document with this directive will open documents in a new BCG unless they have `unsafe-none`, and in this case it does not matter if they are same-site or cross-site.\n   *\n   * ## Description\n   *\n   * Generally you should set your policies such that only same-origin and trusted cross-origin resources that need to be able to script each other should be allowed to be opened in the same browser context group.\n   * Other resources should be cross-origin isolated in their own group.\n   *\n   * The following sections show whether documents will be opened in the same BCG or a new BCG following a navigation or opening a window programmatically.\n   *\n   * > [!NOTE]\n   * > The specification uses the term \"popup\" to refer to any document opened using [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()), whether it is a popup, tab, window, or other context.\n   *\n   * ### Navigations\n   *\n   * When navigating between documents, the new document is opened in the same BCG if the two documents have \"matching coop policies\", and otherwise into a new BCG.\n   *\n   * The policies match if either both documents have the policy `unsafe-none`, or if the policies are the same and the documents are same-origin.\n   *\n   * The table below shows how this rule affects whether documents are opened in the same or a new BCG for the different directive values.\n   *\n   * <!-- https://html.spec.whatwg.org/multipage/browsers.html#matching-coop -->\n   *\n   * | Opener (↓) / Opened (→)    | `unsafe-none` | `same-origin-allow-popups` | `same-origin`       | `noopener-allow-popups` |\n   * | -------------------------- | ------------- | -------------------------- | ------------------- | ----------------------- |\n   * | `unsafe-none`              | Same          | New                        | New                 | New                     |\n   * | `same-origin-allow-popups` | New           | Same if same-origin        | New                 | New                     |\n   * | `same-origin`              | New           | New                        | Same if same-origin | New                     |\n   * | `noopener-allow-popups`    | New           | New                        | New                 | Same if same-origin     |\n   *\n   * ### Opening with Window.open()\n   *\n   * When opening a document using `Window.open()`, the new document is opened in a new BCG according to the following rules, which are evaluated in order:\n   *\n   * 1. If the new document has COOP set to `noopener-allow-popups` => open the new document in a new BCG\n   * 2. If the new document has COOP set to `unsafe-none` and the opener document has COOP set to either `same-origin-allow-popups` or `noopener-allow-popups` => open the new document in the same BCG\n   * 3. If the new document and the opening document have [matching COOP policies](#navigations) => open the new document in the same BCG\n   * 4. Otherwise, open the new document in a new BCG\n   *\n   * The table below shows how these rules affect whether documents are opened in the same or a new BCG for the different directive values.\n   *\n   * <!-- https://html.spec.whatwg.org/multipage/browsers.html#check-browsing-context-group-switch-coop-value-popup -->\n   *\n   * | Opener (↓) / Opened (→)    | `unsafe-none` | `same-origin-allow-popups` | `same-origin`       | `noopener-allow-popups` |\n   * | -------------------------- | ------------- | -------------------------- | ------------------- | ----------------------- |\n   * | `unsafe-none`              | Same          | New                        | New                 | New                     |\n   * | `same-origin-allow-popups` | Same          | Same if same-origin        | New                 | New                     |\n   * | `same-origin`              | New           | New                        | Same if same-origin | New                     |\n   * | `noopener-allow-popups`    | Same          | New                        | New                 | New                     |\n   *\n   * ## Examples\n   *\n   * ### Features that depend on cross-origin isolation\n   *\n   * Certain features, such as access to [SharedArrayBuffer](https://developer.mozilla.org/en-US/docs/jsxref/SharedArrayBuffer) objects or using [Performance.now()](https://developer.mozilla.org/en-US/docs/domxref/Performance.now()) with unthrottled timers, are only available if your document is [cross-origin isolated\",\"\",\"nocode](https://developer.mozilla.org/en-US/docs/domxref/Window.crossOriginIsolated).\n   *\n   * To use these features in a document, you will need to set the COOP header to `same-origin` and the [Cross-Origin-Embedder-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy) header to `require-corp` (or `credentialless`).\n   * In addition the feature must not be blocked by [Permissions-Policy: cross-origin-isolated](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/cross-origin-isolated).\n   *\n   * ```http\n   * Cross-Origin-Opener-Policy: same-origin\n   * Cross-Origin-Embedder-Policy: require-corp\n   * ```\n   *\n   * You can use the [Window.crossOriginIsolated](https://developer.mozilla.org/en-US/docs/domxref/Window.crossOriginIsolated) and [WorkerGlobalScope.crossOriginIsolated](https://developer.mozilla.org/en-US/docs/domxref/WorkerGlobalScope.crossOriginIsolated) properties to check if a document is cross-origin isolated, and hence whether or not the features are restricted:\n   *\n   * ```js\n   * const myWorker = new Worker(\"worker.js\");\n   *\n   * if (crossOriginIsolated) {\n   *   const buffer = new SharedArrayBuffer(16);\n   *   myWorker.postMessage(buffer);\n   * } else {\n   *   const buffer = new ArrayBuffer(16);\n   *   myWorker.postMessage(buffer);\n   * }\n   * ```\n   *\n   * ### Severing the opener relationship\n   *\n   * Consider a hypothetical origin `example.com` that has two very different applications on the same origin:\n   *\n   * - A chat application at `/chat` that enables any user to contact any other user and send them messages.\n   * - A password management application at `/passwords` that contains all of the user's passwords, across different services.\n   *\n   * The administrators of the \"passwords\" application would very much like to ensure that it can't be directly scripted by the \"chat\" app, which by its nature has a larger XSS surface.\n   * The \"right way\" to isolate these applications would be to host them on different origins, but in some cases that's not possible, and those two applications have to be on a single origin for historical, business, or branding reasons.\n   *\n   * The `Cross-Origin-Opener-Policy: noopener-allow-popups` header can be used to ensure that a document can't be scripted by a document that opens it.\n   *\n   * If `example.com/passwords` is served with `noopener-allow-popups` the `WindowProxy` returned by [Window.open()](https://developer.mozilla.org/en-US/docs/domxref/Window.open()) will indicate that the windows is closed ([Window.closed](https://developer.mozilla.org/en-US/docs/domxref/Window.closed) is `true`), so the opener can't script the passwords app:\n   *\n   * ```js\n   * const handle = window.open(\"example.com/passwords\", \"passwordTab\");\n   * if (windowProxy.closed) {\n   *   // The new window is closed so it can't be scripted.\n   * }\n   * ```\n   *\n   * Note that this alone is not considered a sufficient security measure.\n   * The site would also need to do the following:\n   *\n   * - Use Fetch Metadata to block same-origin requests to the more-sensitive app that are not navigation requests.\n   * - Ensure their authentication cookies are all `HttpOnly`.\n   * - Ensure root-level Service-Workers are not installed by the less-sensitive app.\n   * - Ensure that `postMessage` or `BroadcastChannel` on the more-sensitive app don't expose any sensitive information the any other same-origin app.\n   * - Ensure their login page is served on a separate origin, due to password manager autofill being applied based on origin.\n   * - Understand that the browser may still allocate the more-sensitive app in the same process as the less-sensitive one, making it vulnerable to Spectre-like attacks.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Cross-Origin-Embedder-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy)\n   */\n  'Cross-Origin-Opener-Policy' = 'Cross-Origin-Opener-Policy',\n\n  /**\n   * The HTTP **`Cross-Origin-Resource-Policy`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) (CORP) indicates that the browser should block [`no-cors`](/en-US/docs/Web/API/RequestInit#no-cors) cross-origin or cross-site requests to the given resource.\n   *\n   * It specifies resource owner's policy for what sites/origins should be allowed to load this resource.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin\n   * ```\n   *\n   * ### Directives\n   *\n   * - `same-site`\n   *   - : Resources can only be loaded from the same site.\n   *\n   * - `same-origin`\n   *   - : Resources can only be loaded from the same origin.\n   *\n   * - `cross-origin`\n   *   - : Resources can be loaded by any other origin/website.\n   *\n   * ## Examples\n   *\n   * For more examples, see https://resourcepolicy.fyi/.\n   *\n   * ### Disallowing cross-origin no-cors requests\n   *\n   * The `Cross-Origin-Resource-Policy` header below will cause compatible user agents to disallow cross-origin no-cors requests:\n   *\n   * ```http\n   * Cross-Origin-Resource-Policy: same-origin\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Cross-Origin Resource Policy (CORP) explainer](/en-US/docs/Web/HTTP/Guides/Cross-Origin_Resource_Policy)\n   * - [Consider deploying Cross-Origin Resource Policy](https://resourcepolicy.fyi/)\n   * - [Cross-Origin-Embedder-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy)\n   * - [Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin)\n   */\n  'Cross-Origin-Resource-Policy' = 'Cross-Origin-Resource-Policy',\n\n  /**\n   * The HTTP **`Date`** [request](https://developer.mozilla.org/en-US/docs/Glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) contains the date and time at which the message originated.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<day-name>`\n   *   - : One of `Mon`, `Tue`, `Wed`, `Thu`, `Fri`, `Sat`, or `Sun` (case-sensitive).\n   * - `<day>`\n   *   - : 2 digit day number, e.g., \"04\" or \"23\".\n   * - `<month>`\n   *   - : One of `Jan`, `Feb`, `Mar`, `Apr`, `May`, `Jun`, `Jul`, `Aug`, `Sep`, `Oct`, `Nov`, `Dec` (case sensitive).\n   * - `<year>`\n   *   - : 4 digit year number, e.g., \"1990\" or \"2016\".\n   * - `<hour>`\n   *   - : 2 digit hour number, e.g., \"09\" or \"23\".\n   * - `<minute>`\n   *   - : 2 digit minute number, e.g., \"04\" or \"59\".\n   * - `<second>`\n   *   - : 2 digit second number, e.g., \"04\" or \"59\".\n   * - GMT\n   *   - : Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.\n   *\n   * ## Examples\n   *\n   * ### Response with a Date header\n   *\n   * The following HTTP message is a successful `200` status, with a `Date` header showing the time the message originated.\n   * Other headers are omitted for brevity:\n   *\n   * ```http\n   * HTTP/1.1 200\n   * Content-Type: text/html\n   * Date: Tue, 29 Oct 2024 16:56:32 GMT\n   *\n   * <html lang=\"en-US\" …\n   * ```\n   *\n   * ### Attempting to set the field value in JavaScript\n   *\n   * The `Date` header is a [Forbidden request header](https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_request_header), so this code cannot set the message `Date` field:\n   *\n   * ```js example-bad\n   * fetch(\"https://httpbin.org/get\", {\n   *   headers: {\n   *     Date: new Date().toUTCString(),\n   *   },\n   * });\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Age)\n   */\n  'Date' = 'Date',\n\n  /**\n   * The HTTP **`Device-Memory`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is used in [device client hints](/en-US/docs/Web/HTTP/Guides/Client_hints#device_client_hints) to indicate the approximate amount of available RAM on the client device, in gigabytes.\n   * The header is part of the [Device Memory API\", \"\", \"nocode](https://developer.mozilla.org/en-US/docs/DOMxRef/Device_Memory_API).\n   *\n   * Client hints are accessible only on secure origins.\n   * A server has to opt in to receive the `Device-Memory` header from the client, by first sending the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header.\n   * Servers that opt in to the `Device-Memory` client hint will typically also specify it in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header to inform caches that the server may send different responses based on the header value in a request.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Device-Memory: <number>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<number>`\n   *   - : The approximate amount of device RAM. Possible values are: `0.25`, `0.5`, `1`, `2`, `4`, `8`.\n   *     The amount of device RAM can be used as a [fingerprinting](https://developer.mozilla.org/en-US/docs/glossary/fingerprinting) variable, so values for the header are intentionally coarse to reduce the potential for its misuse.\n   *\n   * ## Examples\n   *\n   * The server first needs to opt in to receive `Device-Memory` header by sending the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header containing `Device-Memory`:\n   *\n   * ```http\n   * Accept-CH: Device-Memory\n   * ```\n   *\n   * Then on subsequent requests the client might send `Device-Memory` header back:\n   *\n   * ```http\n   * Device-Memory: 1\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   * - [Device Memory API\", \"\", \"nocode](https://developer.mozilla.org/en-US/docs/DOMxRef/Device_Memory_API)\n   * - [Navigator.deviceMemory](https://developer.mozilla.org/en-US/docs/DOMxRef/Navigator.deviceMemory)\n   * - [WorkerNavigator.deviceMemory](https://developer.mozilla.org/en-US/docs/DOMxRef/WorkerNavigator.deviceMemory)\n   * - Device client hints\n   *   - [Content-DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-DPR)\n   *   - [DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DPR)\n   *   - [Viewport-Width](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Viewport-Width)\n   *   - [Width](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Width)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   */\n  'Device-Memory' = 'Device-Memory',\n\n  /**\n   * The HTTP **`Dictionary-ID`** request header references a dictionary that can be used in [Compression Dictionary Transport](https://developer.mozilla.org/en-US/docs/glossary/Compression_Dictionary_Transport) to compress the server's response.\n   *\n   * A server can indicate that a resource can be used as a dictionary by sending the [Use-As-Dictionary](https://developer.mozilla.org/en-US/docs/httpheader/Use-As-Dictionary) header with the response. The server may include an `id` directive in the `Use-As-Dictionary` header, thus assigning an ID value to the dictionary. If the server does this, then when the browser requests a resource that can be compressed using the dictionary, the resource request must include the `Dictionary-ID` header, and its value must match the ID that was given in `Use-As-Dictionary`.\n   *\n   * This allows the server to identify and find a dictionary that is referenced by some arbitrary key, rather than having to use the [dictionary hash](https://developer.mozilla.org/en-US/docs/glossary/hash_function) as a key (if that approach is used, the server will have to hash every response that includes the `Use-As-Dictionary` header just in case the resource might eventually be used as a dictionary).\n   *\n   * Note that while the server can identify and locate the dictionary from its `Dictionary-ID`, it must still check the hash from the `Available-Dictionary` header to confirm that it is a correct match.\n   *\n   * See the [Compression Dictionary Transport guide](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport) for more information.\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Dictionary-ID: \"<string-identifier>\"\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<string-identifier>`\n   *   - : A string representing the dictionary's server-assigned ID.\n   *\n   * ## Examples\n   *\n   * For example, suppose the server has sent a `Use-As-Dictionary` header containing an `id=\"dictionary-12345\"` directive:\n   *\n   * ```http\n   * Use-As-Dictionary: match=\"/js/app.*.js\", id=\"dictionary-12345\"\n   * ```\n   *\n   * When the client requests a matching resource, it will include this `id` value in a `Dictionary-ID header`:\n   *\n   * ```http\n   * Accept-Encoding: gzip, br, zstd, dcb, dcz\n   * Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:\n   * Dictionary-ID: \"dictionary-12345\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Compression Dictionary Transport guide](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport)\n   * - [Available-Dictionary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Available-Dictionary)\n   * - [Use-As-Dictionary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Use-As-Dictionary)\n   */\n  'Dictionary-ID' = 'Dictionary-ID',\n\n  /**\n   * > [!NOTE]\n   * > The DNT (Do Not Track) specification has been discontinued. See [Navigator.doNotTrack](https://developer.mozilla.org/en-US/docs/domxref/Navigator.doNotTrack) for more information.\n   *\n   * The HTTP **`DNT`** (Do Not Track) [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates the user's tracking preference.\n   * It lets users indicate whether they would prefer privacy rather than personalized content.\n   *\n   * DNT is deprecated in favor of [Global Privacy Control](https://globalprivacycontrol.org/), which is communicated to servers using the [Sec-GPC](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-GPC) header, and accessible to clients from [navigator.globalPrivacyControl](https://developer.mozilla.org/en-US/docs/domxref/navigator.globalPrivacyControl).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * DNT: 0\n   * DNT: 1\n   * DNT: null\n   * ```\n   *\n   * ## Directives\n   *\n   * - `0`\n   *   - : The user prefers to allow tracking on the target site.\n   * - `1`\n   *   - : The user prefers not to be tracked on the target site.\n   * - `null`\n   *   - : The user has not specified a preference about tracking.\n   *\n   * ## Examples\n   *\n   * ### Reading Do Not Track status from JavaScript\n   *\n   * The user's DNT preference can also be read from JavaScript using the\n   * [Navigator.doNotTrack](https://developer.mozilla.org/en-US/docs/domxref/Navigator.doNotTrack) property:\n   *\n   * ```js\n   * navigator.doNotTrack; // \"0\", \"1\" or null\n   * ```\n   *\n   * ## Specifications\n   *\n   * Part of the discontinued [Tracking Preference Expression (DNT)](https://w3c.github.io/dnt/drafts/tracking-dnt.html#dnt-header-field) specification.\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Navigator.doNotTrack](https://developer.mozilla.org/en-US/docs/domxref/Navigator.doNotTrack)\n   * - [Tk](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Tk) header\n   * - [Do Not Track on Wikipedia](https://en.wikipedia.org/wiki/Do_Not_Track)\n   * - [What Does the \"Track\" in \"Do Not Track\" Mean? – EFF](https://www.eff.org/deeplinks/2011/02/what-does-track-do-not-track-mean)\n   * - [DNT on Electronic Frontier Foundation](https://www.eff.org/issues/do-not-track)\n   * - DNT browser settings help:\n   *   - [Firefox](https://support.mozilla.org/en-US/kb/how-do-i-turn-do-not-track-feature)\n   *   - [Chrome](https://support.google.com/chrome/answer/2790761)\n   * - [GPC - Global Privacy Control](https://globalprivacycontrol.org/)\n   *   - [Enabling GPC in Firefox](https://support.mozilla.org/en-US/kb/global-privacy-control?as=u&utm_source=inproduct)\n   */\n  'DNT' = 'DNT',\n\n  /**\n   * The HTTP **`Downlink`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is used in [Client Hints](/en-US/docs/Web/HTTP/Guides/Client_hints) to provide the approximate bandwidth in Mbps of the client's connection to the server.\n   *\n   * The hint allows a server to choose what information is sent based on the network bandwidth.\n   * For example, a server might choose to send smaller versions of images and other resources on low bandwidth networks.\n   *\n   * > [!NOTE]\n   * > The [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header is used in responses to indicate that a different resource is sent for every different value of the header (see [HTTP Caching Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary)).\n   * > Even if `Downlink` is used to configure what resources are sent, consider omitting it in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header — it is likely to change often, which effectively makes the resource uncacheable.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Downlink: <number>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<number>`\n   *   - : The downlink rate in Mbps, rounded to the nearest 25 kilobits.\n   *     The downlink rate may be used as a [fingerprinting](https://developer.mozilla.org/en-US/docs/glossary/fingerprinting) variable, so values for the header are intentionally coarse to reduce the potential for its misuse.\n   *\n   * ## Examples\n   *\n   * A server first needs to opt in to receive the `Downlink` header by sending the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header containing `Downlink`.\n   *\n   * ```http\n   * Accept-CH: Downlink\n   * ```\n   *\n   * Then on subsequent requests the client might send a `Downlink` header back:\n   *\n   * ```http\n   * Downlink: 1.7\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   * - Network client hints\n   *   - [RTT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/RTT)\n   *   - [ECT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ECT)\n   *   - [Save-Data](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   * - [NetworkInformation.effectiveType](https://developer.mozilla.org/en-US/docs/domxref/NetworkInformation.effectiveType)\n   */\n  'Downlink' = 'Downlink',\n\n  /**\n   * > [!WARNING]\n   * > The `DPR` header was removed from the client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07).\n   * > The proposed replacement is [`Sec-CH-DPR`](https://wicg.github.io/responsive-image-client-hints/#sec-ch-dpr) (Responsive Image Client Hints).\n   *\n   * The HTTP **`DPR`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) provides [device client hints](/en-US/docs/Web/HTTP/Guides/Client_hints) about the client device pixel ratio (DPR).\n   * This ratio is the number of physical device pixels corresponding to every [CSS pixel](https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel).\n   *\n   * The hint is useful when selecting image sources that best correspond to a screen's pixel density.\n   * This is similar to the role played by `x` descriptors in the `\n   *\n   * ## Syntax\n   *\n   * ```http\n   * DPR: <number>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<number>`\n   *   - : The client device pixel ratio.\n   *\n   * ## Examples\n   *\n   * A server must first opt in to receive the `DPR` header by sending the response header [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) containing the directive `DPR`.\n   *\n   * ```http\n   * Accept-CH: DPR\n   * ```\n   *\n   * Then on subsequent requests the client might send `DPR` header to the server:\n   *\n   * ```http\n   * DPR: 2.0\n   * ```\n   *\n   * If a request with the `DPR` header (as shown above) is for an image resource, then the server response must include the [Content-DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-DPR) header:\n   *\n   * ```http\n   * Content-DPR: 2.0\n   * ```\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - Device client hints\n   *   - [Content-DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-DPR)\n   *   - [Device-Memory](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Device-Memory)\n   *   - [Viewport-Width](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Viewport-Width)\n   *   - [Width](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Width)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'DPR' = 'DPR',\n\n  /**\n   * The HTTP **`Early-Data`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is set by an intermediary to indicate that the request has been conveyed in [TLS early data](/en-US/docs/Web/Security/Transport_Layer_Security#tls_1.3), and also indicates that the intermediary understands the [425 Too Early](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/425) status code.\n   *\n   * If a client has interacted with a server recently, early data (also known as zero round-trip time [(0-RTT) data](/en-US/docs/Web/Security/Transport_Layer_Security#tls_1.3)) allows the client to send data to a server in the first round trip of a connection, without waiting for the TLS [handshake](/en-US/docs/Glossary/TCP_handshake) to complete.\n   * This reduces latency for repeat connections between a client and server, but has security implications, as early data is susceptible to replay attacks.\n   *\n   * The `Early-Data` header is **not** set by the originator of the request (i.e., a browser).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Early-Data: 1\n   * ```\n   *\n   * ## Examples\n   *\n   * ### A GET request with an Early-Data header\n   *\n   * A client that wants to use early data can send HTTP requests immediately after sending the TLS `ClientHello`.\n   * Sending a request in early data implies that the client is willing to retry a request in response to a [425 Too Early](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/425) status code, so the `Early-Data` header is not included:\n   *\n   * ```http\n   * GET /resource HTTP/1.1\n   * Host: example.com\n   * ```\n   *\n   * An intermediary that forwards a request prior to the completion of the TLS handshake with its client sends it with the `Early-Data` header set to `1`:\n   *\n   * ```http\n   * GET /resource HTTP/1.1\n   * Host: example.com\n   * Early-Data: 1\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [425 Too Early](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/425)\n   * - [Replay Attacks on 0-RTT](https://www.rfc-editor.org/rfc/rfc8446#appendix-E.5)\n   */\n  'Early-Data' = 'Early-Data',\n\n  /**\n   * The HTTP **`ECT`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is used in [Client Hints](/en-US/docs/Web/HTTP/Guides/Client_hints) to indicate the [effective connection type](https://developer.mozilla.org/en-US/docs/Glossary/effective_connection_type): `slow-2g`, `2g`, `3g`, or `4g`.\n   *\n   * The value represents the \"network profile\" that best matches the connection's latency and bandwidth, rather than the actual mechanisms used for transferring the data.\n   * For example, `2g` might be used to represent a slow Wi-Fi connection with high latency and low bandwidth, while `4g` might represent a fast fibre-based broadband network.\n   *\n   * The hint allows a server to choose what information is sent based on the broad characteristics of the network. For example, a server might choose to send smaller versions of images and other resources on less capable connections. The value might also be used as a starting point for determining what information is sent, which is further refined using information in [RTT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/RTT) and [Downlink](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Downlink) hints.\n   *\n   * > [!NOTE]\n   * > A server that specifies `ECT` in [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) may also specify it in [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) to indicate that responses should be cached for different ECT values.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * ECT: <value>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<value>`\n   *   - : A value indicating [effective connection type](https://developer.mozilla.org/en-US/docs/Glossary/effective_connection_type). Can be one of: `slow-2g`, `2g`, `3g`, or `4g`.\n   *\n   * ## Examples\n   *\n   * A server first needs to opt in to receive the `ECT` header by sending the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header containing `ECT`.\n   *\n   * ```http\n   * Accept-CH: ECT\n   * ```\n   *\n   * Then on subsequent requests the client might send an `ECT` header back:\n   *\n   * ```http\n   * ECT: 2g\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   * - Network client hints\n   *   - [Downlink](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Downlink)\n   *   - [RTT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/RTT)\n   *   - [Save-Data](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data)\n   *\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching > Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   * - [NetworkInformation.effectiveType](https://developer.mozilla.org/en-US/docs/domxref/NetworkInformation.effectiveType)\n   */\n  'ECT' = 'ECT',\n\n  /**\n   * The HTTP **`ETag`** (entity tag) [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is an identifier for a specific version of a resource.\n   * It lets [caches](/en-US/docs/Web/HTTP/Guides/Caching) be more efficient and save bandwidth, as a web server does not need to resend a full response if the content has not changed.\n   * Additionally, ETags help to prevent simultaneous updates of a resource from overwriting each other ([\"mid-air collisions\"](#avoiding_mid-air_collisions)).\n   *\n   * If the resource at a given URL changes, a new `Etag` value _must_ be generated.\n   * A comparison of them can determine whether two representations of a resource are the same.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * ETag: W/\"<etag_value>\"\n   * ETag: \"<etag_value>\"\n   * ```\n   *\n   * ## Directives\n   *\n   * - `W/`\n   *   - : `W/` (case-sensitive) indicates that a [weak validator](/en-US/docs/Web/HTTP/Guides/Conditional_requests#weak_validation) is used.\n   *     Weak ETags are easy to generate, but are far less useful for comparisons.\n   *     Strong validators are ideal for comparisons but can be very difficult to generate efficiently.\n   *     Weak `ETag` values of two representations of the same resources might be semantically equivalent, but not byte-for-byte identical.\n   *     This means weak ETags prevent caching when [byte range requests](/en-US/docs/Web/HTTP/Reference/Headers/Accept-Ranges) are used, but strong ETags mean range requests can still be cached.\n   * - `<etag_value>`\n   *   - : Entity tag that uniquely represents the requested resource. It is a string of [ASCII](https://developer.mozilla.org/en-US/docs/Glossary/ASCII) characters placed between double quotes, like `\"675af34563dc-tr34\"`.\n   *     The method by which `ETag` values are generated is not specified.\n   *     Typically, the ETag value is a hash of the content, a hash of the last modification timestamp, or just a revision number.\n   *     For example, a wiki engine can use a hexadecimal hash of the documentation article content.\n   *\n   * ## Examples\n   *\n   * ```http\n   * ETag: \"33a64df551425fcc55e4d42a148795d9f25f89d4\"\n   * ETag: W/\"0815\"\n   * ```\n   *\n   * ### Avoiding mid-air collisions\n   *\n   * With the help of the `ETag` and the [If-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match) headers, you can detect mid-air edit collisions (conflicts).\n   *\n   * For example, when editing a wiki, the current wiki content may be hashed and put into an `Etag` header in the response:\n   *\n   * ```http\n   * ETag: \"33a64df551425fcc55e4d42a148795d9f25f89d4\"\n   * ```\n   *\n   * When saving changes to a wiki page (posting data), the [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) request\n   * will contain the [If-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match) header containing the `ETag`\n   * values to check freshness against.\n   *\n   * ```http\n   * If-Match: \"33a64df551425fcc55e4d42a148795d9f25f89d4\"\n   * ```\n   *\n   * If the hashes don't match, it means that the document has been edited in-between and a\n   * [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) error is thrown.\n   *\n   * ### Caching of unchanged resources\n   *\n   * Another typical use of the `ETag` header is to cache resources that are unchanged.\n   * If a user visits a given URL again (that has an `ETag` set), and it is _stale_ (too old to be considered usable), the client will send the value of its `ETag` along in an [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match) header field:\n   *\n   * ```http\n   * If-None-Match: \"33a64df551425fcc55e4d42a148795d9f25f89d4\"\n   * ```\n   *\n   * The server compares the client's `ETag` (sent with `If-None-Match`) with the `ETag` for its current version of the resource, and if both values match (that is, the resource has not changed), the server sends back a [304 Not Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304) status, without a body, which tells the client that the cached version of the response is still good to use (_fresh_).\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [If-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match), [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match) headers\n   * - [304 Not Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304), [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) response status codes\n   * - [W3C Note: Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout](https://www.w3.org/1999/04/Editing/)\n   */\n  'ETag' = 'ETag',\n\n  /**\n   * The `Expect-CT` [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) lets sites opt in to reporting and/or enforcement of [Certificate Transparency](/en-US/docs/Web/Security/Certificate_Transparency) requirements.\n   * Certificate Transparency (CT) aims to prevent the use of misissued certificates for that site from going unnoticed.\n   *\n   * Only Google Chrome and other Chromium-based browsers implemented `Expect-CT`, and Chromium has deprecated the header from version 107, because Chromium now enforces CT by default.\n   * See the [Chrome Platform Status](https://chromestatus.com/feature/6244547273687040) update.\n   *\n   * CT requirements can be satisfied via any one of the following mechanisms:\n   *\n   * - X.509v3 certificate extension to allow embedding of signed certificate timestamps issued by individual logs. Most TLS certificates issued by publicly-trusted CAs and used online contain embedded CT.\n   * - A TLS extension of type `signed_certificate_timestamp` sent during the handshake\n   * - Supporting OCSP stapling (that is, the `status_request` TLS extension) and providing a `SignedCertificateTimestampList`\n   *\n   * > [!NOTE]\n   * > When a site enables the `Expect-CT` header, they are requesting that the browser check that any certificate for that site appears in **[public CT logs](https://github.com/google/certificate-transparency-community-site/blob/master/docs/google/known-logs.md)**.\n   *\n   * > [!NOTE]\n   * > Browsers **ignore** the `Expect-CT` header over HTTP; the header only has effect on HTTPS connections.\n   *\n   * > [!NOTE]\n   * > The `Expect-CT` is mostly obsolete since June 2021.\n   * > Since May 2018, all new TLS certificates are expected to support SCTs by default.\n   * > Certificates issued before March 2018 were allowed to have a lifetime of 39 months, so they had expired in June 2021.\n   * > Chromium plans to deprecate `Expect-CT` header and to eventually remove it.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Expect-CT: report-uri=\"<uri>\",\n   *            enforce,\n   *            max-age=<age>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `max-age`\n   *   - : The number of seconds after reception of the `Expect-CT` header field during which the user agent should regard the host of the received message as a known `Expect-CT` host.\n   *\n   *     If a cache receives a value greater than it can represent, or if any of its subsequent calculations overflows, the cache will consider this value to be either 2,147,483,648 (2^31) or the greatest positive integer it can represent.\n   *\n   * - `report-uri=\"<uri>\"`\n   *   - : The URI where the user agent should report `Expect-CT` failures.\n   *\n   *     When present with the `enforce` directive, the configuration is referred to as an \"enforce-and-report\" configuration, signalling to the user agent both that compliance to the Certificate Transparency policy should be enforced _and_ that violations should be reported.\n   *\n   * - `enforce`\n   *   - : Signals to the user agent that compliance with the Certificate Transparency policy should be enforced (rather than only reporting compliance) and that the user agent should refuse future connections that violate its Certificate Transparency policy.\n   *\n   *     When both the `enforce` directive and the `report-uri` directive are present, the configuration is referred to as an \"enforce-and-report\" configuration, signalling to the user agent both that compliance to the Certificate Transparency policy should be enforced and that violations should be reported.\n   *\n   * ## Example\n   *\n   * The following example specifies enforcement of Certificate Transparency for 24 hours and reports violations to `foo.example.com`.\n   *\n   * ```http\n   * Expect-CT: max-age=86400, enforce, report-uri=\"https://foo.example.com/report\"\n   * ```\n   *\n   * ## Notes\n   *\n   * Root CAs manually added to the trust store override and suppress `Expect-CT` reports/enforcement.\n   *\n   * Browsers will not remember an `Expect-CT` policy, unless the site has 'proven' it can serve a certificate satisfying the certificate transparency requirements. Browsers implement their own trust model regarding which CT logs are considered trusted for the certificate to have been logged to.\n   *\n   * Builds of Chrome are designed to stop enforcing the `Expect-CT` policy 10 weeks after the installation's build date.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Secure Contexts](/en-US/docs/Web/Security/Secure_Contexts)\n   * - Glossary terms:\n   *   -\n   *   -\n   *   -\n   */\n  'Expect-CT' = 'Expect-CT',\n\n  /**\n   * The HTTP **`Expect`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates that there are expectations that need to be met by the server in order to handle the complete request successfully.\n   *\n   * When a request has an `Expect: 100-continue` header, a server sends a [100 Continue](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100) response to indicate that the server is ready or capable of receiving the rest of the request content.\n   * Waiting for a `100` response can be helpful if a client anticipates that an error is likely, for example, when sending state-changing operations without previously verified authentication credentials.\n   *\n   * A [417 Expectation Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/417) response is returned if the server cannot meet the expectation, or any other status otherwise (e.g., a [4XX](/en-US/docs/Web/HTTP/Reference/Status#client_error_responses) status for a client error, or a [2XX](/en-US/docs/Web/HTTP/Reference/Status#successful_responses) status if the request can be resolved successfully without further processing).\n   *\n   * None of the more common browsers send the `Expect` header, but some clients (command-line tools) do so by default.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Expect: 100-continue\n   * ```\n   *\n   * ## Directives\n   *\n   * There is only one defined expectation:\n   *\n   * - `100-continue`\n   *   - : Informs recipients that the client is about to send a (presumably large) message body in this request and wishes to receive a [100 Continue](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100) interim response.\n   *\n   * ## Examples\n   *\n   * ### Large message body\n   *\n   * A client sends a request with `Expect` header and waits for the server to respond before sending the message body.\n   *\n   * ```http\n   * PUT /somewhere/fun HTTP/1.1\n   * Host: origin.example.com\n   * Content-Type: video/h264\n   * Content-Length: 1234567890987\n   * Expect: 100-continue\n   * ```\n   *\n   * The server checks the headers and generates the response, where a [100 Continue](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100) instructs the client to send the message body:\n   *\n   * ```http\n   * HTTP/1.1 100 Continue\n   * ```\n   *\n   * The client completes the request by sending the actual data:\n   *\n   * ```http\n   * [Video data as content for PUT request]\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## See also\n   *\n   * - [417 Expectation Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/417)\n   * - [100 Continue](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100)\n   */\n  'Expect' = 'Expect',\n\n  /**\n   * The HTTP **`Expires`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) contains the date/time after which the response is considered expired in the context of [HTTP caching](/en-US/docs/Web/HTTP/Guides/Caching).\n   *\n   * The value `0` is used to represent a date in the past, indicating the resource has already expired.\n   *\n   * > [!NOTE]\n   * > If there is a [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) header with the `max-age` or `s-maxage` directive in the response, the `Expires` header is ignored.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Expires: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<day-name>`\n   *   - : One of `Mon`, `Tue`, `Wed`, `Thu`, `Fri`, `Sat`, or `Sun` (case-sensitive).\n   * - `<day>`\n   *   - : 2 digit day number, e.g., \"04\" or \"23\".\n   * - `<month>`\n   *   - : One of `Jan`, `Feb`, `Mar`, `Apr`, `May`, `Jun`, `Jul`, `Aug`, `Sep`, `Oct`, `Nov`, `Dec` (case sensitive).\n   * - `<year>`\n   *   - : 4 digit year number, e.g., \"1990\" or \"2016\".\n   * - `<hour>`\n   *   - : 2 digit hour number, e.g., \"09\" or \"23\".\n   * - `<minute>`\n   *   - : 2 digit minute number, e.g., \"04\" or \"59\".\n   * - `<second>`\n   *   - : 2 digit second number, e.g., \"04\" or \"59\".\n   * - GMT\n   *   - : Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Expires: Wed, 21 Oct 2015 07:28:00 GMT\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTTP caching](/en-US/docs/Web/HTTP/Guides/Caching) guide\n   * - [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)\n   * - [Age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Age)\n   */\n  'Expires' = 'Expires',\n\n  /**\n   * The HTTP **`Forwarded`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) contains information that may be added by [reverse proxy servers](/en-US/docs/Web/HTTP/Guides/Proxy_servers_and_tunneling) (load balancers, CDNs, etc.) that would otherwise be altered or lost when proxy servers are involved in the path of the request.\n   *\n   * For example, if a client is connecting to a web server through an HTTP proxy (or load balancer), server logs will only contain the IP address, host address, and protocol of the proxy; this header can be used to identify the IP address, host, and protocol, of the original request.\n   * The header is optional and may be added to, modified, or removed, by any of the proxy servers on the path to the server.\n   *\n   * This header is used for debugging, statistics, and generating location-dependent content.\n   * By design, it exposes privacy sensitive information, such as the IP address of the client.\n   * Therefore, the user's privacy must be kept in mind when using this header.\n   *\n   * The alternative and de-facto standard versions of this header are the [X-Forwarded-For](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For), [X-Forwarded-Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host) and [X-Forwarded-Proto](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto) headers.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Forwarded: by=<identifier>;for=<identifier>;host=<host>;proto=<http|https>\n   * ```\n   *\n   * Directives are `key=value` pairs, separated by a semicolon.\n   *\n   * If there are multiple proxy servers between the client and server, they may each specify their own forwarding information.\n   * This can be done by adding a new `Forwarded` header to the end of the header block, or by appending the information to the end of the last `Forwarded` header in a comma-separated list.\n   *\n   * ## Directives\n   *\n   * - `by`\n   *   - : The interface where the request came in to the proxy server.\n   *     The identifier can be:\n   *     - an obfuscated identifier (such as \"hidden\" or \"secret\").\n   *       This should be treated as the default.\n   *     - an IP address (v4 or v6, optionally with a port, and ipv6 quoted and enclosed in square brackets)\n   *     - \"unknown\" when the preceding entity is not known (and you still want to indicate that forwarding of the request was made)\n   *\n   * - `for`\n   *   - : The client that initiated the request and subsequent proxies in a chain of proxies.\n   *     The identifier has the same possible values as the `by` directive.\n   * - `host`\n   *   - : The [Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host) request header field as received by the proxy.\n   * - `proto`\n   *   - : Indicates which protocol was used to make the request (typically \"http\" or \"https\").\n   *\n   * ## Examples\n   *\n   * ### Using the `Forwarded` header\n   *\n   * ```http\n   * Forwarded: for=\"_mdn\"\n   *\n   * # case insensitive\n   * Forwarded: For=\"[2001:db8:cafe::17]:4711\"\n   *\n   * # separated by semicolon\n   * Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43\n   *\n   * # Values from multiple proxy servers can be appended using a comma\n   * Forwarded: for=192.0.2.43, for=198.51.100.17\n   * ```\n   *\n   * ### Transitioning from `X-Forwarded-For` to `Forwarded`\n   *\n   * If your application, server, or proxy supports the standardized `Forwarded` header, the [X-Forwarded-For](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For) header can be replaced.\n   * Note that an IPv6 address is quoted and enclosed in square brackets in `Forwarded` (unlike in the [X-Forwarded-For](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For) header).\n   *\n   * ```http\n   * X-Forwarded-For: 192.0.2.172\n   * Forwarded: for=192.0.2.172\n   *\n   * X-Forwarded-For: 192.0.2.43, 2001:db8:cafe::17\n   * Forwarded: for=192.0.2.43, for=\"[2001:db8:cafe::17]\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## See also\n   *\n   * - [X-Forwarded-For](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For)\n   * - [X-Forwarded-Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host)\n   * - [X-Forwarded-Proto](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto)\n   * - [Via](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Via) – provides information about the proxy itself, not about the client connecting to it.\n   */\n  'Forwarded' = 'Forwarded',\n\n  /**\n   * The HTTP **`From`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) contains an Internet email address for an administrator who controls an automated user agent.\n   *\n   * If you are running a robotic user agent (a web crawler, for example), the `From` header must be sent in requests so you can be contacted if problems occur, such as a bot sending excessive, unwanted, or invalid requests.\n   *\n   * > [!WARNING]\n   * > You must not use the `From` header for access control or authentication.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * From: <email>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<email>`\n   *   - : A machine-usable email address.\n   *\n   * ## Examples\n   *\n   * ```http\n   * From: webmaster@example.org\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host)\n   */\n  'From' = 'From',\n\n  /**\n   * The HTTP **`Host`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) specifies the host and port number of the server to which the request is being sent.\n   *\n   * If no port is included, the default port for the service requested is implied (e.g., `443` for an HTTPS URL, and `80` for an HTTP URL).\n   *\n   * A `Host` header field must be sent in all HTTP/1.1 request messages.\n   * A [400 Bad Request](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400) status code may be sent to any HTTP/1.1 request message that lacks or contains more than one `Host` header field.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Host: <host>:<port>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<host>`\n   *   - : The domain name of the server (for virtual hosting).\n   * - `<port>`\n   *   - : TCP port number on which the server is listening.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Host: developer.mozilla.org\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [400](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400)\n   * - [base](https://developer.mozilla.org/en-US/docs/HTMLElement/base)\n   */\n  'Host' = 'Host',\n\n  /**\n   * The HTTP **`If-Match`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) makes a request [conditional](/en-US/docs/Web/HTTP/Guides/Conditional_requests).\n   * A server will return resources for [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) and [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) methods, or upload resource for [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT) and other non-safe methods, only if the resource matches one of the [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) values in the `If-Match` request header.\n   * If the conditional does not match, the [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) response is returned instead.\n   *\n   * The comparison with the stored [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) uses the _strong comparison algorithm_, meaning two files are considered identical byte-by-byte.\n   * If a listed `ETag` has the `W/` prefix indicating a weak entity tag, this comparison algorithm will never match it.\n   *\n   * There are two common use cases:\n   *\n   * - For [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) and [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) methods, used in combination with a [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) header, it can guarantee that the new ranges requested\n   *   come from the same resource as the previous one.\n   * - For other methods, and in particular for [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT), `If-Match` can be used to prevent the [lost update problem](https://www.w3.org/1999/04/Editing/#3.1).\n   *   It can check if the modification of a resource that the user wants to upload will not override another change that has been done since the original resource was fetched.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * If-Match: <etag_value>\n   * If-Match: <etag_value>, <etag_value>, …\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<etag_value>`\n   *   - : Entity tags uniquely representing the requested resources.\n   *     They are a string of [ASCII](https://developer.mozilla.org/en-US/docs/Glossary/ASCII) characters placed between double quotes (like `\"675af34563dc-tr34\"`).\n   *     They may be prefixed by `W/` to indicate that they are 'weak', i.e., that they represent the resource semantically but not byte-by-byte.\n   *     However, in an `If-Match` header, weak entity tags will never match.\n   * - `*`\n   *   - : The asterisk is a special value representing any resource.\n   *     Note that this must match as `false` if the origin server does not have a current representation for the target resource.\n   *\n   * ## Examples\n   *\n   * ```http\n   * If-Match: \"bfc13a64729c4290ef5b2c2730249c88ca92d82d\"\n   *\n   * If-Match: \"67ab43\", \"54ed21\", \"7892dd\"\n   *\n   * If-Match: *\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag)\n   * - [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match), [If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since), [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since) conditional request headers\n   * - [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412)\n   */\n  'If-Match' = 'If-Match',\n\n  /**\n   * The HTTP **`If-Modified-Since`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) makes a request [conditional](/en-US/docs/Web/HTTP/Guides/Conditional_requests).\n   * The server sends back the requested resource, with a [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) status, only if it has been modified after the date in the `If-Modified-Since` header.\n   * If the resource has not been modified since, the response is a [304](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304) without any body, and the [Last-Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified) response header of the previous request contains the date of the last modification.\n   *\n   * Unlike [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since), `If-Modified-Since` can only be used with a [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) or [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD).\n   * When used in combination with [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match), it is ignored, unless the server doesn't support `If-None-Match`.\n   *\n   * The most common use case is to update a cached entity that has no associated [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * If-Modified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<day-name>`\n   *   - : One of `Mon`, `Tue`, `Wed`, `Thu`, `Fri`, `Sat`, or `Sun` (case-sensitive).\n   * - `<day>`\n   *   - : 2 digit day number, e.g., \"04\" or \"23\".\n   * - `<month>`\n   *   - : One of `Jan`, `Feb`, `Mar`, `Apr`, `May`, `Jun`, `Jul`, `Aug`, `Sep`, `Oct`, `Nov`, `Dec` (case sensitive).\n   * - `<year>`\n   *   - : 4 digit year number, e.g., \"1990\" or \"2016\".\n   * - `<hour>`\n   *   - : 2 digit hour number, e.g., \"09\" or \"23\".\n   * - `<minute>`\n   *   - : 2 digit minute number, e.g., \"04\" or \"59\".\n   * - `<second>`\n   *   - : 2 digit second number, e.g., \"04\" or \"59\".\n   * - GMT\n   *   - : Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.\n   *\n   * ## Examples\n   *\n   * ```http\n   * If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag)\n   * - [If-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match), [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match), [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since) conditional request headers\n   * - [304 Not Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304), [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) response status codes\n   */\n  'If-Modified-Since' = 'If-Modified-Since',\n\n  /**\n   * The HTTP **`If-None-Match`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) makes a request [conditional](/en-US/docs/Web/HTTP/Guides/Conditional_requests).\n   * The server returns the requested resource in [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) and [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) methods with a [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) status, only if it doesn't have an [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) matching the ones in the `If-None-Match` header.\n   * For other methods, the request will be processed only if the eventually existing resource's [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) doesn't match any of the values listed.\n   *\n   * When the condition fails for [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) and [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) methods, the server must return a [304 Not Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304) and any of the following header fields that would have been sent in a 200 response to the same request: `Cache-Control`, `Content-Location`, `Date`, `ETag`, `Expires`, and `Vary`.\n   * For methods that apply server-side changes, the [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) is used when the condition fails.\n   *\n   * The comparison with the stored ETag uses the _weak comparison algorithm_, meaning two files are considered identical if the content is equivalent — they don't have to be identical byte-by-byte.\n   * For example, two pages that differ by their creation date in the footer would still be considered identical.\n   *\n   * When used in combination with [If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since), `If-None-Match` has precedence if the server supports it.\n   *\n   * There are two common cases for using `If-None-Match` in requests:\n   *\n   * - For [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) and [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) methods, to update a cached entity that has an associated ETag.\n   * - For other methods, and in particular for [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT), `If-None-Match` used with the `*` value can be used to save a file only if it does not already exist, guaranteeing that the upload won't accidentally overwrite another upload and lose the data of the previous `PUT`; this problem is a variation of the [lost update problem](https://www.w3.org/1999/04/Editing/#3.1).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * If-None-Match: \"<etag_value>\"\n   * If-None-Match: \"<etag_value>\", \"<etag_value>\", …\n   * If-None-Match: *\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<etag_value>`\n   *   - : Entity tags uniquely representing the requested resources. They are a string of [ASCII](https://developer.mozilla.org/en-US/docs/Glossary/ASCII) characters placed between double quotes (Like `\"675af34563dc-tr34\"`) and may be prefixed by `W/` to indicate that the weak comparison algorithm should be used (this is useless with `If-None-Match` as it only uses that algorithm).\n   * - `*`\n   *   - : The asterisk is a special value representing any resource. They are only useful when uploading a resource, usually with [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT), to check if another resource with the identity has already been uploaded before.\n   *\n   * ## Examples\n   *\n   * ```http\n   * If-None-Match: \"bfc13a64729c4290ef5b2c2730249c88ca92d82d\"\n   *\n   * If-None-Match: W/\"67ab43\", \"54ed21\", \"7892dd\"\n   *\n   * If-None-Match: *\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag)\n   * - [If-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match), [If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since), [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since) conditional request headers\n   * - [304 Not Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304), [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) response status codes\n   */\n  'If-None-Match' = 'If-None-Match',\n\n  /**\n   * The HTTP **`If-Range`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) makes a range request [conditional](/en-US/docs/Web/HTTP/Guides/Conditional_requests).\n   * If the condition is fulfilled, a [range request](/en-US/docs/Web/HTTP/Guides/Range_requests) is issued, and the server sends back a [206 Partial Content](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206) response with part (or parts) of the resource in the body.\n   * If the condition is not fulfilled, the full resource is sent back with a [200 OK](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) status.\n   *\n   * This header can be used either with the [Last-Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified) validator or with [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag), but not with both.\n   *\n   * The most common use case is to resume a download with guarantees that the resource on the server has not been modified since the last part has been received by the client.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * If-Range: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT\n   * If-Range: <etag>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<etag>`\n   *   - : An entity tag uniquely representing the requested resource. It is a string of ASCII\n   *     characters placed between double quotes (Like `\"675af34563dc-tr34\"`). A weak entity tag (one prefixed by `W/`) must not be used in this header.\n   * - `<day-name>`\n   *   - : One of `Mon`, `Tue`, `Wed`, `Thu`, `Fri`, `Sat`, or `Sun` (case-sensitive).\n   * - `<day>`\n   *   - : 2 digit day number, e.g., \"04\" or \"23\".\n   * - `<month>`\n   *   - : One of `Jan`, `Feb`, `Mar`, `Apr`, `May`, `Jun`, `Jul`, `Aug`, `Sep`, `Oct`, `Nov`, `Dec` (case sensitive).\n   * - `<year>`\n   *   - : 4 digit year number, e.g., \"1990\" or \"2016\".\n   * - `<hour>`\n   *   - : 2 digit hour number, e.g., \"09\" or \"23\".\n   * - `<minute>`\n   *   - : 2 digit minute number, e.g., \"04\" or \"59\".\n   * - `<second>`\n   *   - : 2 digit second number, e.g., \"04\" or \"59\".\n   * - GMT\n   *   - : Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.\n   *\n   * ## Examples\n   *\n   * ```http\n   * If-Range: Wed, 21 Oct 2015 07:28:00 GMT\n   *\n   * If-Range: \"67ab43\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTTP Conditional Requests](/en-US/docs/Web/HTTP/Guides/Conditional_requests) guide\n   * - [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag)\n   * - [Last-Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified)\n   * - [If-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match), [If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since), [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since), [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match) conditional request headers\n   * - [206 Partial Content](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206), [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412), [416 Range Not Satisfiable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416) response status codes\n   */\n  'If-Range' = 'If-Range',\n\n  /**\n   * The HTTP **`If-Unmodified-Since`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) makes the request for the resource [conditional](/en-US/docs/Web/HTTP/Guides/Conditional_requests).\n   * The server will send the requested resource (or accept it in the case of a [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) or another non-[safe](https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP) method) only if the resource on the server has not been modified after the date in the request header.\n   * If the resource has been modified after the specified date, the response will be a [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) error.\n   *\n   * The `If-Unmodified-Since` header is commonly used in the following situations:\n   *\n   * - In conjunction with non-[safe](https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP) methods like [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST), this header can be used to implement an [optimistic concurrency control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control), as is done by some wikis: revision are rejected if the stored document has been modified since the original was retrieved, avoiding conflicts.\n   * - In conjunction with a range request using the [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) header, this header can be used to ensure that the new fragment requested comes from an unmodified document.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * If-Unmodified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<day-name>`\n   *   - : One of `Mon`, `Tue`, `Wed`, `Thu`, `Fri`, `Sat`, or `Sun` (case-sensitive).\n   * - `<day>`\n   *   - : 2 digit day number, e.g., \"04\" or \"23\".\n   * - `<month>`\n   *   - : One of `Jan`, `Feb`, `Mar`, `Apr`, `May`, `Jun`, `Jul`, `Aug`, `Sep`, `Oct`, `Nov`, `Dec` (case sensitive).\n   * - `<year>`\n   *   - : 4 digit year number, e.g., \"1990\" or \"2016\".\n   * - `<hour>`\n   *   - : 2 digit hour number, e.g., \"09\" or \"23\".\n   * - `<minute>`\n   *   - : 2 digit minute number, e.g., \"04\" or \"59\".\n   * - `<second>`\n   *   - : 2 digit second number, e.g., \"04\" or \"59\".\n   * - GMT\n   *   - : Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.\n   *\n   * ## Examples\n   *\n   * ```http\n   * If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTTP Conditional Requests](/en-US/docs/Web/HTTP/Guides/Conditional_requests) guide\n   * - [Last-Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified)\n   * - [If-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Range), [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) range request headers\n   * - [If-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match), [If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since), [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match) conditional request headers\n   * - [304 Not Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304), [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) response status codes\n   */\n  'If-Unmodified-Since' = 'If-Unmodified-Since',\n\n  /**\n   * The HTTP **`Integrity-Policy-Report-Only`** response header allows website administrators to report on resources that the user agent loads that would violate [Subresource Integrity](/en-US/docs/Web/Security/Subresource_Integrity) guarantees if the integrity policy was enforced (using the [Integrity-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Integrity-Policy) header).\n   *\n   * Reports may be generated for requests on specified [request destinations](/en-US/docs/Web/API/Request/destination) that omit integrity metadata, or that are made in [no-cors](/en-US/docs/Web/API/Request/mode#no-cors) mode.\n   * For reports to be sent to a reporting endpoint, the `Integrity-Policy-Report-Only` header must specify a valid reporting endpoint name that matches an endpoint declared using the [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Reporting-Endpoints) header.\n   * Reports are generated using the [Reporting API](/en-US/docs/Web/API/Reporting_API), and may also be observed in the page for which the integrity policy is being reported, using a [ReportingObserver](/en-US/docs/Web/API/ReportingObserver).\n   * The format of the report body is given by the [IntegrityViolationReportBody](https://developer.mozilla.org/en-US/docs/domxref/IntegrityViolationReportBody) dictionary (a JSON-serialized form of this body is sent in POSTs to reporting server endpoints).\n   *\n   * The header allow developers to test [integrity policies](/en-US/docs/Web/Security/Subresource_Integrity#integrity_policy) and fix any content issues before eventually deploying an [Integrity-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Integrity-Policy) header to enforce the policy.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Integrity-Policy-Report-Only: blocked-destinations=(<destination>),sources=(<source>),endpoints=(<endpoint>)\n   * ```\n   *\n   * The header values are defined as structured field dictionaries with the following keys:\n   *\n   * - `blocked-destinations`\n   *   - : A list of [request destinations](/en-US/docs/Web/API/Request/destination) that must include valid integrity metadata.\n   *     Allowed values are:\n   *     - `script`\n   *       - : Script resources.\n   *\n   * - `sources`\n   *   - : A list of integrity sources that must include integrity metadata.\n   *     Allowed values are:\n   *     - `inline`\n   *       - : The integrity metadata source is inline to the content, such as the [integrity attribute](/en-US/docs/Web/API/HTMLScriptElement/integrity).\n   *         This is the default.\n   *\n   *         As this is the default and only value, omitting `sources` is equivalent to specifying `sources=(inline)`.\n   *\n   * - `endpoints`\n   *   - : A list of [reporting endpoint names](/en-US/docs/Web/HTTP/Reference/Headers/Reporting-Endpoints#endpoint) that indicate where reports will be sent.\n   *     The reporting endpoints must be defined in a [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/httpheader/Reporting-Endpoints) header.\n   *\n   * ## Examples\n   *\n   * ### Reporting when scripts lack integrity metadata\n   *\n   * This example shows a document that reports when any [script](https://developer.mozilla.org/en-US/docs/htmlelement/script) (or `HTMLScriptElement`) does not specify an `integrity` attribute, or when a script resource is requested in [no-cors](/en-US/docs/Web/API/Request/mode#no-cors) mode.\n   *\n   * Note that the `integrity-endpoint` used in `Integrity-Policy-Report-Only` is defined in the [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/httpheader/Reporting-Endpoints) header.\n   *\n   * ```http\n   * Reporting-Endpoints: integrity-endpoint=https://example.com/integrity, backup-integrity-endpoint=https://report-provider.example/integrity\n   * Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint, backup-integrity-endpoint)\n   * ```\n   *\n   * The [report payload](/en-US/docs/Web/API/Reporting_API#reporting_server_endpoints) might look like this.\n   *\n   * ```json\n   * {\n   *   \"type\": \"integrity-violation\",\n   *   \"url\": \"https://example.com\",\n   *   \"body\": {\n   *     \"documentURL\": \"https://example.com\",\n   *     \"blockedURL\": \"https://example.com/main.js\",\n   *     \"destination\": \"script\",\n   *     \"reportOnly\": false\n   *   }\n   * }\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Integrity-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Integrity-Policy)\n   * - [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Reporting-Endpoints)\n   * - [Integrity Policy](/en-US/docs/Web/Security/Subresource_Integrity#integrity_policy)\n   * - [Reporting API](/en-US/docs/Web/API/Reporting_API)\n   */\n  'Integrity-Policy-Report-Only' = 'Integrity-Policy-Report-Only',\n\n  /**\n   * The HTTP **`Integrity-Policy`** response header allows website administrators to ensure that all resources the user agent loads (of a certain type) have [Subresource Integrity](/en-US/docs/Web/Security/Subresource_Integrity) guarantees.\n   *\n   * When set the user agent will block requests on specified [request destinations](/en-US/docs/Web/API/Request/destination) that omit integrity metadata, and will also block requests in [no-cors](/en-US/docs/Web/API/Request/mode#no-cors) mode from ever being made.\n   *\n   * Violation reports may also be sent to if the header includes a reporting endpoint name that matches an endpoint declared using the [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Reporting-Endpoints) header.\n   * Reports are generated using the [Reporting API](/en-US/docs/Web/API/Reporting_API), and may also be observed in the page for which the integrity policy is being enforced, using a [ReportingObserver](/en-US/docs/Web/API/ReportingObserver).\n   * The format of the report body is given by the [IntegrityViolationReportBody](https://developer.mozilla.org/en-US/docs/domxref/IntegrityViolationReportBody) dictionary (a JSON-serialized form of this body is sent in POSTs to reporting server endpoints).\n   *\n   * This helps guard against content manipulation of fetched subresources.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Integrity-Policy: blocked-destinations=(<destination>),sources=(<source>),endpoints=(<endpoint>)\n   * ```\n   *\n   * The header values are defined as structured field dictionaries with the following keys:\n   *\n   * - `blocked-destinations`\n   *   - : A list of [request destinations](/en-US/docs/Web/API/Request/destination) that must include valid integrity metadata.\n   *     Allowed values are:\n   *     - `script`\n   *       - : Script resources.\n   *\n   * - `sources`\n   *   - : A list of integrity sources that must include integrity metadata.\n   *     Allowed values are:\n   *     - `inline`\n   *       - : The integrity metadata source is inline to the content, such as the [integrity attribute](/en-US/docs/Web/API/HTMLScriptElement/integrity).\n   *         This is the default.\n   *\n   *         As this is the default and only value, omitting `sources` is equivalent to specifying `sources=(inline)`.\n   *\n   * - `endpoints`\n   *   - : A list of [reporting endpoint names](/en-US/docs/Web/HTTP/Reference/Headers/Reporting-Endpoints#endpoint) that indicate where reports will be sent.\n   *     The reporting endpoints must be defined in a [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/httpheader/Reporting-Endpoints) header.\n   *\n   * ## Examples\n   *\n   * ### Blocking and reporting when scripts lack integrity metadata\n   *\n   * This example shows a document that blocks and reports when any [script](https://developer.mozilla.org/en-US/docs/htmlelement/script) (or `HTMLScriptElement`) does not specify an `integrity` attribute, or when a script resource is requested in [no-cors](/en-US/docs/Web/API/Request/mode#no-cors) mode.\n   *\n   * Note that the `integrity-endpoint` used in `Integrity-Policy` is defined in the [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/httpheader/Reporting-Endpoints) header.\n   *\n   * ```http\n   * Reporting-Endpoints: integrity-endpoint=https://example.com/integrity, backup-integrity-endpoint=https://report-provider.example/integrity\n   * Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint, backup-integrity-endpoint)\n   * ```\n   *\n   * The [report payload](/en-US/docs/Web/API/Reporting_API#reporting_server_endpoints) might look like this.\n   *\n   * ```json\n   * {\n   *   \"type\": \"integrity-violation\",\n   *   \"url\": \"https://example.com\",\n   *   \"body\": {\n   *     \"documentURL\": \"https://example.com\",\n   *     \"blockedURL\": \"https://example.com/main.js\",\n   *     \"destination\": \"script\",\n   *     \"reportOnly\": false\n   *   }\n   * }\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Integrity-Policy-Report-Only](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Integrity-Policy-Report-Only)\n   * - [Integrity Policy](/en-US/docs/Web/Security/Subresource_Integrity#integrity_policy)\n   * - [Reporting API](/en-US/docs/Web/API/Reporting_API)\n   */\n  'Integrity-Policy' = 'Integrity-Policy',\n\n  /**\n   * The HTTP **`Keep-Alive`** [request](https://developer.mozilla.org/en-US/docs/Glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) allows the sender to hint how a connection may be used in terms of a timeout and a maximum amount of requests.\n   *\n   * > [!NOTE]\n   * > For `Keep-Alive` to have any effect, the message must also include a [Connection: keep-alive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection) header.\n   *\n   * HTTP/1.0 closes the connection after each request/response interaction by default, so persistent connections in HTTP/1.0 must be explicitly negotiated.\n   * Some clients and servers might wish to be compatible with previous approaches to persistent connections, and can do this with a `Connection: keep-alive` request header.\n   * Additional parameters for the connection can be requested with the `Keep-Alive` header.\n   *\n   * > [!WARNING]\n   * > Connection-specific header fields such as [Connection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection) and `Keep-Alive` are prohibited in [HTTP/2](https://httpwg.org/specs/rfc9113.html#ConnectionSpecific) and [HTTP/3](https://httpwg.org/specs/rfc9114.html#header-formatting).\n   * > Chrome and Firefox ignore them in HTTP/2 responses, but Safari conforms to the HTTP/2 specification requirements and does not load any response that contains them.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Keep-Alive: <parameters>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<parameters>`\n   *   - : A comma-separated list of parameters, each consisting of an identifier and a value separated by the equal sign (`=`).\n   *     The following identifiers are possible:\n   *     - `timeout`\n   *       - : An integer that is the time in seconds that the host will allow an idle connection to remain open before it is closed.\n   *         A connection is idle if no data is sent or received by a host. A host may keep an idle connection open for longer than `timeout` seconds, but the host should attempt to retain a connection for at least `timeout` seconds.\n   *     - `max`\n   *       - : An integer that is the maximum number of requests that can be sent on this connection before closing it.\n   *         Unless `0`, this value is ignored for non-pipelined connections as another request will be sent in the next response.\n   *         An HTTP pipeline can use it to limit the pipelining.\n   *\n   * ## Examples\n   *\n   * A response containing a `Keep-Alive` header:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Connection: Keep-Alive\n   * Content-Encoding: gzip\n   * Content-Type: text/html; charset=utf-8\n   * Date: Thu, 11 Aug 2016 15:23:13 GMT\n   * Keep-Alive: timeout=5, max=200\n   * Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT\n   * Server: Apache\n   *\n   * (body)\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Connection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection)\n   * - [Connection management in HTTP/1.x](/en-US/docs/Web/HTTP/Guides/Connection_management_in_HTTP_1.x)\n   */\n  'Keep-Alive' = 'Keep-Alive',\n\n  /**\n   * The HTTP **`Last-Modified`** [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) contains a date and time when the origin server believes the resource was last modified.\n   * It is used as a validator in [conditional requests](/en-US/docs/Web/HTTP/Guides/Conditional_requests) ([If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since) or [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since)) to determine if a requested resource is the same as one already stored by the client.\n   * It is less accurate than an [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) for determining file contents, but can be used as a fallback mechanism if ETags are unavailable.\n   *\n   * `Last-Modified` is also used by [crawlers](/en-US/docs/Glossary/Crawler) to adjust crawl frequency, by browsers in [heuristic caching](/en-US/docs/Web/HTTP/Guides/Caching#heuristic_caching), and by content management systems (CMS) to display the time the content was last modified.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<day-name>`\n   *   - : One of \"Mon\", \"Tue\", \"Wed\", \"Thu\", \"Fri\", \"Sat\", or \"Sun\" (case-sensitive).\n   * - `<day>`\n   *   - : 2 digit day number, e.g., \"04\" or \"23\".\n   * - `<month>`\n   *   - : One of \"Jan\", \"Feb\", \"Mar\", \"Apr\", \"May\", \"Jun\", \"Jul\", \"Aug\", \"Sep\", \"Oct\", \"Nov\", \"Dec\" (case-sensitive).\n   * - `<year>`\n   *   - : 4 digit year number, e.g., \"1990\" or \"2016\".\n   * - `<hour>`\n   *   - : 2 digit hour number, e.g., \"09\" or \"23\".\n   * - `<minute>`\n   *   - : 2 digit minute number, e.g., \"04\" or \"59\".\n   * - `<second>`\n   *   - : 2 digit second number, e.g., \"04\" or \"59\".\n   * - GMT\n   *   - : Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Etag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Etag)\n   * - [HTTP Conditional Requests](/en-US/docs/Web/HTTP/Guides/Conditional_requests) guide\n   * - [If-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match), [If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since), [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since), [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match) conditional request headers\n   * - [304 Not Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304), [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) response status codes\n   */\n  'Last-Modified' = 'Last-Modified',\n\n  /**\n   * The HTTP **`Link`** header provides a means for serializing one or more links in HTTP headers.\n   * This allows the server to point a client to another resource containing metadata about the requested resource.\n   * This header has the same semantics as the HTML [link](https://developer.mozilla.org/en-US/docs/HTMLElement/link) element.\n   * One benefit of using the `Link` header is that the browser can start preconnecting or preloading resources before the HTML itself is fetched and processed.\n   *\n   * In practice, most [`rel` link types](/en-US/docs/Web/HTML/Reference/Attributes/rel) don't have an effect when used with the HTTP header.\n   * For example, the `icon` relation only works in HTML, and `stylesheet` does not work reliably across browsers (only in Firefox).\n   * The only relations that work reliably are [`preconnect`](/en-US/docs/Web/HTML/Reference/Attributes/rel/preconnect) and [`preload`](/en-US/docs/Web/HTML/Reference/Attributes/rel/preload), which can be combined with .\n   *\n   * ; rel=preload; as=style; fetchpriority=\"high\"\n   * ```\n   *\n   * Note that both the internal prioritization for fetching resources and the effect of the `fetchpriority` directive are browser-dependent.\n   * The `fetchpriority` directive should be used sparingly, and only in cases where a browser cannot infer that a particular resource should be treated with a different priority.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [103 Early Hints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103)\n   * - [link](https://developer.mozilla.org/en-US/docs/HTMLElement/link)\n   * - [Link Relations](https://www.iana.org/assignments/link-relations/link-relations.xhtml) IANA registry\n   * - [Optimize resource loading with the Fetch Priority API](https://web.dev/articles/fetch-priority?hl=en#browser_priority_and_fetchpriority) for information about how this API affects priorities on Chrome.\n   */\n  'Link' = 'Link',\n\n  /**\n   * The HTTP **`Location`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates the URL to redirect a page to.\n   * It only provides a meaning when served with a `3XX` [redirection response](/en-US/docs/Web/HTTP/Reference/Status#redirection_messages) or a [201 Created](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201) status response.\n   *\n   * In redirections, the HTTP method used to make the redirected request to fetch the page pointed to by `Location` depends on the original method and the kind of redirection:\n   *\n   * - [303 See Other](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/303) responses always result in a [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) request in the redirection.\n   * - [307 Temporary Redirect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307) and [308 Permanent Redirect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308) use the same method as the initiating request.\n   * - [301 Moved Permanently](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301) and [302 Found](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302) should use the same request method as the initiating request, although this is not guaranteed for older user-agents.\n   *\n   * All responses with one of the above status codes include a `Location` header.\n   *\n   * In cases of resource creation, it indicates the URL of the newly-created resource so that a client can make a request for it immediately.\n   *\n   * `Location` and [Content-Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Location) are different.\n   * `Content-Location` indicates the URL to use to directly access the resource in future when [content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation) occurred.\n   * `Location` is associated with the response, while [Content-Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Location) is associated with the representation that was returned.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Location: <url>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<url>`\n   *   - : May be relative to the request URL or an absolute URL.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Location: /index.html\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Content-Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Location)\n   * - Status responses including a `Location` header: [201](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201), [301](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301), [302](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302), [303](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/303), [307](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307), [308](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308).\n   */\n  'Location' = 'Location',\n\n  /**\n   * The HTTP **`Max-Forwards`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is used with the [TRACE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/TRACE) and [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS) method to limit the number of nodes (usually [proxies](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server)) that the request goes through.\n   *\n   * Its value is an integer indicating the _maximum amount_ of nodes it must visit.\n   * At each node, the value is decremented and the request is forwarded to the next node until the destination is reached or the received value of `Max-Forwards` is zero.\n   * The request is then sent back (excluding sensitive headers where appropriate) as the body of a [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) response.\n   * This allows the client to see what is being received at the other end of the request chain (the [Via](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Via) header is of particular interest) for testing or diagnostic purposes.\n   *\n   * If the `Max-Forwards` header is not present in a `TRACE` or `OPTIONS` request, a node will assume that there is no maximum number of forwards.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Max-Forwards: <integer>\n   * ```\n   *\n   * ## Examples\n   *\n   * ```http\n   * Max-Forwards: 0\n   * Max-Forwards: 10\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * This feature is neither targeted at, nor implemented in, browsers.\n   *\n   * ## See also\n   *\n   * - [TRACE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/TRACE) method\n   * - [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS) method\n   * - [405 Method Not Allowed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405)\n   */\n  'Max-Forwards' = 'Max-Forwards',\n\n  /**\n   * The HTTP **`NEL`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used to configure network request logging.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * NEL: { \"report_to\": \"name_of_reporting_group\", \"max_age\": 12345, \"include_subdomains\": false, \"success_fraction\": 0.0, \"failure_fraction\": 1.0 }\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Network Error Logging (NEL) explainer](/en-US/docs/Web/HTTP/Guides/Network_Error_Logging)\n   */\n  'NEL' = 'NEL',\n\n  /**\n   * The HTTP **`No-Vary-Search`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) specifies a set of rules that define how a URL's query parameters will affect cache matching.\n   * These rules dictate whether the same URL with different URL parameters should be saved as separate browser cache entries.\n   *\n   * This allows the browser to reuse existing resources despite mismatching URL parameters to avoid the expense of fetching the resource again, when the same content will be returned.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * No-Vary-Search: key-order\n   * No-Vary-Search: params\n   * No-Vary-Search: params=(\"param1\" \"param2\")\n   * No-Vary-Search: params, except=(\"param1\" \"param2\")\n   * No-Vary-Search: key-order, params, except=(\"param1\")\n   * ```\n   *\n   * ## Directives\n   *\n   * - `key-order`\n   *   - : Indicates that URLs will not be cached as separate entries if _the order_ in which parameters appear in the URL is the only difference.\n   *     The presence of other parameters _will_ cause URLs to be cached separately.\n   * - `params`\n   *   - : Either a boolean or a list of strings:\n   *     - As a boolean (`params`), it indicates that URLs that differ only by their parameters will not be cached as separate entries.\n   *     - An inner list of space-separated strings (`params=(\"param1\" \"param2\")`).\n   *       Indicates that URLs that differ only by the listed parameters will not be cached as separate entries.\n   *       The presence of other parameters _will_ cause them to be cached separately.\n   * - `except`\n   *   - : An inner list of space-separated strings (`except=(\"param1\" \"param2\")`).\n   *     Indicates that URLs that differ only by the listed parameters _will_ be cached as separate entries.\n   *     A boolean `params` directive has to be included for it to take effect (`params, except=(\"param1\" \"param2\")`).\n   *     The presence of other parameters that are not in the `except=` list _won't_ cause URLs to be cached as separate entries.\n   *\n   * ## Description\n   *\n   * ### Relationship with the Speculation Rules API\n   *\n   * The [Speculation Rules API](/en-US/docs/Web/API/Speculation_Rules_API) supports using the `No-Vary-Search` header to reuse an existing prefetched or prerendered page for different URL parameters — if they are included in the `No-Vary-Search` header.\n   *\n   * > [!WARNING]\n   * > Additional care must be taken when using prerender with `No-Vary-Search` since the page may initially be prerendered with different URL parameters. `No-Vary-Search` is used for URL parameters that deliver the same resource from the server, but are used by the client for various reasons (client-side rendering, UTM parameters for analytics measurement, etc.). As the initial prerender may be for different URL parameters, any code depending on them should only run after prerender activation.\n   *\n   * The Speculation Rules API can also include an `expects_no_vary_search` field, which indicates to the browser what the expected `No-Vary-Search` value will be (if any) for documents that it is receiving prefetch/prerender requests for via the speculation rules. The browser can use this to determine ahead of time whether it is more useful to wait for an existing prefetch/prerender to finish, or start a new fetch request when the speculation rule is matched. See the [\"expects_no_vary_search\" example](/en-US/docs/Web/HTML/Reference/Elements/script/type/speculationrules#expects_no_vary_search_example) for an explanation of how this can be used.\n   *\n   * ## Examples\n   *\n   * ### Allowing responses from URLs with differently ordered params to match the same cache entry\n   *\n   * If you have for example a search page that stores its search criteria in URL parameters, and you can't guarantee that the parameters will be added to the URL in the same order each time, you can allow responses from URLs that are identical except for the order of the parameters to match the same cache entry using `key-order`:\n   *\n   * ```http\n   * No-Vary-Search: key-order\n   * ```\n   *\n   * When this header is added to the associated responses, the following URLs would be treated as equivalent when searching the cache:\n   *\n   * ```plain\n   * https://search.example.com?a=1&b=2&c=3\n   * https://search.example.com?b=2&a=1&c=3\n   * ```\n   *\n   * The presence of different URL parameters, however, will cause these URLs to be cached separately. For example:\n   *\n   * ```plain\n   * https://search.example.com?a=1&b=2&c=3\n   * https://search.example.com?b=2&a=1&c=3&d=4\n   * ```\n   *\n   * The below examples illustrate how to control which parameters are ignored in the context of cache matching.\n   *\n   * ### Allowing responses from URLs with a different param to match the same cache entry\n   *\n   * Consider a case where a user directory landing page, `/users`, has already been cached. An `id` parameter might be used to bring up information on a specific user, for example `/users?id=345`. Whether this URL should be considered identical for cache matching purposes depends on the behavior of the application:\n   *\n   * - If this parameter has the effect of loading a completely new page containing the information for the specified user, then the response from this URL should be cached separately.\n   * - If this parameter has the effect of highlighting the specified user on the same page, and perhaps revealing a pullout panel displaying their data, then it would be better for the browser to use the cached response for `/users`. This could result in performance improvements around the loading of the user pages.\n   *\n   * If your application behaves like the second example described above, you could cause both `/users` and `/users?id=345` to be treated as identical for caching purposes via a `No-Vary-Search` header like so:\n   *\n   * ```http\n   * No-Vary-Search: params=(\"id\")\n   * ```\n   *\n   * > [!NOTE]\n   * > If a parameter is excluded from the cache key using `params`, if it is included in the URL it will be ignored for the purposes of cache matching, regardless of where it appears in the parameter list.\n   *\n   * ### Allowing responses from URLs with multiple different params to match the same cache entry\n   *\n   * Say you also had URL parameters that sorted the list of users on the page in ascending or descending alphabetical order, and specified the language to display the UI strings in, for example `/users?id=345&order=asc&lang=fr`.\n   *\n   * You could get the browser to ignore all of these when considering cache matching like so:\n   *\n   * ```http\n   * No-Vary-Search: params=(\"id\" \"order\" \"lang\")\n   * ```\n   *\n   * > [!NOTE]\n   * > As a [structured field](https://www.rfc-editor.org/rfc/rfc8941), the parameters should be space-separated, quoted strings — as shown above — and not comma-separated, which developers may be more used to.\n   *\n   * If you wanted the browser to ignore all of them _and_ any others that might be present when cache matching, you could use the boolean form of `params`:\n   *\n   * ```http\n   * No-Vary-Search: params\n   * ```\n   *\n   * ### Specifying params that _do_ cause cache matching misses\n   *\n   * Say the app behaved differently, with `/users` pointing to the main user directory landing page and `/users?id=345` pointing to a completely separate detail page for a specific user. In this case you would want the browser to ignore all the parameters mentioned above for cache matching purposes, _except_ for `id`, the presence of which would cause the browser to not match the `/users` cache entry and request `/users?id=345` from the server.\n   *\n   * This can be achieved like so:\n   *\n   * ```http\n   * No-Vary-Search: params, except=(\"id\")\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   */\n  'No-Vary-Search' = 'No-Vary-Search',\n\n  /**\n   * > [!WARNING]\n   * > This feature is currently opposed by two browser vendors. See the [Standards positions](/en-US/docs/Web/API/Topics_API#standards_positions) section for details of opposition.\n   *\n   * The HTTP **`Observe-Browsing-Topics`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used to mark topics of interest inferred from a calling site's URL (i.e., the site where the ad tech [iframe](https://developer.mozilla.org/en-US/docs/HTMLElement/iframe) is embedded) as observed in the response to a request generated by a [feature that enables the Topics API](/en-US/docs/Web/API/Topics_API/Using#what_api_features_enable_the_topics_api).\n   * The browser will subsequently use those topics to calculate top topics for the current user for future epochs.\n   *\n   * See [Using the Topics API](/en-US/docs/Web/API/Topics_API/Using) for more details.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Observe-Browsing-Topics: ?1\n   * ```\n   *\n   * ### Directives\n   *\n   * - `?1`\n   *   - : A character sequence declaring that topics of interest inferred from a calling site's URL (i.e., the site where the ad tech `<iframe>` is embedded) are marked as observed. The browser will subsequently use those topics to calculate topics of interest for a user for future epochs.\n   *\n   * ## Specifications\n   *\n   * This feature is not part of an official standard, although it is specified in the [Topics API Unofficial Proposal Draft](https://patcg-individual-drafts.github.io/topics/).\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Topics API](/en-US/docs/Web/API/Topics_API)\n   */\n  'Observe-Browsing-Topics' = 'Observe-Browsing-Topics',\n\n  /**\n   * The HTTP **`Origin-Agent-Cluster`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used to request that the associated [Document](https://developer.mozilla.org/en-US/docs/domxref/Document) should be placed in an origin-keyed [agent cluster](/en-US/docs/Web/JavaScript/Reference/Execution_model#agent_clusters_and_memory_sharing).\n   * This means that operating system resources (for example, the operating system process) used to evaluate the document should be shared only with other documents from the same [origin](https://developer.mozilla.org/en-US/docs/glossary/origin).\n   *\n   * The effect of this is that a resource-intensive document will be less likely to degrade the performance of documents from other origins.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Origin-Agent-Cluster: <boolean>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<boolean>`\n   *   - : `?1` indicates that the associated [Document](https://developer.mozilla.org/en-US/docs/domxref/Document) should be placed in an origin-keyed agent cluster.\n   *     Values other than `?1` are ignored (e.g., the `?0` structured field for false).\n   *\n   * ## Description\n   *\n   * Modern web browsers have a multiprocess architecture in which pages from different origins can run in different operating system processes. This is important for performance, because it means that a resource-intensive page will not have as much of an impact on other pages that the user has open.\n   *\n   * However, browsers can't as a general rule run [same-site](https://developer.mozilla.org/en-US/docs/glossary/site), [cross-origin](https://developer.mozilla.org/en-US/docs/glossary/origin) pages in different processes, because of certain DOM APIs that depend on same-site, cross-origin communication. For example, by default, pages from the following two origins will share the same operating system resources:\n   *\n   * ```plain\n   * https://apples.example.org\n   * https://oranges.example.org\n   * ```\n   *\n   * By setting the `Origin-Agent-Cluster` header, a page can request that the browser allocate dedicated resources to this origin that are not shared with any other origins.\n   *\n   * The browser is not required to honor the request. If it does, the [Window.originAgentCluster](https://developer.mozilla.org/en-US/docs/domxref/Window.originAgentCluster) property returns `true`, and the window is not able to do the following things, which all depend on same-site, cross-origin communication:\n   *\n   * - Use [Document.domain](https://developer.mozilla.org/en-US/docs/domxref/Document.domain).\n   * - Send [`WebAssembly.Module`](/en-US/docs/WebAssembly/Reference/JavaScript_interface/Module) objects to other same-site cross-origin pages using [postMessage()](https://developer.mozilla.org/en-US/docs/domxref/Window.postMessage()).\n   * - Send [SharedArrayBuffer](https://developer.mozilla.org/en-US/docs/jsxref/SharedArrayBuffer) or [`WebAssembly.Memory`](/en-US/docs/WebAssembly/Reference/JavaScript_interface/Memory) objects to other same-site cross-origin pages.\n   *\n   * Origin-keyed agent clusters should not be viewed as a security feature: browsers may ignore the request for various reasons, or choose to implement it in a way that does not provide memory protection (for example, using separate threads instead of separate processes). Instead, this feature is a hint that the user experience would be improved if this origin were allocated dedicated resources.\n   *\n   * For example, suppose your site includes a page from one origin that embeds a same-site, cross-origin iframe which runs a resource-intensive game. By setting `Origin-Agent-Cluster` on the document in the iframe, you can prevent the game from affecting the performance of the main page.\n   *\n   * The browser will ensure that all pages from a given origin are either origin-keyed or they are not. This means that:\n   *\n   * - If the first page from an origin does not set the header, then no other pages from that origin will be origin-keyed, even if those other pages do set the header.\n   * - If the first page from an origin sets the header and is made origin-keyed, then all other pages from that origin will be origin-keyed whether they ask for it or not.\n   *\n   * To avoid this kind of unpredictable situation, you should set this header for all pages from a given origin, or none of them.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Origin-Agent-Cluster: ?1\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Window.originAgentCluster](https://developer.mozilla.org/en-US/docs/domxref/Window.originAgentCluster)\n   * - [Agent clusters and memory sharing](/en-US/docs/Web/JavaScript/Reference/Execution_model#agent_clusters_and_memory_sharing) in _JavaScript execution model_\n   * - [Requesting performance isolation with the Origin-Agent-Cluster header](https://web.dev/articles/origin-agent-cluster) on web.dev\n   */\n  'Origin-Agent-Cluster' = 'Origin-Agent-Cluster',\n\n  /**\n   * The HTTP **`Origin`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates the [origin](https://developer.mozilla.org/en-US/docs/glossary/origin) ([scheme](/en-US/docs/Web/URI/Reference/Schemes), hostname, and port) that _caused_ the request.\n   * For example, if a user agent needs to request resources included in a page, or fetched by scripts that it executes, then the origin of the page may be included in the request.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Origin: null\n   * Origin: <scheme>://<hostname>\n   * Origin: <scheme>://<hostname>:<port>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `null`\n   *   - : The origin is \"privacy sensitive\", or is an _opaque origin_ as defined by the HTML specification (specific cases are listed in the [description](#description) section).\n   * - `<scheme>`\n   *   - : The protocol that is used.\n   *     Usually, it is the HTTP protocol or its secured version, HTTPS.\n   * - `<hostname>`\n   *   - : The domain name or the IP address of the origin server.\n   * - `<port>`\n   *   - : Port number on which the server is listening.\n   *     If no port is given, the default port for the requested service is implied from the scheme (e.g., `80` for an HTTP URL).\n   *\n   * ## Description\n   *\n   * The `Origin` header is similar to the [Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer) header, but does not disclose the path, and may be `null`.\n   * It is used to provide the security context for the origin request, except in cases where the origin information would be sensitive or unnecessary.\n   *\n   * Broadly speaking, user agents add the `Origin` request header to:\n   *\n   * - [cross origin](https://developer.mozilla.org/en-US/docs/Glossary/CORS) requests.\n   * - [same-origin](/en-US/docs/Web/Security/Same-origin_policy) requests except for [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) or [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) requests (i.e., they are added to same-origin [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST), [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS), [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT), [PATCH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PATCH), and [DELETE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/DELETE) requests).\n   *\n   * There are some exceptions to the above rules; for example, if a cross-origin [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) or [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) request is made in [no-cors mode](/en-US/docs/Web/API/Request/mode#value), the `Origin` header will not be added.\n   *\n   * The `Origin` header value may be `null` in a number of cases, including (non-exhaustively):\n   *\n   * - Origins whose [scheme](/en-US/docs/Web/URI/Reference/Schemes) is not one of `http`, `https`, `ftp`, `ws`, `wss`, or `gopher` (including `blob`, `file` and `data`).\n   * - Cross-origin images and media data, including that in [img](https://developer.mozilla.org/en-US/docs/HTMLElement/img), [video](https://developer.mozilla.org/en-US/docs/HTMLElement/video) and [audio](https://developer.mozilla.org/en-US/docs/HTMLElement/audio) elements.\n   * - Documents created programmatically using [createDocument()](https://developer.mozilla.org/en-US/docs/domxref/DOMImplementation.createDocument), generated from a `data:` URL, or that do not have a creator browsing context.\n   * - Redirects across origins.\n   * - [iframes](https://developer.mozilla.org/en-US/docs/HTMLElement/iframe) with a sandbox attribute that doesn't contain the value `allow-same-origin`.\n   * - Responses that are network errors.\n   * - [Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy) set to `no-referrer` for non-`cors` request modes (e.g., basic form posts).\n   *\n   * > [!NOTE]\n   * > There is a more detailed listing of cases that may return `null` on Stack Overflow: [When do browsers send the Origin header? When do browsers set the origin to null?](https://stackoverflow.com/questions/42239643/when-do-browsers-send-the-origin-header-when-do-browsers-set-the-origin-to-null/42242802)\n   *\n   * ## Examples\n   *\n   * ```http\n   * Origin: https://developer.mozilla.org\n   * ```\n   *\n   * ```http\n   * Origin: https://developer.mozilla.org:80\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host)\n   * - [Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer)\n   * - [Same-origin policy](/en-US/docs/Web/Security/Same-origin_policy)\n   * - [When do browsers send the Origin header? When do browsers set the origin to null?](https://stackoverflow.com/questions/42239643/when-do-browsers-send-the-origin-header-when-do-browsers-set-the-origin-to-null/42242802) (Stack Overflow)\n   */\n  'Origin' = 'Origin',\n\n  /**\n   * The HTTP **`Permissions-Policy`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) provides a mechanism to allow and deny the use of browser features in a document or within any [iframe](https://developer.mozilla.org/en-US/docs/HTMLElement/iframe) elements in the document.\n   *\n   * For more information, see the main [Permissions Policy](/en-US/docs/Web/HTTP/Guides/Permissions_Policy) article.\n   *\n   *\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Permissions Policy](/en-US/docs/Web/HTTP/Guides/Permissions_Policy)\n   * - [Document.featurePolicy](https://developer.mozilla.org/en-US/docs/DOMxRef/Document.featurePolicy) and [FeaturePolicy](https://developer.mozilla.org/en-US/docs/DOMxRef/FeaturePolicy)\n   * - [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)\n   * - [Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy)\n   */\n  'Permissions-Policy' = 'Permissions-Policy',\n\n  /**\n   * The HTTP **`Pragma`** header is an implementation-specific header that may have various effects along the request-response chain.\n   * This header serves for backwards compatibility with HTTP/1.0 caches that do not support the [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) HTTP/1.1 header.\n   *\n   * > [!NOTE]\n   * > The `Pragma` header is not specified for HTTP responses and is therefore not a reliable replacement for the HTTP/1.1 `Cache-Control` header, although its behavior is the same as `Cache-Control: no-cache` if the `Cache-Control` header field is omitted in a request.\n   * > Use `Pragma` only for backwards compatibility with HTTP/1.0 clients.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Pragma: no-cache\n   * ```\n   *\n   * ## Directives\n   *\n   * - `no-cache`\n   *   - : Same as `Cache-Control: no-cache`. Forces caches to submit the request to the origin server for validation before a cached copy is released.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Pragma: no-cache\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)\n   * - [Expires](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires)\n   */\n  'Pragma' = 'Pragma',\n\n  /**\n   * The HTTP **`Prefer`** header allows clients to indicate preferences for specific server behaviors during request processing.\n   *\n   * > [!NOTE]\n   * > Browsers have no handling for the `Prefer` and [Preference-Applied](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Preference-Applied) headers: they are used in custom, implementation-specific clients.\n   * > Ensure both client and server support this header before relying on it in production.\n   * >\n   * > Servers should silently ignore preferences that they do not support, as though the header were not present.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Prefer: <preference>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `respond-async`\n   *   - : The client prefers asynchronous processing.\n   *     For example, the server might respond with [202 Accepted](https://developer.mozilla.org/en-US/docs/httpstatus/202) response indicated that the request has been accepted, along with the [Location](https://developer.mozilla.org/en-US/docs/httpheader/Location) header that has a URL that the client can use to monitor the state of the processing.\n   * - `return=minimal`\n   *   - : Requests that the server return minimal content (a headers-only response).\n   * - `return=representation`\n   *   - : Requests a full resource representation in the response.\n   * - `wait=<seconds>`\n   *   - : The time within which the client expects the server to provide a response, from the point at which the request was received.\n   *     If the `respond-async` preference is also provided, the server should respond asynchronously if processing the request will exceed the wait time.\n   *     Otherwise, the server should consider that the client will timeout after the `wait` time (response behavior depends on server implementation).\n   * - `handling=lenient`\n   *   - : The client wishes the server to apply lenient validation and error handling to the processing of the request.\n   * - `handling=strict`\n   *   - : The client wishes the server to apply strict validation and error handling to the processing of the request.\n   * - Custom preference\n   *   - : Vendors or applications may define their own preferences to suit specific needs.\n   *     For example, `Prefer: timezone=America/Los_Angeles`.\n   *\n   * ## Examples\n   *\n   * ### Requesting minimal response\n   *\n   * The following request asks for a minimal response.\n   * This is typically a headers-only response (as opposed to `return=representation` where a representation is included in the response body):\n   *\n   * ```http\n   * POST /resource HTTP/1.1\n   * Host: example.com\n   * Content-Type: application/json\n   * Prefer: return=minimal\n   *\n   * {\"id\":123, \"name\": \"abc\"}\n   * ```\n   *\n   * The server responds with a [201](https://developer.mozilla.org/en-US/docs/httpstatus/201), but does not include any response body.\n   * The [Location](https://developer.mozilla.org/en-US/docs/httpheader/Location) header contains a URL with the location of the newly-created resource.\n   * There's no need to include a `Preference-Applied` header because the absence of a response body is readily apparent:\n   *\n   * ```http\n   * HTTP/1.1 201 Created\n   * Location: /resource?id=123\n   * ```\n   *\n   * ### Requesting asynchronous processing\n   *\n   * This example requests the server start an async processing task:\n   *\n   * ```http\n   * POST /process HTTP/1.1\n   * Host: example.com\n   * Prefer: respond-async\n   *\n   * {\n   *   \"task\": \"check-broken-links\"\n   * }\n   * ```\n   *\n   * The server responds with a [202 Accepted](https://developer.mozilla.org/en-US/docs/httpstatus/202) response indicated the request has been accepted and has not yet completed executing asynchronously.\n   * A `Location` header points to a status monitor that represents the state of the processing:\n   *\n   * ```http\n   * HTTP/1.1 202 Accepted\n   * Location: http://example.com/tasks/123/status\n   * ```\n   *\n   * ### Providing multiple preferences\n   *\n   * The following request includes two preferences; `timezone=Jupiter/Red_Spot` indicating a time zone preference for the client, and `handling=strict` for strict validation:\n   *\n   * ```http\n   * GET /events HTTP/1.1\n   * Host: example.com\n   * Prefer: handling=strict, timezone=Jupiter/Red_Spot\n   * ```\n   *\n   * In this implementation, an invalid time zone will throw an error:\n   *\n   * ```http\n   * HTTP/1.1 400 Bad Request\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## See also\n   *\n   * - [Preference-Applied](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Preference-Applied)\n   * - [Prefer header](https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#_Toc31358871) on docs.oasis-open.org\n   * - [Prefer header](https://docs.postgrest.org/en/v12/references/api/preferences.html) on docs.postgrest.org\n   */\n  'Prefer' = 'Prefer',\n\n  /**\n   * The HTTP **`Preference-Applied`** header informs the client about which preferences from the [Prefer](https://developer.mozilla.org/en-US/docs/httpheader/Prefer) request header were applied by the server.\n   *\n   * The server indicates if a preference is applied to a response if it would otherwise be ambiguous for the client.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Preference-Applied: <preference>\n   * ```\n   *\n   * ## Examples\n   *\n   * ### Server applies timezone preferences\n   *\n   * The following request indicates that the client prefers events to be represented in a certain time zone:\n   *\n   * ```http\n   * GET /events HTTP/1.1\n   * Host: example.com\n   * Prefer: timezone=America/Los_Angeles\n   * ```\n   *\n   * The server supports the preference and sends back the content with a `Preference-Applied` header:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Type: application/json\n   * Preference-Applied: timezone=America/Los_Angeles\n   *\n   * [\n   *   {\"t\":\"2023-10-18T05:37:59.611-07:00\"},\n   *   {\"t\":\"2023-10-18T07:37:59.611-07:00\"},\n   *   {\"t\":\"2023-10-18T09:37:59.611-07:00\"}\n   * ]\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## See also\n   *\n   * - [Prefer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Prefer)\n   * - [Prefer header](https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#_Toc31358871) on docs.oasis-open.org\n   * - [Prefer header](https://docs.postgrest.org/en/v12/references/api/preferences.html) on docs.postgrest.org\n   */\n  'Preference-Applied' = 'Preference-Applied',\n\n  /**\n   * The HTTP **`Priority`** header indicates a client's preference for the priority order at which the response containing the requested resource should be sent, relative to other resource requests on the same connection.\n   * If the header is not specified in the request, a default priority is assumed.\n   * The server may also include this header in responses in order to indicate it has an interest in changing the prioritization preferences the client advertized.\n   * In responses, this information can be used as an input to the prioritization process for caching servers and other servers that are forwarding the response.\n   *\n   * The server is not bound by client prioritization and might only use client priorities as hints for its own prioritization process.\n   * For example, a server may know that a specific image is vital for user experience and should be sent at the highest priority.\n   * Server prioritization might also be affected by factors such as network congestion.\n   *\n   * This request may be cached, and the server is expected to control the cacheability or the applicability of the cached response using the header fields that control the caching behavior, such as [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary).\n   *\n   * > [!NOTE]\n   * > This header is one part of the \"Extensible Prioritization Scheme for HTTP\" defined in [9218](https://developer.mozilla.org/en-US/docs/rfc/9218).\n   * > There are also HTTP/2 and HTTP/3 `PRIORITY_UPDATE` frames that can be used to re-prioritize a resource request after it has been sent.\n   * > The request can be sent in any HTTP version.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Priority: u=<priority>\n   * Priority: i\n   * Priority: u=<priority>, i\n   * ```\n   *\n   * ## Directives\n   *\n   * - `u=<priority>`\n   *   - : The \"urgency\" (`u`) parameter specifies a priority value `<priority>` for the resource.\n   *     The value is an integer between 0 and 7 inclusive, in descending order of priority (0 is the highest urgency).\n   *     The default priority value for requests is 3.\n   *     There is no default priority value for responses: the absence of the header in a response indicates that the server has chosen not to modify the client priority.\n   *     A priority of 7 should only be used for resources that are unlikely to affect the user experience, such as background tasks or delivery of software updates.\n   *\n   *     Browsers should request documents that are likely to use other resources at the default priority level.\n   *     The referenced resources should then be requested using values that reflect the relative impact on the user experience of their arrival time.\n   *\n   *     Servers may have a different view on the priority than the client, and can respond with a different value in order to provide a priority hint to intermediate servers.\n   *     The intermediate server may take this value into consideration along with the original request priority.\n   *     The absence of the `Priority` header in the response indicates that the server chosen not to modify the client priority.\n   *\n   * - `i`\n   *   - : The incremental (`i`) directive, if present, indicates than an HTTP response can be processed incrementally.\n   *\n   *     Resources that can be processed incrementally are those where the recipient can potentially do something useful as soon as a chunk arrives, rather than waiting for the complete resource to be available.\n   *\n   *     If a browser sets this directive then the server may choose to concurrently serve all incremental requests with the same urgency.\n   *     This distributes the multiple requests across the connection bandwidth, with the result that all the requests start being processed earlier, but take longer in total to complete.\n   *\n   *     If the browser does not set this directive then it is indicating that it will not process the resource incrementally.\n   *     Servers should in this case send responses with the same urgency one by one, in the order in which their associated requests were generated.\n   *\n   * > [!NOTE]\n   * > Servers are expected to ignore directives on this header that they do not understand.\n   * > New directives that are added in future are expected to be compatible with these existing directives so that they can be safely ignored.\n   *\n   * ## Examples\n   *\n   * ### Setting resource urgency\n   *\n   * The following example shows a request for an HTML file.\n   * The urgency isn't set, and so defaults to 3, with `i` being false.\n   * This is the normal setting for a document that owns other resources.\n   *\n   * ```http\n   * :method = GET\n   * :scheme = https\n   * :authority = example.net\n   * :path = /index.html\n   * ```\n   *\n   * The request below is a possible follow-on request for a CSS file used by the HTML.\n   * The urgency is set to 2, indicating that the browser considers it to be quite high priority, but `i` is unset because the CSS file can't be handled incrementally.\n   *\n   * ```http\n   * :method = GET\n   * :scheme = https\n   * :authority = example.net\n   * :path = /style.css\n   * priority = u=2\n   * ```\n   *\n   * > [!NOTE]\n   * > The requests above use the human-readable format from the HTTP/2 or HTTP/3 specifications.\n   * > The HTTP/1.1 format used in most of this documentation would be something like:\n   * >\n   * > ```http\n   * > GET /style.css HTTP/1.1\n   * > Host: example.net\n   * > Priority: u=2\n   * > ```\n   *\n   * A response might look as shown below.\n   * Note that in this case the `priority` is not specified, indicating that the server did not feel that it needed to change the priority for intermediate servers.\n   *\n   * ```http\n   * :status: 200\n   * content-type: text/css\n   * content-length: 610\n   * date: [current date]\n   * ```\n   *\n   * ### Setting the incremental directive\n   *\n   * The header below shows a browser request for an image that can be rendered incrementally.\n   * In this case, the priority is set to 4 (lower than the default of 3), and `i` is set to indicate that the client can process the JPG file incrementally.\n   *\n   * ```http\n   * :method = GET\n   * :path = /image.jpg\n   * :scheme = https\n   * :authority = example.net\n   * priority = u=4, i\n   * ```\n   *\n   * The server might send a response like the one below.\n   * In this case the priority is set to 1, indicating that the server has an understanding that particular image should be sent at high priority.\n   *\n   * ```http\n   * :status: 200\n   * content-type = image/jpeg\n   * content-length = 610\n   * ...\n   * priority = u=1, i\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)\n   * - [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   */\n  'Priority' = 'Priority',\n\n  /**\n   * The HTTP **`Proxy-Authenticate`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) defines the [authentication](/en-US/docs/Web/HTTP/Guides/Authentication) method (or [challenge](https://developer.mozilla.org/en-US/docs/Glossary/Challenge)) that should be used to gain access to a resource behind a [proxy server](https://developer.mozilla.org/en-US/docs/Glossary/proxy_server).\n   * It is sent in a [407 Proxy Authentication Required](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407) response so a client can identify itself to a proxy that requires authentication.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Proxy-Authenticate: <challenge>, …\n   * ```\n   *\n   * The value is a comma-separated list of challenges, where a `<challenge>` is comprised of an `<auth-scheme>`, followed by an optional `<token68>` or a comma-separated list of `<auth-params>`:\n   *\n   * ```plain\n   * challenge = <auth-scheme> <auth-param>, …, <auth-paramN>\n   * challenge = <auth-scheme> <token68>\n   * ```\n   *\n   * For example:\n   *\n   * ```http\n   * Proxy-Authenticate: <auth-scheme>\n   * Proxy-Authenticate: <auth-scheme> token68\n   * Proxy-Authenticate: <auth-scheme> auth-param1=param-token1\n   * Proxy-Authenticate: <auth-scheme> auth-param1=param-token1, …, auth-paramN=param-tokenN\n   * ```\n   *\n   * The presence of a `token68` or authentication parameters depends on the selected `<auth-scheme>`.\n   * For example, [Basic authentication](/en-US/docs/Web/HTTP/Guides/Authentication#basic_authentication_scheme) requires a `<realm>`, and allows for optional use of `charset` key, but does not support a `token68`:\n   *\n   * ```http\n   * Proxy-Authenticate: Basic realm=\"Dev\", charset=\"UTF-8\"\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<auth-scheme>`\n   *   - : A case-insensitive token indicating the [Authentication scheme](/en-US/docs/Web/HTTP/Guides/Authentication#authentication_schemes) used.\n   *     Some of the more common types are [`Basic`](/en-US/docs/Web/HTTP/Guides/Authentication#basic_authentication_scheme), `Digest`, `Negotiate` and `AWS4-HMAC-SHA256`.\n   *     IANA maintains a [list of authentication schemes](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml), but there are other schemes offered by host services.\n   * - `<auth-param>`\n   *   - : An authentication parameter whose format depends on the `<auth-scheme>`.\n   *     `<realm>` is described below as it's a common authentication parameter among many auth schemes.\n   *     - `<realm>`\n   *       - : The string `realm` followed by `=` and a quoted string describing a protected area, for example `realm=\"staging environment\"`.\n   *         A realm allows a server to partition the areas it protects (if supported by a scheme that allows such partitioning).\n   *         Some clients show this value to the user to inform them about which particular credentials are required — though most browsers stopped doing so to counter phishing.\n   *         The only reliably supported character set for this value is `us-ascii`.\n   *         If no realm is specified, clients often display a formatted hostname instead.\n   * - `<token68>`\n   *   - : A token that may be useful for some schemes.\n   *     The token allows the 66 unreserved URI characters plus a few others.\n   *     It can hold a [base64](https://developer.mozilla.org/en-US/docs/glossary/base64), base64url, base32, or base16 (hex) encoding, with or without padding, but excluding whitespace.\n   *     The `token68` alternative to auth-param lists is supported for consistency with legacy authentication schemes.\n   *\n   * Generally, you will need to check the relevant specifications for the authentication parameters needed for each `<auth-scheme>`.\n   *\n   * > [!NOTE]\n   * > See [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate) for more details on authentication parameters.\n   *\n   * ## Examples\n   *\n   * ### Proxy-Authenticate Basic auth\n   *\n   * The following response indicates a Basic auth scheme is required with a realm:\n   *\n   * ```http\n   * Proxy-Authenticate: Basic realm=\"Staging server\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate)\n   * - [HTTP authentication](/en-US/docs/Web/HTTP/Guides/Authentication)\n   * - [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization), [Proxy-Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authorization)\n   * - [401](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401), [403](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403), [407](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407)\n   */\n  'Proxy-Authenticate' = 'Proxy-Authenticate',\n\n  /**\n   * The HTTP **`Proxy-Authorization`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) contains the credentials to authenticate a client with a proxy server, typically after the server has responded with a [407 Proxy Authentication Required](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407) status with the [Proxy-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authenticate) header.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Proxy-Authorization: <auth-scheme> <credentials>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<auth-scheme>`\n   *   - : A case-insensitive token indicating the [Authentication scheme](/en-US/docs/Web/HTTP/Guides/Authentication#authentication_schemes) used.\n   *     Some of the more common types are [`Basic`](/en-US/docs/Web/HTTP/Guides/Authentication#basic_authentication_scheme), `Digest`, `Negotiate` and `AWS4-HMAC-SHA256`.\n   *     IANA maintains a [list of authentication schemes](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml), but there are other schemes offered by host services.\n   * - `<credentials>`\n   *   - : Credentials use for the authentication scheme.\n   *     Generally, you will need to check the relevant specifications for the format.\n   *\n   * > [!NOTE]\n   * > See [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) for more details.\n   *\n   * ## Examples\n   *\n   * ### Basic authentication\n   *\n   * In `Basic` auth, credentials are sent in the format `<username>:<password>` (for example, `aladdin:opensesame`).\n   * The resulting string is then [base64](/en-US/docs/Glossary/Base64) encoded (`YWxhZGRpbjpvcGVuc2VzYW1l`).\n   *\n   * ```http\n   * Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l\n   * ```\n   *\n   * > [!WARNING]\n   * > Base64 encoding is reversible, and therefore offers no cryptographic security.\n   * > This method can be considered equivalent to sending the credentials in clear text.\n   * > [HTTPS](https://developer.mozilla.org/en-US/docs/Glossary/HTTPS) is always recommended when using authentication, but is even more so when using `Basic` authentication.\n   *\n   * ### Bearer authentication (auth token)\n   *\n   * ```http\n   * Proxy-Authorization: Bearer kNTktNTA1My00YzLT1234\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## See also\n   *\n   * - [HTTP authentication](/en-US/docs/Web/HTTP/Guides/Authentication)\n   * - [Proxy-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authenticate)\n   * - [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate)\n   * - [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization)\n   * - [401](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401), [403](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403), [407](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407)\n   */\n  'Proxy-Authorization' = 'Proxy-Authorization',\n\n  /**\n   * The HTTP **`Range`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates the part of a resource that the server should return.\n   * Several parts can be requested at the same time in one `Range` header, and the server may send back these ranges in a multipart document.\n   * If the server sends back ranges, it uses the [206 Partial Content](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206) status code for the response.\n   * If the ranges are invalid, the server returns the [416 Range Not Satisfiable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416) error.\n   *\n   * A server that doesn't support range requests may ignore the `Range` header and return the whole resource with a [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) status code.\n   * Older browsers used a response header of [Accept-Ranges: none](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Ranges) to disable features like 'pause' or 'resume' in download managers, but since a server ignoring the `Range` header has the same meaning as responding with `Accept-Ranges: none`, the header is rarely used in this way.\n   *\n   * Currently only [`bytes` units are registered](https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#range-units) which are _offsets_ (zero-indexed & inclusive).\n   * If the requested data has a [content coding](/en-US/docs/Web/HTTP/Reference/Headers/Content-Encoding) applied, each byte range represents the encoded sequence of bytes, not the bytes that would be obtained after decoding.\n   *\n   * The header is a [CORS-safelisted request header](/en-US/docs/Glossary/CORS-safelisted_request_header) when the directive specifies a single byte range.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Range: <unit>=<range-start>-\n   * Range: <unit>=<range-start>-<range-end>\n   * Range: <unit>=<range-start>-<range-end>, …, <range-startN>-<range-endN>\n   * Range: <unit>=-<suffix-length>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<unit>`\n   *   - : The unit in which ranges are defined.\n   *     Currently only `bytes` are a registered unit.\n   * - `<range-start>`\n   *   - : An integer in the given unit indicating the start position of the request range.\n   * - `<range-end>`\n   *   - : An integer in the given unit indicating the end position of the requested range.\n   *     This value is optional and, if omitted, the end of the resource is used as the end of the range.\n   * - `<suffix-length>`\n   *   - : An integer indicating the number of units at the end of the resource to return.\n   *\n   * ## Examples\n   *\n   * The following examples show how to make requests using the `Range` header for CORS-safelisted requests, and for requesting multiple ranges.\n   * Other examples can be found in the [HTTP range requests](/en-US/docs/Web/HTTP/Guides/Range_requests) guide.\n   *\n   * ### Single byte ranges and CORS-safelisted requests\n   *\n   * The `Range` header is a [CORS-safelisted request header](/en-US/docs/Glossary/CORS-safelisted_request_header) when the value is a single byte range.\n   * This means that it can be used in cross-origin requests without triggering a [preflight](/en-US/docs/Glossary/Preflight_request) request, which is useful for requesting media and resuming downloads.\n   *\n   * The following example requests the first 500 bytes of a resource:\n   *\n   * ```http\n   * Range: bytes=0-499\n   * ```\n   *\n   * To request the second 500 bytes:\n   *\n   * ```http\n   * Range: bytes=500-999\n   * ```\n   *\n   * Omitting the end position requests all remaining units of the resource, so the last 100 bytes of a resource with a length of 1000 bytes can be requested using:\n   *\n   * ```http\n   * Range: bytes=900-\n   * ```\n   *\n   * Alternatively, if it's unknown how large a resource is, the last `n` bytes can be requested using a suffix range of `-n`:\n   *\n   * ```http\n   * Range: bytes=-100\n   * ```\n   *\n   * ### Requesting multiple ranges\n   *\n   * Given a resource with a length of 10000 bytes, the following example requests three separate ranges; `200`-`999` (800 bytes), `2000`-`2499` (500 bytes), and finally `9500-`.\n   * The ranges-specifier value `9500-` omits an end position which indicates that all bytes from 9500 onward are part of the third range (500 bytes).\n   *\n   * ```http\n   * Range: bytes=200-999, 2000-2499, 9500-\n   * ```\n   *\n   * This example requests the first 500 and last 500 bytes of the file.\n   * The request may be rejected by the server if these ranges overlap (if the requested resource was less than 1000 bytes long, for instance).\n   *\n   * ```http\n   * Range: bytes=0-499, -500\n   * ```\n   *\n   * ### Checking if a server supports range requests\n   *\n   * The following curl command makes a [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) request for an image:\n   *\n   * ```bash\n   * curl -v --http1.1 -I https://i.imgur.com/z4d4kWk.jpg\n   * # or using the OPTIONS method:\n   * # curl -v --http1.1 -X OPTIONS https://i.imgur.com/z4d4kWk.jpg\n   * ```\n   *\n   * This results in the following HTTP request:\n   *\n   * ```http\n   * HEAD /z4d4kWk.jpg HTTP/1.1\n   * Host: i.imgur.com\n   * User-Agent: curl/8.7.1\n   * Accept: * /*\n   * ```\n   *\n   * The server responds with a `200` response, and the `Accept-Ranges: bytes` header is present (some headers are omitted for brevity):\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Connection: keep-alive\n   * Content-Length: 146515\n   * Content-Type: image/jpeg\n   * …\n   * Accept-Ranges: bytes\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [If-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Range) conditional request header\n   * - [Content-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range) response header\n   * - [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type)\n   * - [Accept-Ranges](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Ranges)\n   * - [206 Partial Content](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206)\n   * - [416 Range Not Satisfiable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416)\n   * - [HTTP range requests](/en-US/docs/Web/HTTP/Guides/Range_requests) guide\n   * - [CORS-safelisted request header](/en-US/docs/Glossary/CORS-safelisted_request_header)\n   */\n  'Range' = 'Range',\n\n  /**\n   * The HTTP **`Referer`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) contains the absolute or partial address from which a resource has been requested.\n   * The `Referer` header allows a server to identify referring pages that people are visiting from or where requested resources are being used.\n   * This data can be used for analytics, logging, optimized caching, and more.\n   *\n   * When you click a link, the `Referer` contains the address of the page that includes the link.\n   * When you make resource requests to another domain, the `Referer` contains the address of the page that uses the requested resource.\n   *\n   * The `Referer` header can contain an _origin_, _path_, and _querystring_, and may not contain [URL fragments](/en-US/docs/Web/URI/Reference/Fragment) (i.e., `#section`) or `username:password` information.\n   * The request's _referrer policy_ defines the data that can be included. See [Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy) for more [information](/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy#directives) and [examples](/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy#examples).\n   *\n   * The `Referer` should also be sent in requests following a [Refresh](https://developer.mozilla.org/en-US/docs/httpheader/Refresh) response (or equivalent [`\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Referer: <url>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<url>`\n   *   - : An absolute or partial address of the web page that makes the request.\n   *     URL fragments (i.e., `#section`) and user info (i.e., `username:password` in `https://username:password@example.com/foo/bar/`) are not included.\n   *     Origin, path, and query string may be included, depending on the [referrer policy](/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy#directives).\n   *\n   * ## Examples\n   *\n   * ```http\n   * Referer: https://developer.mozilla.org/en-US/docs/Web/JavaScript\n   * Referer: https://example.com/page?q=123\n   * Referer: https://example.com/\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy)\n   * - [Same-origin policy](/en-US/docs/Web/Security/Same-origin_policy)\n   * - [Fetch](/en-US/docs/Web/API/Fetch_API): [Request.referrerPolicy](https://developer.mozilla.org/en-US/docs/domxref/Request.referrerPolicy)\n   * - [Tighter Control Over Your Referrers – Mozilla Security Blog](https://blog.mozilla.org/security/2015/01/21/meta-referrer/)\n   * - [HTTP referer on Wikipedia](https://en.wikipedia.org/wiki/HTTP_referer)\n   */\n  'Referer' = 'Referer',\n\n  /**\n   * The HTTP **`Referrer-Policy`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) controls how much [referrer information](/en-US/docs/Web/Security/Referer_header:_privacy_and_security_concerns) (sent with the [Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer) header) should be included with requests.\n   * Aside from the HTTP header, you can [set this policy in HTML](#integration_with_html).\n   *\n   *\n   * ```\n   *\n   * > [!WARNING]\n   * > As seen above, the `noreferrer` link relation is written without a dash. When you specify the referrer policy for the entire document with a [meta](https://developer.mozilla.org/en-US/docs/HTMLElement/meta) element, it should be written _with_ a dash: `<meta name=\"referrer\" content=\"no-referrer\">`.\n   *\n   * ## Integration with CSS\n   *\n   * CSS can fetch resources referenced from stylesheets. These resources follow a referrer policy as well:\n   *\n   * - External CSS stylesheets use the default policy (`strict-origin-when-cross-origin`), unless it's overwritten by a `Referrer-Policy` HTTP header on the CSS stylesheet's response.\n   * - For [style](https://developer.mozilla.org/en-US/docs/HTMLElement/style) elements or [`style` attributes](/en-US/docs/Web/API/HTMLElement/style), the owner document's referrer policy is used.\n   *\n   * ## Examples\n   *\n   * ### `no-referrer`\n   *\n   * | From document              | Navigation to | Referrer used   |\n   * | -------------------------- | ------------- | --------------- |\n   * | `https://example.com/page` | _anywhere_    | _(no referrer)_ |\n   *\n   * ### `no-referrer-when-downgrade`\n   *\n   * | From document               | Navigation to                   | Referrer used              |\n   * | --------------------------- | ------------------------------- | -------------------------- |\n   * | `https://example.com/page`  | `https://example.com/otherpage` | `https://example.com/page` |\n   * | `https://example.com/page`  | `https://mozilla.org`           | `https://example.com/page` |\n   * | `https://example.com/page`  | **http**://example.com          | _(no referrer)_            |\n   * | **http**://example.com/page | _anywhere_                      | `http://example.com/page`  |\n   *\n   * ### `origin`\n   *\n   * | From document              | Navigation to | Referrer used          |\n   * | -------------------------- | ------------- | ---------------------- |\n   * | `https://example.com/page` | _anywhere_    | `https://example.com/` |\n   *\n   * ### `origin-when-cross-origin`\n   *\n   * | From document              | Navigation to                   | Referrer used              |\n   * | -------------------------- | ------------------------------- | -------------------------- |\n   * | `https://example.com/page` | `https://example.com/otherpage` | `https://example.com/page` |\n   * | `https://example.com/page` | `https://mozilla.org`           | `https://example.com/`     |\n   * | `https://example.com/page` | **http**://example.com/page     | `https://example.com/`     |\n   *\n   * ### `same-origin`\n   *\n   * | From document              | Navigation to                   | Referrer used              |\n   * | -------------------------- | ------------------------------- | -------------------------- |\n   * | `https://example.com/page` | `https://example.com/otherpage` | `https://example.com/page` |\n   * | `https://example.com/page` | `https://mozilla.org`           | _(no referrer)_            |\n   *\n   * ### `strict-origin`\n   *\n   * | From document               | Navigation to          | Referrer used          |\n   * | --------------------------- | ---------------------- | ---------------------- |\n   * | `https://example.com/page`  | `https://mozilla.org`  | `https://example.com/` |\n   * | `https://example.com/page`  | **http**://example.com | _(no referrer)_        |\n   * | **http**://example.com/page | _anywhere_             | `http://example.com/`  |\n   *\n   * ### `strict-origin-when-cross-origin`\n   *\n   * | From document              | Navigation to                   | Referrer used              |\n   * | -------------------------- | ------------------------------- | -------------------------- |\n   * | `https://example.com/page` | `https://example.com/otherpage` | `https://example.com/page` |\n   * | `https://example.com/page` | `https://mozilla.org`           | `https://example.com/`     |\n   * | `https://example.com/page` | **http**://example.com          | _(no referrer)_            |\n   *\n   * ### `unsafe-url`\n   *\n   * | From document                    | Navigation to | Referrer used                    |\n   * | -------------------------------- | ------------- | -------------------------------- |\n   * | `https://example.com/page?q=123` | _anywhere_    | `https://example.com/page?q=123` |\n   *\n   * ### Specify a fallback policy\n   *\n   * If you want to specify a fallback policy in case the desired policy hasn't got wide enough browser support, use a comma-separated list with the desired policy specified last:\n   *\n   * ```http\n   * Referrer-Policy: no-referrer, strict-origin-when-cross-origin\n   * ```\n   *\n   * In the above scenario, `no-referrer` is used only if the browser does not support the `strict-origin-when-cross-origin` policy.\n   *\n   * > [!NOTE]\n   * > Specifying multiple values is only supported in the `Referrer-Policy` HTTP header, and not in the `referrerpolicy` attribute.\n   *\n   * ## Browser-specific preferences/settings\n   *\n   * ### Firefox preferences\n   *\n   * You can configure the _default_ referrer policy in Firefox preferences. The preference names are version specific:\n   *\n   * - Firefox version 59 and later: `network.http.referer.defaultPolicy` (and `network.http.referer.defaultPolicy.pbmode` for private networks)\n   * - Firefox versions 53 to 58: `network.http.referer.userControlPolicy`\n   *\n   * All of these settings take the same set of values: `0 = no-referrer`, `1 = same-origin`, `2 = strict-origin-when-cross-origin`, `3 = no-referrer-when-downgrade`.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Web security > Referer header: privacy and security concerns](/en-US/docs/Web/Security/Referer_header:_privacy_and_security_concerns)\n   * - When using [Fetch](/en-US/docs/Web/API/Fetch_API): [Request.referrerPolicy](https://developer.mozilla.org/en-US/docs/domxref/Request.referrerPolicy)\n   * - [Same-origin policy](/en-US/docs/Web/Security/Same-origin_policy)\n   * - [HTTP referer on Wikipedia](https://en.wikipedia.org/wiki/HTTP_referer)\n   * - [Tighter Control Over Your Referrers – Mozilla Security Blog](https://blog.mozilla.org/security/2015/01/21/meta-referrer/)\n   */\n  'Referrer-Policy' = 'Referrer-Policy',\n\n  /**\n   * The HTTP **`Refresh`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) directs a web browser to either refresh or redirect the page when a specified amount of time has passed after the page was fully loaded.\n   * It is exactly equivalent to using [`\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Refresh: <time>\n   * Refresh: <time>, url=<url>\n   * Refresh: <time>; url=<url>\n   * ```\n   *\n   * - `<time>`\n   *   - : A non-negative number of seconds after which to refresh the page. Fractional parts are recognized but ignored; you should only specify integers.\n   * - `<url>`\n   *   - : If present, the browser will redirect to the specified URL instead of refreshing with the current URL. This URL can be quoted or unquoted. The `url=` prefix is case-insensitive and optional.\n   *\n   * ## Examples\n   *\n   * ### Refreshing a page after a specific time\n   *\n   * This header will cause the browser to refresh the page 5 seconds after it is fully loaded (that is, after the [load](https://developer.mozilla.org/en-US/docs/domxref/Window/load_event) event):\n   *\n   * ```http\n   * Refresh: 5\n   * ```\n   *\n   * ### Redirecting after a specific time\n   *\n   * This header will cause the browser to redirect to the a URL 5 seconds after the page is fully loaded:\n   *\n   * ```http\n   * Refresh: 5; url=https://example.com/\n   * ```\n   *\n   * > [!NOTE]\n   * > See the [`http-equiv=\"refresh\"`](/en-US/docs/Web/HTML/Reference/Elements/meta/http-equiv#refresh) attribute in the HTML reference for important information about accessibility implications of automatic redirects.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [meta](https://developer.mozilla.org/en-US/docs/htmlelement/meta)\n   * - [Redirections in HTTP](/en-US/docs/Web/HTTP/Guides/Redirections)\n   * - [The Refresh header is still with us](https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0197.html) HTTP Working Group message (2019)\n   */\n  'Refresh' = 'Refresh',\n\n  /**\n   * > [!WARNING]\n   * > This header has been replaced by the [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Reporting-Endpoints) HTTP response header.\n   * > It is a deprecated part of an earlier iteration of the [Reporting API](/en-US/docs/Web/API/Reporting_API) specification.\n   *\n   * The HTTP **`Report-To`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) allows website administrators to define named groups of endpoints that can be used as the destination for warning and error reports, such as CSP violation reports, [Cross-Origin-Opener-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) reports, deprecation reports, or other generic violations.\n   *\n   * `Report-To` is often used in conjunction with other headers that select a group of endpoints to use for a particular kind of report.\n   * For example, the [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) header [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive can be used to select the group used for reporting CSP violations.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Report-To: <json-field-value>\n   * ```\n   *\n   * - `<json-field-value>`\n   *   - : One or more endpoint-group definitions, defined as a JSON array that omits the surrounding `[` and `]` markers.\n   *     Each object in the array has the following members:\n   *     - `group`\n   *       - : A name for the group of endpoints.\n   *     - `max_age`\n   *       - : The time in seconds that the browser should cache the reporting configuration.\n   *     - `endpoints`\n   *       - : An array of one or more URLs where the reports in the group should be sent.\n   *\n   * ## Examples\n   *\n   * ### Setting a CSP violation report endpoint\n   *\n   * This example shows how a server might use `Report-To` to define a group of endpoints, and then set the group as the location where CSP violation reports are sent.\n   *\n   * First a server might send a response with the `Report-To` HTTP response header as shown below.\n   * This specifies a group of `url` endpoints identified by the group name `csp-endpoints`.\n   *\n   * ```http\n   * Report-To: { \"group\": \"csp-endpoints\",\n   *               \"max_age\": 10886400,\n   *               \"endpoints\": [\n   *                 { \"url\": \"https://example.com/reports\" },\n   *                 { \"url\": \"https://backup.com/reports\" }\n   *               ] }\n   * ```\n   *\n   * The server can then specify that it wants this group to be the target for sending CSP violation reports by setting the group name as the value of the [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive:\n   *\n   * ```http\n   * Content-Security-Policy: script-src https://example.com/; report-to csp-endpoints\n   * ```\n   *\n   * Given the headers above, any `script-src` CSP violations would result in violation reports being sent to both of the `url` values listed in `Report-To`.\n   *\n   * ### Specifying multiple reporting groups\n   *\n   * The example below demonstrates a `Report-To` header that specifies multiple endpoint groups.\n   * Note that each group has a unique name, and that the groups are not bounded by the array markers.\n   *\n   * ```http\n   * Report-To: { \"group\": \"csp-endpoint-1\",\n   *               \"max_age\": 10886400,\n   *               \"endpoints\": [\n   *                 { \"url\": \"https://example.com/csp-reports\" }\n   *               ] },\n   *             { \"group\": \"hpkp-endpoint\",\n   *               \"max_age\": 10886400,\n   *               \"endpoints\": [\n   *                 { \"url\": \"https://example.com/hpkp-reports\" }\n   *               ] }\n   * ```\n   *\n   * We can select an endpoint group as the target for violation reports by name, in the same way as we did in the previous example:\n   *\n   * ```http\n   * Content-Security-Policy: script-src https://example.com/; report-to csp-endpoint-1\n   * ```\n   *\n   * ## Specifications\n   *\n   * This header is no longer part of any specification.\n   * It was previously part of the [Reporting API](/en-US/docs/Web/API/Reporting_API). <!-- https://github.com/w3c/reporting/pull/197 -->\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Reporting API](/en-US/docs/Web/API/Reporting_API) and [Reporting-Endpoints](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Reporting-Endpoints) header\n   * - [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) CSP directive\n   * - [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy), [Content-Security-Policy-Report-Only](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only) headers\n   * - [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/Guides/CSP#violation_reporting) guide\n   */\n  'Report-To' = 'Report-To',\n\n  /**\n   * The HTTP **`Reporting-Endpoints`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) allows website administrators to specify one or more endpoints that can be sent reports generated by the [Reporting API](/en-US/docs/Web/API/Reporting_API).\n   *\n   * The endpoints can be used, for example, as targets for sending CSP violation reports, [Cross-Origin-Opener-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) reports, or other generic violations.\n   *\n   * When used for reporting [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/Guides/CSP#violation_reporting) errors, the header is used in combination with the [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) header [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive.\n   * For more details on setting up CSP reporting, see the [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/Guides/CSP#violation_reporting) documentation.\n   *\n   * > [!NOTE]\n   * > This header replaces [Report-To](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Report-To)  for declaring endpoints, and should be used in preference.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Reporting-Endpoints: <endpoint>\n   * Reporting-Endpoints: <endpoint>, …, <endpointN>\n   * ```\n   *\n   * - `<endpoint>`\n   *   - : A reporting endpoint in the format `<endpoint-name>=\"<URL>\"`.\n   *     The endpoints must have valid URIs in quoted strings (e.g., `my-endpoint=\"https://example.com/reports\"`) and non-secure endpoints are ignored.\n   *     A comma-separated list of endpoints may be provided.\n   *\n   * ## Examples\n   *\n   * ### Setting a CSP violation report endpoint\n   *\n   * The following example shows how the `Reporting-Endpoints` response header is used in conjunction with the [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) header to indicate where CSP violation reports are sent:\n   *\n   * ```http\n   * Reporting-Endpoints: csp-endpoint=\"https://example.com/csp-reports\"\n   * Content-Security-Policy: default-src 'self'; report-to csp-endpoint\n   * ```\n   *\n   * ### Specifying multiple reporting endpoints\n   *\n   * It's possible to specify multiple endpoints that can be used for different types of violation reports.\n   *\n   * ```http\n   * Reporting-Endpoints: csp-endpoint=\"https://example.com/csp-reports\",\n   *                      permissions-endpoint=\"https://example.com/permissions-policy-reports\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Reporting API](/en-US/docs/Web/API/Reporting_API)\n   * - [Content Security Policy (CSP)](/en-US/docs/Web/HTTP/Guides/CSP#violation_reporting) guide\n   * - [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) header\n   * - [report-to](https://developer.mozilla.org/en-US/docs/CSP/report-to) directive\n   */\n  'Reporting-Endpoints' = 'Reporting-Endpoints',\n\n  /**\n   * The HTTP **`Repr-Digest`** [request](https://developer.mozilla.org/en-US/docs/Glossary/Request_header) and [response header](https://developer.mozilla.org/en-US/docs/Glossary/Response_header) provides a [digest](https://developer.mozilla.org/en-US/docs/Glossary/hash_function) of the selected representation of the target resource.\n   * It can be used validate the integrity of the whole selected representation once it has been received and reconstructed.\n   *\n   * The _selected representation_ is the specific format of a resource chosen through [content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation).\n   * Details about the representation can be determined from [representation headers](https://developer.mozilla.org/en-US/docs/Glossary/Representation_header), such as [Content-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Language), [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type), and [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding).\n   *\n   * The representation digest applies to the whole representation rather than the encoding or chunking of the messages that are used to send it.\n   * A [Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Digest) applies to the content of a specific message, and will have different values based on the [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) and [Content-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range) of each message.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Repr-Digest: <digest-algorithm>=<digest-value>\n   *\n   * // Multiple digest algorithms\n   * Repr-Digest: <digest-algorithm>=<digest-value>,…,<digest-algorithmN>=<digest-valueN>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<digest-algorithm>`\n   *   - : The algorithm used to create a digest of the representation.\n   *     Only two registered digest algorithms are considered secure: `sha-512` and `sha-256`.\n   *     The insecure (legacy) registered digest algorithms are: `md5`, `sha` (SHA-1), `unixsum`, `unixcksum`, `adler` (ADLER32) and `crc32c`.\n   * - `<digest-value>`\n   *   - : The digest in bytes of the representation using the `<digest-algorithm>`.\n   *     The choice of digest algorithm also determines the encoding to use: `sha-512` and `sha-256` use [base64](https://developer.mozilla.org/en-US/docs/Glossary/base64) encoding, while some legacy digest algorithms such as `unixsum` use a decimal integer.\n   *     In contrast to earlier drafts of the specification, the standard-base64-encoded digest bytes are wrapped in colons (`:`, ASCII 0x3A) as part of the [dictionary syntax](https://www.rfc-editor.org/rfc/rfc8941#name-byte-sequences).\n   *\n   * Usage of insecure digest algorithms is discouraged as collisions can realistically be forced, rendering the digest's usefulness weak.\n   * Unless working with legacy systems (which is unlikely since most will expect the deprecated `Digest` header and not understand this specification), consider omitting a `Repr-Digest` instead of including one with an insecure digest algorithm.\n   *\n   * ## Description\n   *\n   * A `Digest` header was defined in previous specifications, but it proved problematic as the scope of what the digest applied to was not clear.\n   * Specifically, it was difficult to distinguish whether a digest applied to the entire resource representation or to the specific content of a HTTP message.\n   * As such, two separate headers were specified (`Content-Digest` and `Repr-Digest`) to convey HTTP message content digests and resource representation digests, respectively.\n   *\n   * ## Examples\n   *\n   * ### User-agent sending a Repr-Digest in requests\n   *\n   * In the following example, a user-agent sends a digest of the message content using SHA-512.\n   * It sends both a `Content-Digest` and a `Repr-Digest`, which differ from each other because of the `Content-Encoding`:\n   *\n   * ```http\n   * POST /bank_transfer HTTP/1.1\n   * Host: example.com\n   * Content-Encoding: zstd\n   * Content-Digest: sha-512=:ABC…=:\n   * Repr-Digest: sha-512=:DEF…=:\n   *\n   * {\n   *  \"recipient\": \"Alex\",\n   *  \"amount\": 900000000\n   * }\n   * ```\n   *\n   * The server may calculate a digest of the content it has received and compare the result with the `Content-Digest` or `Repr-Digest` headers to validate the message integrity.\n   * In requests like the example above, the `Repr-Digest` is more useful to the server as this is calculated over the decoded representation and would be more consistent in different scenarios.\n   *\n   * ### HTTP response where `Repr-Digest` and `Content-Digest` coincide\n   *\n   * An HTTP server may send the whole representation unencoded in a single message.\n   * In this case, `Repr-Digest` and `Content-Digest` have equal values for the same digest algorithms:\n   *\n   * ```http\n   * …\n   * Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:\n   * Content-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:\n   * …\n   * Content-Type: text/yaml\n   * Content-Encoding: br\n   * Content-Length: 38054\n   * Content-Range: 0-38053/38054\n   * …\n   *\n   * [message body]\n   * ```\n   *\n   * ### HTTP responses where `Repr-Digest` and `Content-Digest` diverge\n   *\n   * A server may compress the content for sending.\n   * In this case [Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Digest) will depend on the [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding), and will therefore have a different value to the `Repr-Digest` header in a response:\n   *\n   * ```http\n   * …\n   * Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==:\n   * Content-Digest: sha-256=:293wcr5IoFAsDCzdoDXR1Qppgf2yxOPO1bvQ3nZQtuI=:, unixsum=54809\n   * …\n   * Content-Type: text/html; charset=utf-8\n   * Content-Encoding: br\n   * …\n   *\n   * [message body]\n   * ```\n   *\n   * In another response, the server uses a different compression method, resulting in a new `Content-Digest`, but the same `Repr-Digest` digests:\n   *\n   * ```http\n   * …\n   * Repr-Digest: sha-256=:AEGPTgUMw5e96wxZuDtpfm23RBU3nFwtgY5fw4NYORo=:, sha-512=:U59TCCaZPA9Qio3CzHJVAgDnIAut53t5Sgkj2Gv4BvDd0b+OX9QpIdgWkzdXLmBsmvBrf3t5PBt+UrVK6k5dkw==:\n   * Content-Digest: sha-256=:rv9Jivc4TmcacLUshzN3OdX7Hz+ORnQRaiTaIKZQ0zk=:\n   * …\n   * Content-Type: text/html; charset=utf-8\n   * Content-Encoding: zstd\n   * …\n   *\n   * [message body]\n   * ```\n   *\n   * ### Successful HTTP request-response employing `Want-Repr-Digest`, `Repr-Digest`, and `Content-Digest`\n   *\n   * The following [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT) request includes a `Want-Repr-Digest` header, indicating that the server should include a `Repr-Digest` header with a `sha-256` digest if the operation is successful:\n   *\n   * ```http\n   * PUT /api/transact HTTP/1.1\n   * Want-Repr-Digest: sha-256=8\n   * Content-Type: text/json\n   * …\n   *\n   * [message body]\n   * ```\n   *\n   * The server responds with a successful [201 Created](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201) response, including `Repr-Digest` and `Content-Digest` headers with sha-256 digests of the representation and content, respectively:\n   *\n   * ```http\n   * HTTP/1.1 201 Created\n   * Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:\n   * Content-Encoding: br\n   * Content-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:\n   * …\n   *\n   * [message body]\n   * ```\n   *\n   * ### Unsuccessful HTTP request-response employing `Repr-Digest`\n   *\n   * In the following message, a user-agent requests a resource with a specific sha-256 digest:\n   *\n   * ```http\n   * GET /api/last-transaction HTTP/1.1\n   * Accept: text/json\n   * Repr-Digest: sha-256=:2IBI7hQn83oTCgB3Z/6apOl91WGoctRfRj/F9gkvVo8=:\n   * …\n   * ```\n   *\n   * A [406 Not Acceptable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406) is returned by the server to indicate the operation failed given a specific digest for the resource.\n   * A `Repr-Digest` header is included with the SHA-256 digest value that would result in a successful response if the user-agent repeated the request with that value:\n   *\n   * ```http\n   * HTTP/1.1 406 Not Acceptable\n   * Repr-Digest: sha-256=:W8oN3H3CmE/CBpV6ZPNozV2AIDzzQpWL7CCOXyDyDzI=:\n   * …\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * This header has no specification-defined browser integration (\"browser compatibility\" does not apply).\n   * Developers can set and get HTTP headers using `fetch()` in order to provide application-specific implementation behavior.\n   *\n   * ## See also\n   *\n   * - [Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Digest), [Want-Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Content-Digest), [Want-Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Repr-Digest)\n   * - [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag)\n   * - [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding)\n   * - [Digital Signatures for APIs](https://developer.ebay.com/develop/guides/digital-signatures-for-apis) SDK guide uses `Content-Digest`s for digital signatures in HTTP calls (developer.ebay.com)\n   */\n  'Repr-Digest' = 'Repr-Digest',\n\n  /**\n   * The HTTP **`Retry-After`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates how long the user agent should wait before making a follow-up request.\n   * There are three main cases this header is used:\n   *\n   * - In a [503 Service Unavailable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503) response, this indicates how long the service is expected to be unavailable.\n   * - In a [429 Too Many Requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429) response, this indicates how long to wait before making a new request.\n   * - In a redirect response, such as [301 Moved Permanently](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301), this indicates the minimum time that the user agent is asked to wait before issuing the redirected request.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Retry-After: <http-date>\n   * Retry-After: <delay-seconds>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<http-date>`\n   *   - : A date after which to retry. See the [Date](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date) header for more details\n   *     on the HTTP date format.\n   * - `<delay-seconds>`\n   *   - : A non-negative decimal integer indicating the seconds to delay after the response is\n   *     received.\n   *\n   * ## Examples\n   *\n   * ### Dealing with scheduled downtime\n   *\n   * Support for the `Retry-After` header on both clients and servers is still\n   * inconsistent. However, some crawlers and spiders, like the Googlebot, honor the\n   * `Retry-After` header. It is useful to send it along with a `503` response, so that search engines will keep\n   * indexing your site when the downtime is over.\n   *\n   * ```http\n   * Retry-After: Wed, 21 Oct 2015 07:28:00 GMT\n   * Retry-After: 120\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [503 Service Unavailable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503)\n   * - [301 Moved Permanently](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301)\n   * - [How to deal with planned site downtime](https://developers.google.com/search/blog/2011/01/how-to-deal-with-planned-site-downtime) on developers.google.com (2011)\n   */\n  'Retry-After' = 'Retry-After',\n\n  /**\n   * The HTTP **`RTT`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [network client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#network_client_hints) which provides the approximate round trip time on the application layer, in milliseconds.\n   * The RTT hint includes server processing time, unlike transport layer RTT.\n   *\n   * The RTT value is rounded to the nearest 25 milliseconds to prevent [fingerprinting](/en-US/docs/Glossary/Fingerprinting), although there are many other mechanisms an attacker might use to obtain similar round-trip information.\n   *\n   * The hint allows a server to choose what information is sent based on the network responsiveness/latency. For example, it might choose to send fewer resources.\n   *\n   * > [!NOTE]\n   * > The [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header is used in responses to indicate that a different resource is sent for every different value of the header (see [HTTP Caching Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary)). Even if `RTT` is used to configure what resources are sent consider omitting it in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header — it is likely to change often, which effectively makes the resource uncacheable.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * RTT: <number>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<number>`\n   *   - : The approximate round trip time in milliseconds, rounded to the nearest 25 milliseconds.\n   *\n   * ## Examples\n   *\n   * ### Using RTT client hints\n   *\n   * A server first needs to opt in to receive the `RTT` header by sending the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header containing `RTT`.\n   *\n   * ```http\n   * Accept-CH: RTT\n   * ```\n   *\n   * Then on subsequent requests the client might send an `RTT` header back:\n   *\n   * ```http\n   * RTT: 125\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Downlink](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Downlink), [ECT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ECT), [Save-Data](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data) network client hints\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   * - [NetworkInformation.effectiveType](https://developer.mozilla.org/en-US/docs/domxref/NetworkInformation.effectiveType)\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'RTT' = 'RTT',\n\n  /**\n   * The HTTP **`Save-Data`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [network client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#network_client_hints) which indicates the client's preference for reduced data usage.\n   * This could be for reasons such as high transfer costs, slow connection speeds, etc.\n   *\n   * `Save-Data` is a [low entropy hint](/en-US/docs/Web/HTTP/Guides/Client_hints#low_entropy_hints), and hence may be sent by the client even if not requested by the server using an [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header.\n   * Further, it should be used to reduce data sent to the client irrespective of the values of other client hints that indicate network capability, like [Downlink](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Downlink) and [RTT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/RTT).\n   *\n   * A value of `On` indicates explicit user opt-in into a reduced data usage mode on the client.\n   * When communicated to origins, this allows them to deliver alternative content to reduce the data downloaded such as smaller image and video resources, different markup and styling, disabled polling and automatic updates, and so on.\n   *\n   * > [!NOTE]\n   * > Disabling HTTP/2 Server Push ([Server Push\", \"8.2](https://developer.mozilla.org/en-US/docs/RFC/7540)) may reduce data downloads.\n   * > Note that this feature is no longer supported by default in most major browser engines.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Save-Data: <sd-token>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<sd-token>`\n   *   - : A value indicating whether the client wants to opt in to reduced data usage mode.\n   *     `on` indicates yes, while `off` (the default) indicates no.\n   *\n   * ## Examples\n   *\n   * ### Using `Save-Data: on`\n   *\n   * The following message requests a resource with `Save-Data` header indicating the client is opting in to reduced data mode:\n   *\n   * ```http\n   * GET /image.jpg HTTP/1.1\n   * Host: example.com\n   * Save-Data: on\n   * ```\n   *\n   * The server responds with a `200` response, and the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header indicates that `Save-Data` may have been used to create the response, and caches should be aware of this header to differentiate responses:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Length: 102832\n   * Vary: Accept-Encoding, Save-Data\n   * Cache-Control: public, max-age=31536000\n   * Content-Type: image/jpeg\n   *\n   * […]\n   * ```\n   *\n   * ### Omitting `Save-Data`\n   *\n   * In this case, the client requests the same resource without the `Save-Data` header:\n   *\n   * ```http\n   * GET /image.jpg HTTP/1.1\n   * Host: example.com\n   * ```\n   *\n   * The server's response provides the full version of the content.\n   * The [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header ensures that responses should be separately cached based on the value of the `Save-Data` header.\n   * This can ensure that the user is not served a lower-quality image from the cache when the `Save-Data` header is no longer present (e.g., after having switched from cellular to Wi-Fi).\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Length: 481770\n   * Vary: Accept-Encoding, Save-Data\n   * Cache-Control: public, max-age=31536000\n   * Content-Type: image/jpeg\n   *\n   * […]\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - CSS `@media` feature [`prefers-reduced-data`](/en-US/docs/Web/CSS/@media/prefers-reduced-data)\n   * - [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header which indicates that the content served varies depending on the value of `Save-Data` (see [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary))\n   * - [NetworkInformation.saveData](https://developer.mozilla.org/en-US/docs/domxref/NetworkInformation.saveData)\n   * - [Help Your Users `Save-Data`](https://css-tricks.com/help-users-save-data/) on css-tricks.com\n   * - [Delivering Fast and Light Applications with Save-Data - web.dev](https://web.dev/articles/optimizing-content-efficiency-save-data) on web.dev\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Save-Data' = 'Save-Data',\n\n  /**\n   * > [!WARNING]\n   * > This feature is currently opposed by two browser vendors. See the [Standards positions](/en-US/docs/Web/API/Topics_API#standards_positions) section for details of opposition.\n   *\n   * > [!NOTE]\n   * > An [Enrollment process](/en-US/docs/Web/Privacy/Guides/Privacy_sandbox/Enrollment) is required to use this feature in your applications.\n   *\n   * The HTTP **`Sec-Browsing-Topics`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) sends the selected topics for the current user along with the associated request, which are used by an ad tech platform to choose a personalized ad to display.\n   *\n   * If the calling site does not have the Topics API included in a successful [privacy sandbox enrollment process](/en-US/docs/Web/Privacy/Guides/Privacy_sandbox/Enrollment), attempting to create or modify `Sec-Browsing-Topics` fails silently, and any existing `Sec-Browsing-Topics` header is deleted.\n   *\n   * See [Using the Topics API](/en-US/docs/Web/API/Topics_API/Using) for more details.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-Browsing-Topics: <array-of-observed-topics>\n   * ```\n   *\n   * ## Directives\n   *\n   * A JSON object representing an array of up to three objects representing the current user's selected topics for the last three epochs. Each object contains the following properties:\n   *\n   * - `configVersion`\n   *   - : A string identifying the algorithm (other than the model part) used to calculate the topic.\n   * - `modelVersion`\n   *   - : A string representing the model used to classify a string (such as a web page's hostname) into topic IDs.\n   * - `taxonomyVersion`\n   *   - : A string representing the taxonomy version used.\n   * - `topic`\n   *   - : A number representing the ID of the topic, which can be used by the browser to retrieve the topic from the taxonomy (see an example [taxonomy of interests](https://github.com/patcg-individual-drafts/topics/blob/main/taxonomy_v1.md)).\n   * - `version`\n   *   - : The `configVersion`, `modelVersion`, and `taxonomyVersion`, concatenated with colons (`:`) between each.\n   *\n   * ## Examples\n   *\n   * The exact property values may vary by browser implementation. An example header from Chrome might look as follows:\n   *\n   * ```http\n   * Sec-Browsing-Topics: [{configVersion: \"chrome.1\", modelVersion: \"1\", taxonomyVersion: \"1\", topic: 43, version: \"chrome.1:1:1\"}]\n   * ```\n   *\n   * ## Specifications\n   *\n   * This feature is not part of an official standard, although it is specified in the [Topics API Unofficial Proposal Draft](https://patcg-individual-drafts.github.io/topics/).\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Topics API](/en-US/docs/Web/API/Topics_API)\n   */\n  'Sec-Browsing-Topics' = 'Sec-Browsing-Topics',\n\n  /**\n   * The HTTP **`Sec-CH-Prefers-Color-Scheme`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [media feature client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_preference_media_features_client_hints) which provides the user's preference for light or dark color themes.\n   * A user indicates their preference through an operating system setting (for example, light or dark mode) or a user agent setting.\n   *\n   * If a server signals to a client via the [Accept-CH](https://developer.mozilla.org/en-US/docs/httpheader/Accept-CH) header that it accepts `Sec-CH-Prefers-Color-Scheme`, the client can then respond with this header to indicate the user's preference for a specific color scheme. The server can send the client appropriately adapted content including images or CSS to display a light or dark mode for subsequent rendered content.\n   *\n   * This header is modeled on the [prefers-color-scheme](https://developer.mozilla.org/en-US/docs/cssxref/@media/prefers-color-scheme) media query.\n   *\n   *\n   *\n   * ## Usage notes\n   *\n   * The **`Sec-CH-Prefers-Color-Scheme`** header allows sites to obtain user color scheme preference at request time; they could then choose to provide the relevant CSS for the user's preference inline, for performance reasons. If the server inlines the CSS, it might want to include a [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) response header specifying `Sec-CH-Prefers-Color-Scheme`, to indicate that the response is tailored for a particular color scheme.\n   *\n   * If performance is not a critical consideration in this context, you could instead handle the user's color scheme preference using the [`prefers-color-scheme`](/en-US/docs/Web/CSS/@media/prefers-color-scheme) media query, and/or the [Window.matchMedia()](https://developer.mozilla.org/en-US/docs/domxref/Window.matchMedia()) API.\n   *\n   * `Sec-CH-Prefers-Color-Scheme` is a high entropy hint so the site needs to opt into receiving it by sending an appropriate [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header. A user agent may intentionally omit the `Sec-CH-Prefers-Color-Scheme` header to preserve user privacy since the user's preference could, in theory, be used for fingerprinting.\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-Prefers-Color-Scheme: <preference>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<preference>`\n   *   - : A string indicating the user agent's preference for dark or light content: `\"light\"` or `\"dark\"`.\n   *     The value may originate from a corresponding setting in the underlying operating system.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-Prefers-Color-Scheme\n   *\n   * The client makes an initial request to the server:\n   *\n   * ```http\n   * GET / HTTP/1.1\n   * Host: example.com\n   * ```\n   *\n   * The server responds, telling the client via [Accept-CH](https://developer.mozilla.org/en-US/docs/httpheader/Accept-CH) that it accepts `Sec-CH-Prefers-Color-Scheme`. In this example [Critical-CH](https://developer.mozilla.org/en-US/docs/httpheader/Critical-CH) is also used, indicating that `Sec-CH-Prefers-Color-Scheme` is considered a [critical client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#critical_client_hints).\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Type: text/html\n   * Accept-CH: Sec-CH-Prefers-Color-Scheme\n   * Vary: Sec-CH-Prefers-Color-Scheme\n   * Critical-CH: Sec-CH-Prefers-Color-Scheme\n   * ```\n   *\n   * > [!NOTE]\n   * > We've also specified `Sec-CH-Prefers-Color-Scheme` in the [Vary](https://developer.mozilla.org/en-US/docs/httpheader/Vary) header to indicate that responses should be separately cached based on the value of this header (even if the URL stays the same).\n   * > Each header listed in the `Critical-CH` header should also be present in the `Accept-CH` and `Vary` headers.\n   *\n   * The client automatically retries the request (due to `Critical-CH` being specified above), telling the server via `Sec-CH-Prefers-Color-Scheme` that it has a user preference for dark content:\n   *\n   * ```http\n   * GET / HTTP/1.1\n   * Host: example.com\n   * Sec-CH-Prefers-Color-Scheme: \"dark\"\n   * ```\n   *\n   * The client will include the header in subsequent requests in the current session, unless the `Accept-CH` changes in responses to indicate that it is no longer supported by the server.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching varying responses](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [`prefers-color-scheme` CSS Media Query](/en-US/docs/Web/CSS/@media/prefers-color-scheme)\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-Prefers-Color-Scheme' = 'Sec-CH-Prefers-Color-Scheme',\n\n  /**\n   * The HTTP **`Sec-CH-Prefers-Reduced-Motion`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_preference_media_features_client_hints) which indicates the user agent's preference for animations to be displayed with reduced motion.\n   *\n   * If a server signals to a client via the [Accept-CH](https://developer.mozilla.org/en-US/docs/httpheader/Accept-CH) header that it accepts `Sec-CH-Prefers-Reduced-Motion`, the client can then respond with this header to indicate the user's preference for reduced motion. The server can send the client appropriately adapted content, for example, JavaScript or CSS, to reduce the motion of any animations presented on subsequent rendered content. This could include reducing the speed or amplitude of movement to reduce discomfort for those with vestibular motion disorders.\n   *\n   * This header is modeled on the [prefers-reduced-motion](https://developer.mozilla.org/en-US/docs/cssxref/@media/prefers-reduced-motion) media query.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-Prefers-Reduced-Motion: <preference>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<preference>`\n   *   - : The user agent's preference for reduced-motion animations. This is often taken from the underlying operating system's setting. The value of this directive can be either `no-preference` or `reduce`.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-Prefers-Reduced-Motion\n   *\n   * The client makes an initial request to the server:\n   *\n   * ```http\n   * GET / HTTP/1.1\n   * Host: example.com\n   * ```\n   *\n   * The server responds, telling the client via [Accept-CH](https://developer.mozilla.org/en-US/docs/httpheader/Accept-CH) that it accepts `Sec-CH-Prefers-Reduced-Motion`. In this example [Critical-CH](https://developer.mozilla.org/en-US/docs/httpheader/Critical-CH) is also used, indicating that `Sec-CH-Prefers-Reduced-Motion` is considered a [critical client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#critical_client_hints).\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Type: text/html\n   * Accept-CH: Sec-CH-Prefers-Reduced-Motion\n   * Vary: Sec-CH-Prefers-Reduced-Motion\n   * Critical-CH: Sec-CH-Prefers-Reduced-Motion\n   * ```\n   *\n   * > [!NOTE]\n   * > We've also specified `Sec-CH-Prefers-Reduced-Motion` in the [Vary](https://developer.mozilla.org/en-US/docs/httpheader/Vary) header to indicate to the browser that the served content will differ based on this header value, even if the URL stays the same, so the browser shouldn't just use an existing cached response and instead should cache this response separately. Each header listed in the `Critical-CH` header should also be present in the `Accept-CH` and `Vary` headers.\n   *\n   * The client automatically retries the request (due to `Critical-CH` being specified above), telling the server via `Sec-CH-Prefers-Reduced-Motion` that it has a user preference for reduced-motion animations:\n   *\n   * ```http\n   * GET / HTTP/1.1\n   * Host: example.com\n   * Sec-CH-Prefers-Reduced-Motion: \"reduce\"\n   * ```\n   *\n   * The client will include the header in subsequent requests in the current session unless the `Accept-CH` changes in responses to indicate that it is no longer supported by the server.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [`prefers-reduced-motion` CSS Media Query](/en-US/docs/Web/CSS/@media/prefers-reduced-motion)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-Prefers-Reduced-Motion' = 'Sec-CH-Prefers-Reduced-Motion',\n\n  /**\n   * The HTTP **`Sec-CH-Prefers-Reduced-Transparency`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_preference_media_features_client_hints) that indicates the user agent's preference for reduced transparency.\n   *\n   * If a server signals to a client via the [Accept-CH](https://developer.mozilla.org/en-US/docs/httpheader/Accept-CH) header that it accepts `Sec-CH-Prefers-Reduced-Transparency`, the client can then respond with this header to indicate the user's preference for reduced transparency. The server can send the client appropriately adapted content — for example, CSS or images — to reduce the transparency of the content.\n   *\n   * This header is modeled on the [prefers-reduced-transparency](https://developer.mozilla.org/en-US/docs/cssxref/@media/prefers-reduced-transparency) media query.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-Prefers-Reduced-Transparency: <preference>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<preference>`\n   *   - : The user agent's preference for reduced transparency. This is often taken from the underlying operating system's setting. The value of this directive can be either `no-preference` or `reduce`.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-Prefers-Reduced-Transparency\n   *\n   * The client makes an initial request to the server:\n   *\n   * ```http\n   * GET / HTTP/1.1\n   * Host: example.com\n   * ```\n   *\n   * The server responds, telling the client via [Accept-CH](https://developer.mozilla.org/en-US/docs/httpheader/Accept-CH) that it accepts `Sec-CH-Prefers-Reduced-Transparency`. In this example [Critical-CH](https://developer.mozilla.org/en-US/docs/httpheader/Critical-CH) is also used, indicating that `Sec-CH-Prefers-Reduced-Transparency` is considered a [critical client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#critical_client_hints).\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Type: text/html\n   * Accept-CH: Sec-CH-Prefers-Reduced-Transparency\n   * Vary: Sec-CH-Prefers-Reduced-Transparency\n   * Critical-CH: Sec-CH-Prefers-Reduced-Transparency\n   * ```\n   *\n   * > [!NOTE]\n   * > We've also specified `Sec-CH-Prefers-Reduced-Transparency` in the [Vary](https://developer.mozilla.org/en-US/docs/httpheader/Vary) header, to indicate to the browser that the served content will differ based on this header value — even if the URL stays the same — so the browser shouldn't just use an existing cached response and instead should cache this response separately. Each header listed in the `Critical-CH` header should also be present in the `Accept-CH` and `Vary` headers.\n   *\n   * The client automatically retries the request (due to `Critical-CH` being specified above), telling the server via `Sec-CH-Prefers-Reduced-Transparency` that it has a user preference for reduced transparency:\n   *\n   * ```http\n   * GET / HTTP/1.1\n   * Host: example.com\n   * Sec-CH-Prefers-Reduced-Transparency: \"reduce\"\n   * ```\n   *\n   * The client will include the header in subsequent requests in the current session unless the `Accept-CH` changes in responses to indicate that it is no longer supported by the server.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-Prefers-Reduced-Transparency' = 'Sec-CH-Prefers-Reduced-Transparency',\n\n  /**\n   * The HTTP **`Sec-CH-UA-Arch`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_agent_client_hints) which contains the user-agent's underlying CPU architecture, such as ARM or x86.\n   *\n   * This might be used by a server, for example, to select and offer the correct binary format of an executable for a user to download.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-UA-Arch: <arch>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<arch>`\n   *   - : A string indicating the underlying platform architecture, such as: `\"x86\"`, `\"ARM\"`, `\"[arm64-v8a, armeabi-v7a, armeabi]\"`.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-UA-Arch\n   *\n   * A server requests the `Sec-CH-UA-Arch` header by including the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) in a response to some request from the client, using the name of the desired header as a token:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Accept-CH: Sec-CH-UA-Arch\n   * ```\n   *\n   * The client may choose to provide the hint, and add the `Sec-CH-UA-Arch` header to subsequent requests.\n   * For example, on a Windows X86 based computer, the client might add the header as shown:\n   *\n   * ```http\n   * GET /my/page HTTP/1.1\n   * Host: example.site\n   *\n   * Sec-CH-UA: \" Not A;Brand\";v=\"99\", \"Chromium\";v=\"96\", \"Google Chrome\";v=\"96\"\n   * Sec-CH-UA-Mobile: ?0\n   * Sec-CH-UA-Platform: \"Windows\"\n   * Sec-CH-UA-Arch: \"x86\"\n   * ```\n   *\n   * Note above that the [low entropy headers](/en-US/docs/Web/HTTP/Guides/Client_hints#low_entropy_hints) are added to the request even though not specified in the server response.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-UA-Arch' = 'Sec-CH-UA-Arch',\n\n  /**\n   * The HTTP **`Sec-CH-UA-Bitness`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_agent_client_hints) which provides the \"bitness\" of the user-agent's underlying CPU architecture.\n   * This is the size in bits of an integer or memory address—typically 64 or 32 bits.\n   *\n   * This might be used by a server, for example, to select and offer the correct binary format of an executable for a user to download.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-UA-Bitness: <bitness>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<bitness>`\n   *   - : A string indicating the underlying platform architecture bitness, such as: `\"64\"`, `\"32\"`.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-UA-Bitness\n   *\n   * A server requests the `Sec-CH-UA-Bitness` header by including [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) in a _response_ to any request from the client, using the name of the desired header as a token:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Accept-CH: Sec-CH-UA-Bitness\n   * ```\n   *\n   * The client may choose to provide the hint, and add the `Sec-CH-UA-Bitness` header to subsequent requests.\n   * For example, on a Windows based 64-bit computer, the client might add the header as shown:\n   *\n   * ```http\n   * GET /my/page HTTP/1.1\n   * Host: example.site\n   *\n   * Sec-CH-UA: \" Not A;Brand\";v=\"99\", \"Chromium\";v=\"96\", \"Google Chrome\";v=\"96\"\n   * Sec-CH-UA-Mobile: ?0\n   * Sec-CH-UA-Platform: \"Windows\"\n   * Sec-CH-UA-Bitness: \"64\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-UA-Bitness' = 'Sec-CH-UA-Bitness',\n\n  /**\n   * The HTTP **`Sec-CH-UA-Form-Factors`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/Request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_agent_client_hints) which provides information on the user-agent's device form factor.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-UA-Form-Factors: <form-factor>\n   * Sec-CH-UA-Form-Factors: <form-factor>, …, <form-factor>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<form-factor>`\n   *   - : A string indicating a common device form factor.\n   *     All applicable form factors can be included.\n   *     The meanings of the allowed values are:\n   *     - `\"Desktop\"`\n   *       - : A user-agent running on a personal computer.\n   *     - `\"Automotive\"`\n   *       - : A user-agent embedded in a vehicle, where the user may be responsible for operating the vehicle and have limited ability to interact.\n   *     - `\"Mobile\"`\n   *       - : Small, touch-oriented device typically carried on a user's person.\n   *     - `\"Tablet\"`\n   *       - : A touch-oriented device larger than `\"Mobile\"` and not typically carried on a user's person.\n   *     - `\"XR\"`\n   *       - : Immersive devices that augment or replace the environment around the user.\n   *     - `\"EInk\"`\n   *       - : A device characterized by slow screen updates and limited or no color resolution.\n   *     - `\"Watch\"`\n   *       - : A mobile device with a tiny screen (typically less than 2 inches), carried in such a way that the user can glance at it quickly.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-UA-Form-Factors\n   *\n   * A server requests the `Sec-CH-UA-Form-Factors` header by including the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) in a _response_ to any request from the client, using the name of the desired header as a token:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Accept-CH: Sec-CH-UA-Form-Factors\n   * ```\n   *\n   * The client may choose to provide the hint, and add the `Sec-CH-UA-Form-Factors` header to subsequent requests.\n   * For example, the client might add the header as shown:\n   *\n   * ```http\n   * GET /my/page HTTP/1.1\n   * Host: example.site\n   *\n   * Sec-CH-UA-Mobile: ?0\n   * Sec-CH-UA-Form-Factors: \"EInk\"\n   * ```\n   *\n   * In this case, `\"EInk\"` means that the device is characterized by slow screen updates and limited color resolution, and as such, responses may differ depending on this hint.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) on developer.chrome.com\n   */\n  'Sec-CH-UA-Form-Factors' = 'Sec-CH-UA-Form-Factors',\n\n  /**\n   * The HTTP **`Sec-CH-UA-Full-Version-List`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_agent_client_hints) which provides the user-agent's branding and full version information.\n   *\n   * The **`Sec-CH-UA-Full-Version-List`** header provides the brand and full version information for each brand associated with the browser, in a comma-separated list.\n   *\n   * The header may include \"fake\" brands in any position and with any name.\n   * This is a feature designed to prevent servers from rejecting unknown user agents outright, forcing user agents to lie about their brand identity.\n   *\n   * > [!NOTE]\n   * > This is similar to [Sec-CH-UA](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-UA), but includes the full version number instead of the significant version number for each brand.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-UA-Full-Version-List: \"<brand>\";v=\"<full version>\", …\n   * ```\n   *\n   * The value is a comma separated list of brands in the user agent brand list, and their associated full version number.\n   *\n   * ### Directives\n   *\n   * - `<brand>`\n   *   - : A brand associated with the user agent, like \"Chromium\", \"Google Chrome\".\n   *     This may be an intentionally incorrect brand like `\" Not A;Brand\"` or `\"(Not(A:Brand\"` (the actual value is expected change over time and be unpredictable).\n   * - `<full version>`\n   *   - : A full version number, such as 98.0.4750.0.\n   *\n   * ## Description\n   *\n   * A brand is a commercial name for the user agent like: Chromium, Opera, Google Chrome, Microsoft Edge, Firefox, and Safari.\n   * A user agent might have several associated brands.\n   * For example, Opera, Chrome, and Edge are all based on Chromium, and will provide both brands in the `Sec-CH-UA-Full-Version-List` header.\n   *\n   * The header allows the server to customize its response based on both shared brands and on particular customizations in their specific respective builds.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-UA-Full-Version-List\n   *\n   * A server requests the `Sec-CH-UA-Full-Version-List` header by including the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) in a _response_ to any request from the client, using the name of the desired header as a token:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Accept-CH: Sec-CH-UA-Full-Version-List\n   * ```\n   *\n   * The client may choose to provide the hint, and add the `Sec-CH-UA-Full-Version-List` header to subsequent requests, as shown below:\n   *\n   * ```http\n   * GET /my/page HTTP/1.1\n   * Host: example.site\n   *\n   * Sec-CH-UA: \" Not A;Brand\";v=\"99\", \"Chromium\";v=\"98\", \"Google Chrome\";v=\"98\"\n   * Sec-CH-UA-Mobile: ?0\n   * Sec-CH-UA-Full-Version-List: \" Not A;Brand\";v=\"99.0.0.0\", \"Chromium\";v=\"98.0.4750.0\", \"Google Chrome\";v=\"98.0.4750.0\"\n   * Sec-CH-UA-Platform: \"Linux\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-UA-Full-Version-List' = 'Sec-CH-UA-Full-Version-List',\n\n  /**\n   * > [!NOTE]\n   * > This is being replaced by the [Sec-CH-UA-Full-Version-List](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-UA-Full-Version-List).\n   *\n   * The HTTP **`Sec-CH-UA-Full-Version`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_agent_client_hints) which provides the user-agent's full version string.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-UA-Full-Version: <version>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<version>`\n   *   - : A string containing the full version number, like \"96.0.4664.93\".\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-UA-Full-Version\n   *\n   * A server requests the `Sec-CH-UA-Full-Version` header by including the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) in a _response_ to any request from the client, using the name of the desired header as a token:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Accept-CH: Sec-CH-UA-Full-Version\n   * ```\n   *\n   * The client may choose to provide the hint, and add the `Sec-CH-UA-Full-Version` header to subsequent requests.\n   * For example, the client might add the header as shown:\n   *\n   * ```http\n   * GET /my/page HTTP/1.1\n   * Host: example.site\n   *\n   * Sec-CH-UA: \" Not A;Brand\";v=\"99\", \"Chromium\";v=\"96\", \"Google Chrome\";v=\"96\"\n   * Sec-CH-UA-Mobile: ?0\n   * Sec-CH-UA-Full-Version: \"96.0.4664.110\"\n   * Sec-CH-UA-Platform: \"Windows\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-UA-Full-Version' = 'Sec-CH-UA-Full-Version',\n\n  /**\n   * The HTTP **`Sec-CH-UA-Mobile`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_agent_client_hints) which indicates whether the browser is on a mobile device.\n   * It can also be used by a desktop browser to indicate a preference for a \"mobile\" user experience.\n   *\n   * `Sec-CH-UA-Mobile` is a [low entropy hint](/en-US/docs/Web/HTTP/Guides/Client_hints#low_entropy_hints).\n   * Unless blocked by a user agent permission policy, it is sent by default, without the server opting in by sending [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-UA-Mobile: <boolean>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<boolean>`\n   *   - : `?1` indicates that the user-agent prefers a mobile experience (true).\n   *     `?0` indicates that user-agent does not prefer a mobile experience (false).\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-UA-Mobile\n   *\n   * As `Sec-CH-UA-Mobile` is a [low entropy hint](/en-US/docs/Web/HTTP/Guides/Client_hints#low_entropy_hints) it is typically sent in all requests.\n   * A desktop browser would usually send requests with the following header:\n   *\n   * ```http\n   * Sec-CH-UA-Mobile: ?0\n   * ```\n   *\n   * A browser on a mobile device would usually send requests with the following header:\n   *\n   * ```http\n   * Sec-CH-UA-Mobile: ?1\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-UA-Mobile' = 'Sec-CH-UA-Mobile',\n\n  /**\n   * The HTTP **`Sec-CH-UA-Model`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_agent_client_hints) which indicates the device model on which the browser is running.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-UA-Model: <device-version>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<device-version>`\n   *   - : A string containing the device version. For example \"Pixel 3\".\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-UA-Model\n   *\n   * A server requests the `Sec-CH-UA-Model` header by including [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) in a _response_ to any request from the client, using the name of the desired header as a token:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Accept-CH: Sec-CH-UA-Model\n   * ```\n   *\n   * The client may choose to provide the hint, and add the `Sec-CH-UA-Model` header to subsequent requests.\n   * For example, on mobile phone the client might add the header as shown:\n   *\n   * ```http\n   * GET /my/page HTTP/1.1\n   * Host: example.site\n   *\n   * Sec-CH-UA: \" Not A;Brand\";v=\"99\", \"Chromium\";v=\"96\", \"Google Chrome\";v=\"96\"\n   * Sec-CH-UA-Mobile: ?1\n   * Sec-CH-UA-Platform: \"Android\"\n   * Sec-CH-UA-Bitness: \"64\"\n   * Sec-CH-UA-Model: \"Pixel 3 XL\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-UA-Model' = 'Sec-CH-UA-Model',\n\n  /**\n   * The HTTP **`Sec-CH-UA-Platform-Version`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_agent_client_hints) which provides the version of the operating system on which the user agent is running.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-UA-Platform-Version: <version>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<version>`\n   *   - : The version string typically contains the operating system version in a string, consisting of dot-separated major, minor and patch version numbers, for example `\"11.0.0\"`.\n   *     The version string on Linux is always empty.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-UA-Platform-Version\n   *\n   * A server requests the `Sec-CH-UA-Platform-Version` header by including the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) in a _response_ to any request from the client, using the name of the desired header as a token:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Accept-CH: Sec-CH-UA-Platform-Version\n   * ```\n   *\n   * The client may choose to provide the hint, and add the `Sec-CH-UA-Platform-Version` header to subsequent requests.\n   * For example, the following request headers might be sent from a browser running on Windows 10.\n   *\n   * ```http\n   * GET /my/page HTTP/1.1\n   * Host: example.site\n   *\n   * Sec-CH-UA: \" Not A;Brand\";v=\"99\", \"Chromium\";v=\"96\", \"Google Chrome\";v=\"96\"\n   * Sec-CH-UA-Mobile: ?0\n   * Sec-CH-UA-Platform: \"Windows\"\n   * Sec-CH-UA-Platform-Version: \"10.0.0\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-UA-Platform-Version' = 'Sec-CH-UA-Platform-Version',\n\n  /**\n   * The HTTP **`Sec-CH-UA-Platform`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_agent_client_hints) which provides the platform or operating system on which the user agent is running.\n   * For example: \"Windows\" or \"Android\".\n   *\n   * `Sec-CH-UA-Platform` is a [low entropy hint](/en-US/docs/Web/HTTP/Guides/Client_hints#low_entropy_hints).\n   * Unless blocked by a user agent permission policy, it is sent by default (without the server opting in by sending [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-UA-Platform: <platform>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<platform>`\n   *   - : One of the following strings: `\"Android\"`, `\"Chrome OS\"`, `\"Chromium OS\"`, `\"iOS\"`, `\"Linux\"`, `\"macOS\"`, `\"Windows\"`, or `\"Unknown\"`.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-UA-Platform\n   *\n   * As `Sec-CH-UA-Platform` is a [low entropy hint](/en-US/docs/Web/HTTP/Guides/Client_hints#low_entropy_hints) it is typically sent in all requests.\n   * A browser running on a macOS computer might add the following header to all requests.\n   *\n   * ```http\n   * Sec-CH-UA-Platform: \"macOS\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-UA-Platform' = 'Sec-CH-UA-Platform',\n\n  /**\n   * The HTTP **`Sec-CH-UA-WoW64`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/Request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_agent_client_hints) indicating if a 32-bit user-agent application is running on a 64-bit Windows machine.\n   *\n   * [WoW64](https://en.wikipedia.org/wiki/WoW64) was commonly used to know which [NPAPI](https://en.wikipedia.org/wiki/NPAPI) plugin installer should be offered for download.\n   * This client hint header is used for backwards compatibility considerations, to provide a one-to-one mapping from the user-agent string of certain browsers to UA client hints.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-UA-WoW64: <boolean>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<boolean>`\n   *   - : `?1` indicates that the user agent's binary is running in 32-bit mode on 64-bit Windows (true), while `?0` means that it is not (false).\n   *\n   * ## Examples\n   *\n   * ### Using Sec-CH-UA-WoW64\n   *\n   * A server requests the `Sec-CH-UA-WoW64` header by including the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) in a _response_ to any request from the client, using the name of the desired header as a token:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Accept-CH: Sec-CH-UA-WoW64\n   * ```\n   *\n   * The client may choose to provide the hint, and add the `Sec-CH-UA-WoW64` header to subsequent requests.\n   * Adding `Sec-CH-UA-WoW64: ?1` means the user agent's binary is running in 32-bit mode on 64-bit Windows:\n   *\n   * ```http\n   * GET /my/page HTTP/1.1\n   * Host: example.site\n   *\n   * Sec-CH-UA-WoW64: ?1\n   * Sec-CH-UA-Platform: \"Windows\"\n   * Sec-CH-UA-Form-Factors: \"Desktop\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) on developer.chrome.com\n   */\n  'Sec-CH-UA-WoW64' = 'Sec-CH-UA-WoW64',\n\n  /**\n   * The HTTP **`Sec-CH-UA`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [user agent client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#user_agent_client_hints) which provides the user-agent's branding and significant version information.\n   *\n   * The `Sec-CH-UA` header provides the brand and significant version for each brand associated with the browser in a comma-separated list.\n   * The header therefore allows the server to customize its response based on both shared brands and on particular customizations in their respective versions.\n   *\n   * `Sec-CH-UA` is a [low entropy hint](/en-US/docs/Web/HTTP/Guides/Client_hints#low_entropy_hints).\n   * Unless blocked by a user agent permission policy, it is sent by default, without the server opting in by sending [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH).\n   *\n   * The header may include \"fake\" brands in any position and with any name.\n   * This is a feature designed to prevent servers from rejecting unknown user agents outright, forcing user agents to lie about their brand identity.\n   *\n   * > [!NOTE]\n   * > The [Sec-CH-UA-Full-Version-List](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-UA-Full-Version-List) header is the same as `Sec-CH-UA`, but includes the full version number rather than the significant version number for each brand.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-CH-UA: \"<brand>\";v=\"<significant version>\", …\n   * ```\n   *\n   * The value is a comma separated list of brands in the user agent brand list, and their associated significant version number.\n   *\n   * ### Directives\n   *\n   * - `<brand>`\n   *   - : A brand associated with the user agent, like \"Chromium\", \"Google Chrome\", or an intentionally incorrect brand like `\"Not A;Brand\"`.\n   * - `<significant version>`\n   *   - : The \"marketing\" version number associated with distinguishable web-exposed features.\n   *\n   * ## Description\n   *\n   * A brand is a commercial name for the user agent like: Chromium, Opera, Google Chrome, Microsoft Edge, Firefox, and Safari.\n   * A user agent might have several associated brands.\n   * For example, Opera, Chrome, and Edge are all based on Chromium, and will provide both brands in the `Sec-CH-UA` header.\n   *\n   * The _significant version_ is the \"marketing\" version identifier that is used to distinguish between major releases of the brand.\n   * For example a Chromium build with _full version number_ \"96.0.4664.45\" has a significant version number of \"96\".\n   *\n   * ## Examples\n   *\n   * ### Different Sec-CH-UA brands\n   *\n   * `Sec-CH-UA` is a [low entropy hint](/en-US/docs/Web/HTTP/Guides/Client_hints#low_entropy_hints).\n   * Unless explicitly blocked by a user agent policy, it will be sent in all requests (without the server having to opt in by sending [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)).\n   *\n   * Strings from Chromium, Chrome, Edge, and Opera desktop browsers are shown below.\n   * Note that they all share the \"Chromium\" brand, but have an additional brand indicating their origin.\n   * They also have an intentionally incorrect brand string, which may appear in any position and have different text.\n   *\n   * ```http\n   * Sec-CH-UA: \"(Not(A:Brand\";v=\"8\", \"Chromium\";v=\"98\"\n   * ```\n   *\n   * ```http\n   * Sec-CH-UA: \" Not A;Brand\";v=\"99\", \"Chromium\";v=\"96\", \"Google Chrome\";v=\"96\"\n   * ```\n   *\n   * ```http\n   * Sec-CH-UA: \" Not A;Brand\";v=\"99\", \"Chromium\";v=\"96\", \"Microsoft Edge\";v=\"96\"\n   * ```\n   *\n   * ```http\n   * Sec-CH-UA: \"Opera\";v=\"81\", \" Not;A Brand\";v=\"99\", \"Chromium\";v=\"95\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   * - [User-Agent Client Hints API](/en-US/docs/Web/API/User-Agent_Client_Hints_API)\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Sec-CH-UA' = 'Sec-CH-UA',\n\n  /**\n   * The HTTP **`Sec-Fetch-Dest`** [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/fetch_metadata_request_header) indicates the request's _destination_.\n   * That is the initiator of the original fetch request, which is where (and how) the fetched data will be used.\n   *\n   * This allows servers to determine whether to service a request based on whether it is appropriate for how it is _expected_ to be used. For example, a request with an `audio` destination should request audio data, not some other type of resource (for example, a document that includes sensitive user information).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-Fetch-Dest: audio\n   * Sec-Fetch-Dest: audioworklet\n   * Sec-Fetch-Dest: document\n   * Sec-Fetch-Dest: embed\n   * Sec-Fetch-Dest: empty\n   * Sec-Fetch-Dest: fencedframe\n   * Sec-Fetch-Dest: font\n   * Sec-Fetch-Dest: frame\n   * Sec-Fetch-Dest: iframe\n   * Sec-Fetch-Dest: image\n   * Sec-Fetch-Dest: manifest\n   * Sec-Fetch-Dest: object\n   * Sec-Fetch-Dest: paintworklet\n   * Sec-Fetch-Dest: report\n   * Sec-Fetch-Dest: script\n   * Sec-Fetch-Dest: serviceworker\n   * Sec-Fetch-Dest: sharedworker\n   * Sec-Fetch-Dest: style\n   * Sec-Fetch-Dest: track\n   * Sec-Fetch-Dest: video\n   * Sec-Fetch-Dest: webidentity\n   * Sec-Fetch-Dest: worker\n   * Sec-Fetch-Dest: xslt\n   * ```\n   *\n   * Servers should ignore this header if it contains any other value.\n   *\n   * ## Directives\n   *\n   * > [!NOTE]\n   * > These directives correspond to the values returned by [Request.destination](https://developer.mozilla.org/en-US/docs/domxref/Request.destination).\n   *\n   * - `audio`\n   *   - : The destination is audio data. This might originate from an HTML [audio](https://developer.mozilla.org/en-US/docs/HTMLElement/audio) tag.\n   * - `audioworklet`\n   *   - : The destination is data being fetched for use by an audio worklet. This might originate from a call to [audioWorklet.addModule()](https://developer.mozilla.org/en-US/docs/domxref/Worklet.addModule()).\n   * - `document`\n   *   - : The destination is a document (HTML or XML), and the request is the result of a user-initiated top-level navigation (e.g., resulting from a user clicking a link).\n   * - `embed`\n   *   - : The destination is embedded content. This might originate from an HTML [embed](https://developer.mozilla.org/en-US/docs/HTMLElement/embed) tag.\n   * - `empty`\n   *   - : The destination is the empty string. This is used for destinations that do not have their own value. For example: [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch), [navigator.sendBeacon()](https://developer.mozilla.org/en-US/docs/domxref/navigator.sendBeacon()), [EventSource](https://developer.mozilla.org/en-US/docs/domxref/EventSource), [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest), [WebSocket](https://developer.mozilla.org/en-US/docs/domxref/WebSocket), etc.\n   * - `fencedframe`\n   *   - : The destination is a [fenced frame](/en-US/docs/Web/API/Fenced_frame_API).\n   * - `font`\n   *   - : The destination is a font. This might originate from CSS [@font-face](https://developer.mozilla.org/en-US/docs/cssxref/@font-face).\n   * - `frame`\n   *   - : The destination is a frame. This might originate from an HTML [frame](https://developer.mozilla.org/en-US/docs/HTMLElement/frame) tag.\n   * - `iframe`\n   *   - : The destination is an iframe. This might originate from an HTML [iframe](https://developer.mozilla.org/en-US/docs/HTMLElement/iframe) tag.\n   * - `image`\n   *   - : The destination is an image. This might originate from an HTML [img](https://developer.mozilla.org/en-US/docs/HTMLElement/img), SVG [image](https://developer.mozilla.org/en-US/docs/SVGElement/image), CSS [background-image](https://developer.mozilla.org/en-US/docs/cssxref/background-image), CSS [cursor](https://developer.mozilla.org/en-US/docs/cssxref/cursor), CSS [list-style-image](https://developer.mozilla.org/en-US/docs/cssxref/list-style-image), etc.\n   * - `manifest`\n   *   - : The destination is a manifest. This might originate from an HTML [\\<link rel=manifest>](/en-US/docs/Web/HTML/Reference/Attributes/rel/manifest).\n   * - `object`\n   *   - : The destination is an object. This might originate from an HTML [object](https://developer.mozilla.org/en-US/docs/HTMLElement/object) tag.\n   * - `paintworklet`\n   *   - : The destination is a paint worklet. This might originate from a call to .\n   * - `report`\n   *   - : The destination is a report (for example, a content security policy report).\n   * - `script`\n   *   - : The destination is a script. This might originate from an HTML [script](https://developer.mozilla.org/en-US/docs/HTMLElement/script) tag or a call to [WorkerGlobalScope.importScripts()](https://developer.mozilla.org/en-US/docs/domxref/WorkerGlobalScope.importScripts()).\n   * - `serviceworker`\n   *   - : The destination is a service worker. This might originate from a call to [navigator.serviceWorker.register()](https://developer.mozilla.org/en-US/docs/domxref/ServiceWorkerContainer.register).\n   * - `sharedworker`\n   *   - : The destination is a shared worker. This might originate from a [SharedWorker](https://developer.mozilla.org/en-US/docs/domxref/SharedWorker).\n   * - `style`\n   *   - : The destination is a style. This might originate from an HTML [&lt;link rel=stylesheet&gt;](https://developer.mozilla.org/en-US/docs/HTMLElement/link) or a CSS [@import](https://developer.mozilla.org/en-US/docs/cssxref/@import).\n   * - `track`\n   *   - : The destination is an HTML text track. This might originate from an HTML [track](https://developer.mozilla.org/en-US/docs/HTMLElement/track) tag.\n   * - `video`\n   *   - : The destination is video data. This might originate from an HTML [video](https://developer.mozilla.org/en-US/docs/HTMLElement/video) tag.\n   * - `webidentity`\n   *   - : The destination is an endpoint associated with verifying user identify. For example, it is used in the [FedCM API](/en-US/docs/Web/API/FedCM_API) to verify the authenticity of identity provider (IdP) endpoints, guarding against [CSRF](https://developer.mozilla.org/en-US/docs/glossary/CSRF) attacks.\n   * - `worker`\n   *   - : The destination is a [Worker](https://developer.mozilla.org/en-US/docs/domxref/Worker).\n   * - `xslt`\n   *   - : The destination is an XSLT transform.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-Fetch-Dest\n   *\n   * A cross-site request generated by an [img](https://developer.mozilla.org/en-US/docs/HTMLElement/img) element would result in a request with the following HTTP request headers (note that the destination is `image`):\n   *\n   * ```http\n   * Sec-Fetch-Dest: image\n   * Sec-Fetch-Mode: no-cors\n   * Sec-Fetch-Site: cross-site\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Sec-Fetch-Mode](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode), [Sec-Fetch-Site](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site), [Sec-Fetch-User](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-User) fetch metadata request headers\n   * - [Protect your resources from web attacks with Fetch Metadata](https://web.dev/articles/fetch-metadata) (web.dev)\n   * - [Fetch Metadata Request Headers playground](https://secmetadata.appspot.com/) (secmetadata.appspot.com)\n   */\n  'Sec-Fetch-Dest' = 'Sec-Fetch-Dest',\n\n  /**\n   * The HTTP **`Sec-Fetch-Mode`** [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/fetch_metadata_request_header) indicates the [mode](/en-US/docs/Web/API/Request/mode) of the request.\n   *\n   * Broadly speaking, this allows a server to distinguish between requests originating from a user navigating between HTML pages, and requests to load images and other resources.\n   * For example, this header would contain `navigate` for top level navigation requests, while `no-cors` is used for loading an image.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-Fetch-Mode: cors\n   * Sec-Fetch-Mode: navigate\n   * Sec-Fetch-Mode: no-cors\n   * Sec-Fetch-Mode: same-origin\n   * Sec-Fetch-Mode: websocket\n   * ```\n   *\n   * Servers should ignore this header if it contains any other value.\n   *\n   * ## Directives\n   *\n   * > [!NOTE]\n   * > These directives correspond to the values in [`Request.mode`](/en-US/docs/Web/API/Request/mode#value).\n   *\n   * - `cors`\n   *   - : The request is a [CORS protocol](/en-US/docs/Web/HTTP/Guides/CORS) request.\n   * - `navigate`\n   *   - : The request is initiated by navigation between HTML documents.\n   * - `no-cors`\n   *   - : The request is a no-cors request (see [`Request.mode`](/en-US/docs/Web/API/Request/mode#value)).\n   * - `same-origin`\n   *   - : The request is made from the same origin as the resource that is being requested.\n   * - `websocket`\n   *   - : The request is being made to establish a [WebSocket](/en-US/docs/Web/API/WebSockets_API) connection.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-Fetch-Mode\n   *\n   * If a user clicks on a page link to another page on the same origin, the resulting request would have the following headers (note that the mode is `navigate`):\n   *\n   * ```http\n   * Sec-Fetch-Dest: document\n   * Sec-Fetch-Mode: navigate\n   * Sec-Fetch-Site: same-origin\n   * Sec-Fetch-User: ?1\n   * ```\n   *\n   * A cross-site request generated by an [img](https://developer.mozilla.org/en-US/docs/HTMLElement/img) element would result in a request with the following HTTP request headers (note that the mode is `no-cors`):\n   *\n   * ```http\n   * Sec-Fetch-Dest: image\n   * Sec-Fetch-Mode: no-cors\n   * Sec-Fetch-Site: cross-site\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Sec-Fetch-Dest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest), [Sec-Fetch-Site](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site), [Sec-Fetch-User](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-User) fetch metadata request headers\n   * - [Protect your resources from web attacks with Fetch Metadata](https://web.dev/articles/fetch-metadata) (web.dev)\n   * - [Fetch Metadata Request Headers playground](https://secmetadata.appspot.com/) (secmetadata.appspot.com)\n   */\n  'Sec-Fetch-Mode' = 'Sec-Fetch-Mode',\n\n  /**\n   * The HTTP **`Sec-Fetch-Site`** [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/fetch_metadata_request_header) indicates the relationship between a request initiator's origin and the origin of the requested resource.\n   *\n   * In other words, this header tells a server whether a request for a resource is coming from the same origin, the same site, a different site, or is a \"user initiated\" request. The server can then use this information to decide if the request should be allowed.\n   *\n   * Same-origin requests would usually be allowed by default, but what happens for requests from other origins may further depend on what resource is being requested, or information in another [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/fetch_metadata_request_header). By default, requests that are not accepted should be rejected with a [403](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403) response code.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-Fetch-Site: cross-site\n   * Sec-Fetch-Site: same-origin\n   * Sec-Fetch-Site: same-site\n   * Sec-Fetch-Site: none\n   * ```\n   *\n   * ## Directives\n   *\n   * - `cross-site`\n   *   - : The request initiator and the server hosting the resource have a different site (i.e., a request by \"potentially-evil.com\" for a resource at \"example.com\").\n   * - `same-origin`\n   *   - : The request initiator and the server hosting the resource have the same [origin](https://developer.mozilla.org/en-US/docs/Glossary/origin) (same scheme, host and port).\n   * - `same-site`\n   *   - : The request initiator and the server hosting the resource have the same [site](https://developer.mozilla.org/en-US/docs/glossary/site), including the scheme.\n   * - `none`\n   *   - : This request is a user-originated operation. For example: entering a URL into the address bar, opening a bookmark, or dragging-and-dropping a file into the browser window.\n   *\n   * ## Examples\n   *\n   * A fetch request to `https://mysite.example/foo.json` originating from a web page on `https://mysite.example` (with the same port) is a same-origin request.\n   * The browser will generate the `Sec-Fetch-Site: same-origin` header as shown below, and the server will typically allow the request:\n   *\n   * ```http\n   * GET /foo.json\n   * Sec-Fetch-Dest: empty\n   * Sec-Fetch-Mode: cors\n   * Sec-Fetch-Site: same-origin\n   * ```\n   *\n   * A fetch request to the same URL from another site, for example `potentially-evil.com`, causes the browser to generate a different header (e.g., `Sec-Fetch-Site: cross-site`), which the server can choose to accept or reject:\n   *\n   * ```http\n   * GET /foo.json\n   * Sec-Fetch-Dest: empty\n   * Sec-Fetch-Mode: cors\n   * Sec-Fetch-Site: cross-site\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Sec-Fetch-Mode](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode), [Sec-Fetch-User](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-User), [Sec-Fetch-Dest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest) fetch metadata request headers\n   * - [Protect your resources from web attacks with Fetch Metadata](https://web.dev/articles/fetch-metadata) (web.dev)\n   * - [Fetch Metadata Request Headers playground](https://secmetadata.appspot.com/) (secmetadata.appspot.com)\n   */\n  'Sec-Fetch-Site' = 'Sec-Fetch-Site',\n\n  /**\n   * The HTTP **`Sec-Fetch-User`** [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/fetch_metadata_request_header) is sent for requests initiated by user activation, and its value is always `?1`.\n   *\n   * A server can use this header to identify whether a navigation request from a document, iframe, etc., was originated by the user.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-Fetch-User: ?1\n   * ```\n   *\n   * ## Directives\n   *\n   * The value will always be `?1`. When a request is triggered by something other than a user activation, the spec requires browsers to omit the header completely.\n   *\n   * ## Examples\n   *\n   * ### Using Sec-Fetch-User\n   *\n   * If a user clicks on a page link to another page on the same origin, the resulting request would have the following headers:\n   *\n   * ```http\n   * Sec-Fetch-Dest: document\n   * Sec-Fetch-Mode: navigate\n   * Sec-Fetch-Site: same-origin\n   * Sec-Fetch-User: ?1\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Sec-Fetch-Dest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest), [Sec-Fetch-Mode](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode), [Sec-Fetch-Site](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site) fetch metadata request headers\n   * - [Protect your resources from web attacks with Fetch Metadata](https://web.dev/articles/fetch-metadata) (web.dev)\n   * - [Fetch Metadata Request Headers playground](https://secmetadata.appspot.com/) (secmetadata.appspot.com)\n   */\n  'Sec-Fetch-User' = 'Sec-Fetch-User',\n\n  /**\n   * The HTTP **`Sec-GPC`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is part of the [Global Privacy Control](https://globalprivacycontrol.org/) (GPC) mechanism to indicate whether the user consents to a website or service selling or sharing their personal information with third parties.\n   *\n   * The specification does not define how the user can withdraw or grant consent for website.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-GPC: <preference>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<preference>`\n   *   - : A value of `1` means the user has indicated that they prefer their information not be shared with, or sold to, third parties.\n   *     Otherwise, the header is not sent, which indicates that either the user has not made a decision or the user is okay with their information being shared with or sold to third parties.\n   *\n   * ## Examples\n   *\n   * ### Reading Global Privacy Control status from JavaScript\n   *\n   * The user's GPC preference can also be read from JavaScript using the [Navigator.globalPrivacyControl](https://developer.mozilla.org/en-US/docs/domxref/Navigator.globalPrivacyControl) or [WorkerNavigator.globalPrivacyControl](https://developer.mozilla.org/en-US/docs/domxref/WorkerNavigator.globalPrivacyControl) property:\n   *\n   * ```js\n   * navigator.globalPrivacyControl; // \"false\" or \"true\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Navigator.globalPrivacyControl](https://developer.mozilla.org/en-US/docs/domxref/Navigator.globalPrivacyControl)\n   * - [DNT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DNT) header\n   * - [Tk](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Tk) header\n   * - [globalprivacycontrol.org](https://globalprivacycontrol.org/)\n   * - [Do Not Track on Wikipedia](https://en.wikipedia.org/wiki/Do_Not_Track)\n   */\n  'Sec-GPC' = 'Sec-GPC',\n\n  /**\n   * The HTTP **`Sec-Purpose`** [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/fetch_metadata_request_header) indicates the purpose for which the requested resource will be used, when that purpose is something other than immediate use by the user-agent.\n   *\n   * The only purpose that is currently defined is `prefetch`, which indicates that the resource is being requested in anticipation that it will be needed by a page that is likely to be navigated to in the near future, such as a page linked in search results or a link that a user has hovered over.\n   * The server can use this knowledge to: adjust the caching expiry for the request, disallow the request, or perhaps to treat it differently when counting page visits.\n   *\n   * The header is sent when a page is loaded that has a [`\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-Purpose: prefetch\n   * ```\n   *\n   * ## Directives\n   *\n   * The allowed tokens are:\n   *\n   * - `prefetch`\n   *   - : The purpose is to prefetch a resource that may be needed in a probable future navigation.\n   *\n   * ## Examples\n   *\n   * ### A prefetch request\n   *\n   * Consider the case where a browser loads a file with a [`<link>`](/en-US/docs/Web/HTML/Reference/Elements/link) element that has the attribute `rel=\"prefetch\"` and an `href` attribute containing the address of an image file.\n   * The resulting `fetch()` should result in an HTTP request where `Sec-Purpose: prefetch`, `Sec-Fetch-Dest: empty`, and an `Accept` value that is the same as the browser uses for page navigation.\n   *\n   * An example of such a header (on Firefox) is given below:\n   *\n   * ```http\n   * GET /images/some_image.png HTTP/1.1\n   * Host: example.com\n   * User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0\n   * Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,* /*;q=0.8\n   * Accept-Language: en-US,en;q=0.5\n   * Accept-Encoding: gzip, deflate, br\n   * Sec-Purpose: prefetch\n   * Connection: keep-alive\n   * Sec-Fetch-Dest: empty\n   * Sec-Fetch-Mode: no-cors\n   * Sec-Fetch-Site: same-origin\n   * Pragma: no-cache\n   * Cache-Control: no-cache\n   * ```\n   *\n   * > [!NOTE]\n   * > At time of writing Firefox incorrectly sets the `Accept` header as `Accept: * /*` for prefetches.\n   * > The example has been modified to show what the `Accept` value should be.\n   * > This issue can be tracked in [Firefox bug 1836334](https://bugzil.la/1836334).\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Sec-Fetch-Dest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest), [Sec-Fetch-Mode](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode), [Sec-Fetch-Site](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site), [Sec-Fetch-User](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-User) fetch metadata request headers\n   * - [Prefetch](https://developer.mozilla.org/en-US/docs/Glossary/Prefetch) (Glossary)\n   * - [`<link>`](/en-US/docs/Web/HTML/Reference/Elements/link) element with attribute [`rel=\"prefetch\"`](/en-US/docs/Web/HTML/Reference/Attributes/rel/prefetch)\n   */\n  'Sec-Purpose' = 'Sec-Purpose',\n\n  /**\n   * The HTTP **`Sec-Speculation-Tags`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) contains one or more `tag` values from the [speculation rules](/en-US/docs/Web/API/Speculation_Rules_API) that resulted in the speculation. This allows a server to identify which rule(s) caused a speculation and potentially block them.\n   *\n   * For example, a CDN may automatically insert speculation rules, but block speculations for resources not cached in the CDN to avoid unintended consequences. The `Sec-Speculation-Tags` header allows the CDN to differentiate between the rules it has inserted (which should be blocked in this case) and speculation rules added by the site owner (which should not be blocked).\n   *\n   *\n   * ```\n   *\n   * Similar to the previous example, if the link is clicked immediately without waiting for the 200 millisecond hover, both rules would have triggered a speculation, therefore both tags will be included in the header. However, because the first rule does not include a `tag` field, it is represented in the header with a `null` value:\n   *\n   * ```http\n   * Sec-Speculation-Tags: null, \"cdn-rule\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Speculation Rules API](/en-US/docs/Web/API/Speculation_Rules_API)\n   * - [`<script type=\"speculationrules\">`](/en-US/docs/Web/HTML/Reference/Elements/script/type/speculationrules)\n   */\n  'Sec-Speculation-Tags' = 'Sec-Speculation-Tags',\n\n  /**\n   * The HTTP **Sec-WebSocket-Accept** [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to indicate that the server is willing to upgrade to a WebSocket connection.\n   *\n   * This header must appear no more than once in the response, and has a directive value that is calculated from the [Sec-WebSocket-Key](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Key) request header sent in the corresponding request.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-WebSocket-Accept: <hashed key>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<hashed key>`\n   *   - : If a [Sec-WebSocket-Key](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Key) header was provided, the value of this header is computed by taking the value of the key, concatenating the string `258EAFA5-E914-47DA-95CA-C5AB0DC85B11`, and taking the [SHA-1](https://en.wikipedia.org/wiki/SHA-1) hash of that concatenated string — resulting in a 20-byte value.\n   *     That value is then [base64](/en-US/docs/Glossary/Base64) encoded to obtain the value of this property.\n   *\n   * ## Examples\n   *\n   * ### WebSocket opening handshake\n   *\n   * The client will initiate a WebSocket handshake with a request like the following.\n   * Note that this starts as an HTTP `GET` request (HTTP/1.1 or later) and includes the [Upgrade](https://developer.mozilla.org/en-US/docs/httpheader/Upgrade) header indicating the intent to upgrade to a WebSocket connection.\n   * It also includes `Sec-WebSocket-Key`, which is used in the calculation of `Sec-WebSocket-Accept` to confirm the intent to upgrade the connection to a WebSocket connection.\n   *\n   * ```http\n   * GET /chat HTTP/1.1\n   * Host: example.com:8000\n   * Upgrade: websocket\n   * Connection: Upgrade\n   * Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\n   * Sec-WebSocket-Version: 13\n   * ```\n   *\n   * The response from the server should include the `Sec-WebSocket-Accept` header with a value that is calculated from the `Sec-WebSocket-Key` header in the request, and confirms the intent to upgrade the connection to a WebSocket connection:\n   *\n   * ```http\n   * HTTP/1.1 101 Switching Protocols\n   * Upgrade: websocket\n   * Connection: Upgrade\n   * Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Sec-WebSocket-Key](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Key)\n   * - [Sec-WebSocket-Version](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Version)\n   * - [Sec-WebSocket-Protocol](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Protocol)\n   * - [Sec-WebSocket-Extensions](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Extensions)\n   * - [The WebSocket handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) in _Writing WebSocket servers_\n   * - [HTTP Protocol upgrade mechanism](/en-US/docs/Web/HTTP/Guides/Protocol_upgrade_mechanism)\n   */\n  'Sec-WebSocket-Accept' = 'Sec-WebSocket-Accept',\n\n  /**\n   * The HTTP **Sec-WebSocket-Extensions** [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to negotiate a protocol extension used by the client and server.\n   *\n   * In a request the header specifies one or more extensions that the web application would like to use, in order of preference.\n   * These can be added as in multiple headers, or as comma separated values added to a single header.\n   * Each extension can also have one or more parameters — these are semicolon-separated values listed after the extension.\n   *\n   * In a response the header can only appear once, where it specifies the extension selected by the server from the client's preferences.\n   * This value must be the first extension that the server supports from the list provided in the request header.\n   *\n   * The request header is automatically added by the browser based on its own capabilities, and does not depend on parameters passed to the constructor when the `WebSocket` is created.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-WebSocket-Extensions: <extensions>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<extensions>`\n   *   - : A comma-separated list of extensions to request (or for the server to agree to support).\n   *     These are commonly selected from the [IANA WebSocket Extension Name Registry](https://www.iana.org/assignments/websocket/websocket.xml#extension-name) (custom extensions may also be used).\n   *     Extensions which take parameters delineate them with semicolons.\n   *\n   * ## Examples\n   *\n   * ### WebSocket opening handshake\n   *\n   * The HTTP request below shows the opening handshake where a client supports the `permessage-deflate` extension (with `client_max_window_bits` parameter), and the `bbf-usp-protocol` extension.\n   *\n   * ```http\n   * GET /chat HTTP/1.1\n   * Host: example.com:8000\n   * Upgrade: websocket\n   * Connection: Upgrade\n   * Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\n   * Sec-WebSocket-Version: 13\n   * Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits, bbf-usp-protocol\n   * ```\n   *\n   * The request below with separate headers for each extension is equivalent:\n   *\n   * ```http\n   * GET /chat HTTP/1.1\n   * Host: example.com:8000\n   * Upgrade: websocket\n   * Connection: Upgrade\n   * Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\n   * Sec-WebSocket-Version: 13\n   * Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits\n   * Sec-WebSocket-Extensions: bbf-usp-protocol\n   * ```\n   *\n   * The response below might be sent from a server to indicate that it will support the `permessage-deflate` extension:\n   *\n   * ```http\n   * HTTP/1.1 101 Switching Protocols\n   * Upgrade: websocket\n   * Connection: Upgrade\n   * Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=\n   * Sec-WebSocket-Extensions: permessage-deflate\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Sec-WebSocket-Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Accept)\n   * - [Sec-WebSocket-Key](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Key)\n   * - [Sec-WebSocket-Version](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Version)\n   * - [Sec-WebSocket-Protocol](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Protocol)\n   * - [The WebSocket handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) and [Subprotocols](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#subprotocols) in _Writing WebSocket servers_\n   */\n  'Sec-WebSocket-Extensions' = 'Sec-WebSocket-Extensions',\n\n  /**\n   * The HTTP **Sec-WebSocket-Key** [request header](https://developer.mozilla.org/en-US/docs/glossary/request_header) is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to allow a client (user agent) to confirm that it \"really wants\" to request that an HTTP client is upgraded to become a WebSocket.\n   *\n   * The value of the key is computed using an algorithm defined in the WebSocket specification, so this _does not provide security_.\n   * Instead, it helps to prevent non-WebSocket clients from inadvertently, or through misuse, requesting a WebSocket connection.\n   *\n   * This header is automatically added by user agents when a script opens a WebSocket; it cannot be added using the [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch) or [XMLHttpRequest.setRequestHeader()](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest.setRequestHeader()) methods.\n   *\n   * The server's [Sec-WebSocket-Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Accept) response header should include a value computed based upon the specified key value.\n   * The user agent can then validate this before this before confirming the connection.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-WebSocket-Key: <key>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<key>`\n   *   - : The key for this request to upgrade.\n   *     This is a randomly selected 16-byte nonce that has been base64-encoded and isomorphic encoded.\n   *     The user agent adds this when initiating the WebSocket connection.\n   *\n   * ## Examples\n   *\n   * ### WebSocket opening handshake\n   *\n   * The client will initiate a WebSocket handshake with a request like the following.\n   * Note that this starts as an HTTP `GET` request (HTTP/1.1 or later), in addition to `Sec-WebSocket-Key`, the request includes the [Upgrade](https://developer.mozilla.org/en-US/docs/httpheader/Upgrade) header, indicating the intent to upgrade from HTTP to a WebSocket connection.\n   *\n   * ```http\n   * GET /chat HTTP/1.1\n   * Host: example.com:8000\n   * Upgrade: websocket\n   * Connection: Upgrade\n   * Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\n   * Sec-WebSocket-Version: 13\n   * ```\n   *\n   * The response from the server should include the `Sec-WebSocket-Accept` header with a value that is calculated from the `Sec-WebSocket-Key` header in the request, and confirms the intent to upgrade the connection to a WebSocket connection:\n   *\n   * ```http\n   * HTTP/1.1 101 Switching Protocols\n   * Upgrade: websocket\n   * Connection: Upgrade\n   * Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Sec-WebSocket-Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Accept)\n   * - [Sec-WebSocket-Version](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Version)\n   * - [Sec-WebSocket-Protocol](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Protocol)\n   * - [Sec-WebSocket-Extensions](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Extensions)\n   * - [The WebSocket handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) in _Writing WebSocket servers_\n   * - [HTTP Protocol upgrade mechanism](/en-US/docs/Web/HTTP/Guides/Protocol_upgrade_mechanism)\n   */\n  'Sec-WebSocket-Key' = 'Sec-WebSocket-Key',\n\n  /**\n   * The HTTP **`Sec-WebSocket-Protocol`** [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to negotiate a [sub-protocol](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#subprotocols) to use in the communication.\n   * This can be a well understood protocol, such as SOAP or WAMP, or a custom protocol understood by the client and server.\n   *\n   * In a request the header specifies one or more WebSocket sub-protocols that the web application would like to use, in order of preference.\n   * These can be added as protocol values in multiple headers, or as comma separate values added to a single header.\n   *\n   * In a response it specifies the sub-protocol selected by the server.\n   * This must be the first sub-protocol that the server supports from the list provided in the request header.\n   *\n   * The request header is automatically added and populated by the browser using values specified by the application in the [`protocols`](/en-US/docs/Web/API/WebSocket/WebSocket#protocols) argument to the `WebSocket()`.\n   * The sub-protocol selected by the server is made available to the web application in [WebSocket.protocol](https://developer.mozilla.org/en-US/docs/domxref/WebSocket.protocol).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Sec-WebSocket-Protocol: <sub-protocols>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<sub-protocols>`\n   *   - : A comma-separated list of sub-protocol names, in the order of preference.\n   *     The sub-protocols may be selected from the [IANA WebSocket Subprotocol Name Registry](https://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name), or may be a custom name jointly understood by the client and the server.\n   *\n   *     As a response header, this is a single sub-protocol that the server selected.\n   *\n   * ## Examples\n   *\n   * ### WebSocket opening handshake\n   *\n   * The sub-protocol is specified in the original WebSocket [handshake request](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake).\n   * The request below shows that the client prefers `soap`, but also supports `wamp`.\n   *\n   * ```http\n   * GET /chat HTTP/1.1\n   * Host: example.com:8000\n   * Upgrade: websocket\n   * Connection: Upgrade\n   * Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\n   * Sec-WebSocket-Version: 13\n   * Sec-WebSocket-Protocol: soap, wamp\n   * ```\n   *\n   * Specifying the protocols like this has the same effect:\n   *\n   * ```http\n   * Sec-WebSocket-Protocol: soap\n   * Sec-WebSocket-Protocol: wamp\n   * ```\n   *\n   * The response from the server will include the `Sec-WebSocket-Protocol` header, selecting the first sub-protocol that it supports from the client's preferences.\n   * Below that is shown as `soap`:\n   *\n   * ```http\n   * HTTP/1.1 101 Switching Protocols\n   * Upgrade: websocket\n   * Connection: Upgrade\n   * Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=\n   * Sec-WebSocket-Protocol: soap\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Sec-WebSocket-Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Accept)\n   * - [Sec-WebSocket-Key](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Key)\n   * - [Sec-WebSocket-Version](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Version)\n   * - [Sec-WebSocket-Extensions](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Extensions)\n   * - [The WebSocket handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) and [Subprotocols](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#subprotocols) in _Writing WebSocket servers_\n   */\n  'Sec-WebSocket-Protocol' = 'Sec-WebSocket-Protocol',\n\n  /**\n   * The HTTP **Sec-WebSocket-Version** [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) is used in the [WebSocket](/en-US/docs/Web/API/WebSockets_API) opening [handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to indicate the WebSocket protocol supported by the client, and the protocol versions supported by the server if it does _not_ support the version specified in the request.\n   *\n   * The header can only appear once in a request, and specifies the WebSocket version that web application is using.\n   * The current version of the protocol at time of writing is 13.\n   * The header is automatically added to requests by user agents when a [WebSocket](https://developer.mozilla.org/en-US/docs/domxref/WebSocket) connection is established.\n   *\n   * The server uses the version to determine if it can understand the protocol.\n   * If the server doesn't support the version, or any header in the handshake is not understood or has an incorrect value, the server should send a response with status [400 Bad Request](https://developer.mozilla.org/en-US/docs/httpstatus/400) and immediately close the socket.\n   * It should also include `Sec-WebSocket-Version` in the `400` response, listing the versions that it does support.\n   * The versions can be specified in individual headers, or as comma-separate values in a single header.\n   *\n   * The header should not be sent in responses if the server understands the version specified by the client.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * Request\n   *\n   * ```http\n   * Sec-WebSocket-Version: <version>\n   * ```\n   *\n   * Response (on error only):\n   *\n   * ```http\n   * Sec-WebSocket-Version: <server-supported-versions>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<version>`\n   *   - : The WebSocket protocol version the client wishes to use when communicating with the server.\n   *     This number should be the most recent version possible listed in the [IANA WebSocket Version Number Registry](https://www.iana.org/assignments/websocket/websocket.xml#version-number).\n   *     The most recent final version of the WebSocket protocol is version 13.\n   * - `<server-supported-versions>`\n   *   - : On error, a comma-delineated list of the WebSocket protocol versions supported by the server.\n   *     The header is not sent in responses if `<version>` is supported.\n   *\n   * ## Examples\n   *\n   * ### WebSocket opening handshake\n   *\n   * The version supported by the client is specified in the original `WebSocket` [handshake request](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake).\n   * For the current protocol, the version is \"13\", as shown below.\n   *\n   * ```http\n   * GET /chat HTTP/1.1\n   * Host: example.com:8000\n   * Upgrade: websocket\n   * Connection: Upgrade\n   * Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\n   * Sec-WebSocket-Version: 13\n   * ```\n   *\n   * If the server supports version 13 of the protocol, then `Sec-WebSocket-Version` will not appear in the response.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Sec-WebSocket-Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Accept)\n   * - [Sec-WebSocket-Key](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Key)\n   * - [Sec-WebSocket-Protocol](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Protocol)\n   * - [Sec-WebSocket-Extensions](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Extensions)\n   * - [The WebSocket handshake](/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) in _Writing WebSocket servers_\n   */\n  'Sec-WebSocket-Version' = 'Sec-WebSocket-Version',\n\n  /**\n   * The HTTP **`Server-Timing`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) communicates one or more performance metrics about the request-response cycle to the user agent.\n   * It is used to surface backend server timing metrics (for example, database read/write, CPU time, file system access, etc.) in the developer tools in the user's browser or in the [PerformanceServerTiming](https://developer.mozilla.org/en-US/docs/domxref/PerformanceServerTiming) interface.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * // A single metric\n   * Server-Timing: <timing-metric>\n   *\n   * // Multiple metrics as a comma-separated list\n   * Server-Timing: <timing-metric>, …, <timing-metricN>\n   * ```\n   *\n   * A `<timing-metric>` has a name, and may include an optional duration and an optional description.\n   * For example:\n   *\n   * ```http\n   * // A metric with a name only\n   * Server-Timing: missedCache\n   *\n   * // A metric with a duration\n   * Server-Timing: cpu;dur=2.4\n   *\n   * // A metric with a description and duration\n   * Server-Timing: cache;desc=\"Cache Read\";dur=23.2\n   *\n   * // Two metrics with duration values\n   * Server-Timing: db;dur=53, app;dur=47.2\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<timing-metric>`\n   *   - : A comma-separated list of one or more metrics with the following components separated by semi-colons:\n   *     - `<name>`\n   *       - : A name token (no spaces or special characters) for the metric that is implementation-specific or defined by the server, like `cacheHit`.\n   *     - `<duration>`\n   *       - : A duration as the string `dur`, followed by `=`, followed by a value, like `dur=23.2`.\n   *     - `<description>`\n   *       - : A description as the string `desc`, followed by `=`, followed by a value as a token or a quoted string, like `desc=prod` or `desc=\"DB lookup\"`.\n   *\n   * Names and descriptions should be kept as short as possible (for example, use abbreviations and omit optional values) to minimize HTTP data overhead.\n   *\n   * ## Description\n   *\n   * ### Privacy and security\n   *\n   * The `Server-Timing` header may expose potentially sensitive application and infrastructure information.\n   * Decide which metrics to send, when to send them, and who should see them based on the use case.\n   * For example, you may decide to only show metrics to authenticated users and nothing on public responses.\n   *\n   * ### PerformanceServerTiming interface\n   *\n   * In addition to having `Server-Timing` header metrics appear in the developer tools of the browser, the [PerformanceServerTiming](https://developer.mozilla.org/en-US/docs/domxref/PerformanceServerTiming) interface enables tools to automatically collect and process metrics from JavaScript. This interface is restricted to the same origin, but you can use the [Timing-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Timing-Allow-Origin) header to specify the domains that are allowed to access the server metrics. The interface is only available in secure contexts (HTTPS) in some browsers.\n   *\n   * The components of the `Server-Timing` header map to the [PerformanceServerTiming](https://developer.mozilla.org/en-US/docs/domxref/PerformanceServerTiming) properties as follows:\n   *\n   * - `\"name\"` -> [PerformanceServerTiming.name](https://developer.mozilla.org/en-US/docs/domxref/PerformanceServerTiming.name)\n   * - `\"dur\"` -> [PerformanceServerTiming.duration](https://developer.mozilla.org/en-US/docs/domxref/PerformanceServerTiming.duration)\n   * - `\"desc\"` -> [PerformanceServerTiming.description](https://developer.mozilla.org/en-US/docs/domxref/PerformanceServerTiming.description)\n   *\n   * ## Examples\n   *\n   * ### Sending a metric using the Server-Timing header\n   *\n   * The following response includes a metric `custom-metric` with a duration of `123.45` milliseconds, and a description of \"My custom metric\":\n   *\n   * ```http\n   * Server-Timing: custom-metric;dur=123.45;desc=\"My custom metric\"\n   * ```\n   *\n   * ### Server-Timing as HTTP trailer\n   *\n   * In the following response, the [Trailer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer) header is used to indicate that a `Server-Timing` header will follow the response body.\n   * A metric `custom-metric` with a duration of `123.4` milliseconds is sent.\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Transfer-Encoding: chunked\n   * Trailer: Server-Timing\n   *\n   * --- response body ---\n   * Server-Timing: custom-metric;dur=123.4\n   * ```\n   *\n   * > [!WARNING]\n   * > Only the browser's DevTools can use the `Server-Timing` header as a HTTP trailer to display information in the Network -> Timings tab.\n   * > The Fetch API cannot access HTTP trailers.\n   * > See [Browser compatibility](#browser_compatibility) for more information.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [PerformanceServerTiming](https://developer.mozilla.org/en-US/docs/domxref/PerformanceServerTiming)\n   * - [Trailer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer) header\n   */\n  'Server-Timing' = 'Server-Timing',\n\n  /**\n   * The HTTP **`Server`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) describes the software used by the origin server that handled the request and generated a response.\n   *\n   * The benefits of advertising the server type and version via this header are that it helps with analytics and identifying how widespread specific interoperability issues are.\n   * Historically, clients have used the server version information to avoid known limitations, such as inconsistent support for [range requests](/en-US/docs/Web/HTTP/Guides/Range_requests) in specific software versions.\n   *\n   * > [!WARNING]\n   * > The presence of this header in responses, especially when it contains fine-grained implementation details about server software, may make known vulnerabilities easier to detect.\n   *\n   * Too much detail in the `Server` header is not advised for response latency and the security reason mentioned above.\n   * It's debatable whether obscuring the information in this header provides much benefit because fingerprinting server software is possible via other means.\n   * In general, a more robust approach to server security is to ensure software is regularly updated or patched against known vulnerabilities instead.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Server: <product>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<product>`\n   *   - : A name of the software or the product that handled the request.\n   *     Usually in a format similar to .\n   *\n   * ## Examples\n   *\n   * ```http\n   * Server: Apache/2.4.1 (Unix)\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Allow](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Allow)\n   * - [HTTP Observatory](/en-US/observatory)\n   * - [Prevent information disclosure via HTTP headers](https://owasp.org/www-project-secure-headers/index.html#prevent-information-disclosure-via-http-headers) - OWASP Secure Headers Project\n   */\n  'Server' = 'Server',\n\n  /**\n   * The HTTP **`Service-Worker-Allowed`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used to broaden the path restriction for a service worker's default `scope`.\n   *\n   * By default, the [`scope`](/en-US/docs/Web/API/ServiceWorkerContainer/register#scope) for a service worker registration is the directory where the service worker script is located.\n   * For example, if the script `sw.js` is located in `/js/sw.js`, it can only control URLs under `/js/` by default.\n   * Servers can use the `Service-Worker-Allowed` header to allow a service worker to control URLs outside of its own directory.\n   *\n   * A service worker intercepts all network requests within its scope, so you should avoid using overly-broad scopes unless necessary.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Service-Worker-Allowed: <scope>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<scope>`\n   *   - : A string representing a URL that defines a service worker's registration scope; that is, what range of URLs a service worker can control.\n   *\n   * ## Examples\n   *\n   * ### Using Service-Worker-Allowed to broaden service worker scope\n   *\n   * The JavaScript example below is included in `example.com/product/index.html`, and attempts to [register](/en-US/docs/Web/API/ServiceWorkerContainer/register) a service worker with a scope that applies to all resources under `example.com/`.\n   *\n   * ```js\n   * navigator.serviceWorker.register(\"./sw.js\", { scope: \"/\" }).then(\n   *   (registration) => {\n   *     console.log(\"Install succeeded, scoped to '/'\", registration);\n   *   },\n   *   (error) => {\n   *     console.error(`Service worker registration failed: ${error}`);\n   *   },\n   * );\n   * ```\n   *\n   * The HTTP response to the service worker's script resource request (`./sw.js`) includes the `Service-Worker-Allowed` header set to `/`:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Date: Mon, 16 Dec 2024 14:37:20 GMT\n   * Service-Worker-Allowed: /\n   *\n   * // sw.js contents…\n   * ```\n   *\n   * If the server doesn't set the header, the service worker registration will fail, as the `scope` option (`{ scope: \"/\" }`) requests a scope broader than the directory where the service worker script is located (`/product/sw.js`).\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Service-Worker](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Service-Worker) header\n   * - [Service worker API](/en-US/docs/Web/API/Service_Worker_API)\n   * - [ServiceWorkerRegistration](https://developer.mozilla.org/en-US/docs/domxref/ServiceWorkerRegistration)\n   * - [Why is my service worker failing to register](/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#why_is_my_service_worker_failing_to_register) in _Using Service Workers_.\n   */\n  'Service-Worker-Allowed' = 'Service-Worker-Allowed',\n\n  /**\n   * The HTTP **`Service-Worker-Navigation-Preload`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) indicates that the request was the result of a [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch) operation made during service worker navigation preloading.\n   * It allows a server to respond with a different resource than for a normal `fetch()`.\n   *\n   * If a different response may result from setting this header, the server must include a [Vary: Service-Worker-Navigation-Preload](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header in responses to ensure that different responses are cached.\n   *\n   * For more information see [NavigationPreloadManager.setHeaderValue()](https://developer.mozilla.org/en-US/docs/domxref/NavigationPreloadManager.setHeaderValue()) (and [NavigationPreloadManager](https://developer.mozilla.org/en-US/docs/domxref/NavigationPreloadManager)).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Service-Worker-Navigation-Preload: <value>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<value>`\n   *   - : An arbitrary value that indicates what data should be sent in the response to the preload request.\n   *     This defaults to `true`.\n   *     It maybe set to any other string value in the service worker, using [NavigationPreloadManager.setHeaderValue()](https://developer.mozilla.org/en-US/docs/domxref/NavigationPreloadManager.setHeaderValue()).\n   *\n   * ## Examples\n   *\n   * ### Service worker navigation preloading headers\n   *\n   * The following request header is sent by default in navigation preload requests:\n   *\n   * ```http\n   * Service-Worker-Navigation-Preload: true\n   * ```\n   *\n   * The service worker can set a different header value using [NavigationPreloadManager.setHeaderValue()](https://developer.mozilla.org/en-US/docs/domxref/NavigationPreloadManager.setHeaderValue()).\n   * For example, in order to request that a fragment of the requested resource be returned in JSON format, the value could be set with the string `json_fragment1`.\n   *\n   * ```http\n   * Service-Worker-Navigation-Preload: json_fragment1\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Service Worker API](/en-US/docs/Web/API/Service_Worker_API)\n   */\n  'Service-Worker-Navigation-Preload' = 'Service-Worker-Navigation-Preload',\n\n  /**\n   * The HTTP **`Service-Worker`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is included in fetches for a service worker's script resource.\n   * This header helps administrators log service worker script requests for monitoring purposes.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Service-Worker: script\n   * ```\n   *\n   * ## Directives\n   *\n   * - `script`\n   *   - : A value indicating that this is a script.\n   *     This is the only allowed directive for this header.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Service-Worker-Allowed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Service-Worker-Allowed) header\n   * - [Service worker API](/en-US/docs/Web/API/Service_Worker_API)\n   */\n  'Service-Worker' = 'Service-Worker',\n\n  /**\n   * The HTTP **`Set-Cookie`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later.\n   * To send multiple cookies, multiple `Set-Cookie` headers should be sent in the same response.\n   *\n   * > [!WARNING]\n   * > Browsers block frontend JavaScript code from accessing the `Set-Cookie` header, as required by the Fetch spec, which defines `Set-Cookie` as a [forbidden response header name](https://fetch.spec.whatwg.org/#forbidden-response-header-name) that [must be filtered out](https://fetch.spec.whatwg.org/#ref-for-forbidden-response-header-name%E2%91%A0) from any response exposed to frontend code.\n   * >\n   * > When a [Fetch API](/en-US/docs/Web/API/Fetch_API/Using_Fetch) or [XMLHttpRequest API](/en-US/docs/Web/API/XMLHttpRequest_API) request [uses CORS](/en-US/docs/Web/HTTP/Guides/CORS#what_requests_use_cors), browsers will ignore `Set-Cookie` headers present in the server's response unless the request includes credentials. Visit [Using the Fetch API - Including credentials](/en-US/docs/Web/API/Fetch_API/Using_Fetch#including_credentials) and the [XMLHttpRequest article](/en-US/docs/Web/API/XMLHttpRequest_API) to learn how to include credentials.\n   *\n   * For more information, see the guide on [Using HTTP cookies](/en-US/docs/Web/HTTP/Guides/Cookies).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Set-Cookie: <cookie-name>=<cookie-value>\n   * Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>\n   * Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>\n   * Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly\n   * Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<number>\n   * Set-Cookie: <cookie-name>=<cookie-value>; Partitioned\n   * Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>\n   * Set-Cookie: <cookie-name>=<cookie-value>; Secure\n   *\n   * Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict\n   * Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax\n   * Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure\n   *\n   * // Multiple attributes are also possible, for example:\n   * Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly\n   * ```\n   *\n   * ## Attributes\n   *\n   * - `<cookie-name>=<cookie-value>`\n   *   - : Defines the cookie name and its value.\n   *     A cookie definition begins with a name-value pair.\n   *\n   *     A `<cookie-name>` can contain any US-ASCII characters except for: control characters ([ASCII](https://developer.mozilla.org/en-US/docs/Glossary/ASCII) characters 0 up to 31 and ASCII character 127) or separator characters (space, tab and the characters: `( ) < > @ , ; : \\ \" / [ ] ? = { }`)\n   *\n   *     A `<cookie-value>` can optionally be wrapped in double quotes and include any US-ASCII character excluding control characters (ASCII characters 0 up to 31 and ASCII character 127), [Whitespace](https://developer.mozilla.org/en-US/docs/glossary/Whitespace), double quotes, commas, semicolons, and backslashes.\n   *\n   *     **Encoding**: Many implementations perform [percent-encoding](https://developer.mozilla.org/en-US/docs/Glossary/Percent-encoding) on cookie values.\n   *     However, this is not required by the RFC specification.\n   *     The percent-encoding does help to satisfy the requirements of the characters allowed for `<cookie-value>`.\n   *\n   *     > [!NOTE]\n   *     > Some `<cookie-name>` have a specific semantic:\n   *     >\n   *     > **`__Secure-` prefix**: Cookies with names starting with `__Secure-` (dash is part of the prefix) must be set with the `secure` flag from a secure page (HTTPS).\n   *     >\n   *     > **`__Host-` prefix**: Cookies with names starting with `__Host-` are sent only to the host subdomain or domain that set them, and not to any other host.\n   *     > They must be set with the `secure` flag, must be from a secure page (HTTPS), must not have a domain specified, and the path must be `/`.\n   *\n   * - `Domain=<domain-value>`\n   *   - : Defines the host to which the cookie will be sent.\n   *\n   *     Only the current domain can be set as the value, or a domain of a higher order, unless it is a public suffix. Setting the domain will make the cookie available to it, as well as to all its subdomains.\n   *\n   *     If omitted, this attribute defaults to the host of the current document URL, not including subdomains.\n   *\n   *     Contrary to earlier specifications, leading dots in domain names (`.example.com`) are ignored.\n   *\n   *     Multiple host/domain values are _not_ allowed, but if a domain _is_ specified, then subdomains are always included.\n   *\n   * - `Expires=<date>`\n   *   - : Indicates the maximum lifetime of the cookie as an HTTP-date timestamp.\n   *     See [Date](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date) for the required formatting.\n   *\n   *     If unspecified, the cookie becomes a **session cookie**.\n   *     A session finishes when the client shuts down, after which\n   *     the session cookie is removed.\n   *\n   *     > [!WARNING]\n   *     > Many web browsers have a _session restore_ feature that will save all tabs and restore them the next time the browser is used. Session cookies will also be restored, as if the browser was never closed.\n   *\n   *     The `Expires` attribute is set by the server with a value relative to its own internal clock, which may differ from that of the client browser.\n   *     Firefox and Chromium-based browsers internally use an expiry (max-age) value that is adjusted to compensate for clock difference, storing and expiring cookies based on the time intended by the server.\n   *     The adjustment for clock skew is calculated from the value of the [DATE](https://developer.mozilla.org/en-US/docs/httpheader/DATE) header.\n   *     Note that the specification explains how the attribute should be parsed, but does not indicate if/how the value should be corrected by the recipient.\n   *\n   * - `HttpOnly`\n   *   - : Forbids JavaScript from accessing the cookie, for example, through the [Document.cookie](https://developer.mozilla.org/en-US/docs/domxref/Document.cookie) property.\n   *     Note that a cookie that has been created with `HttpOnly` will still be sent with JavaScript-initiated requests, for example, when calling [XMLHttpRequest.send()](https://developer.mozilla.org/en-US/docs/domxref/XMLHttpRequest.send()) or [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch).\n   *     This mitigates attacks against cross-site scripting ([XSS](https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting)).\n   *\n   * - `Max-Age=<number>`\n   *   - : Indicates the number of seconds until the cookie expires. A zero or negative number will expire the cookie immediately. If both `Expires` and `Max-Age` are set, `Max-Age` has precedence.\n   *\n   * - `Partitioned`\n   *   - : Indicates that the cookie should be stored using partitioned storage.\n   *     Note that if this is set, the [`Secure` directive](#secure) must also be set.\n   *     See [Cookies Having Independent Partitioned State (CHIPS)](/en-US/docs/Web/Privacy/Guides/Privacy_sandbox/Partitioned_cookies) for more details.\n   *\n   * - `Path=<path-value>`\n   *   - : Indicates the path that _must_ exist in the requested URL for the browser to send the `Cookie` header.\n   *\n   *     If omitted, this attribute defaults to the path component of the request URL. For example, if a cookie is set by a request to `https://example.com/docs/Web/HTTP/index.html`, the default path would be `/docs/Web/HTTP/`.\n   *\n   *     The forward slash (`/`) character is interpreted as a directory separator, and subdirectories are matched as well. For example, for `Path=/docs`,\n   *     - the request paths `/docs`, `/docs/`, `/docs/Web/`, and `/docs/Web/HTTP` will all match.\n   *     - the request paths `/`, `/docsets`, `/fr/docs` will not match.\n   *\n   *     > [!NOTE]\n   *     > The `path` attribute lets you control what cookies the browser sends based on the different parts of a site.\n   *     > It is not intended as a security measure, and [does not protect](/en-US/docs/Web/API/Document/cookie#security) against unauthorized reading of the cookie from a different path.\n   *\n   * - `SameSite=<samesite-value>`\n   *   - : Controls whether or not a cookie is sent with cross-site requests: that is, requests originating from a different [site](https://developer.mozilla.org/en-US/docs/glossary/site), including the scheme, from the site that set the cookie. This provides some protection against certain cross-site attacks, including [cross-site request forgery (CSRF)](https://developer.mozilla.org/en-US/docs/Glossary/CSRF) attacks.\n   *\n   *     The possible attribute values are:\n   *     - `Strict`\n   *       - : Send the cookie only for requests originating from the same [site](https://developer.mozilla.org/en-US/docs/glossary/site) that set the cookie.\n   *\n   *     - `Lax`\n   *       - : Send the cookie only for requests originating from the same [site](https://developer.mozilla.org/en-US/docs/glossary/site) that set the cookie, and for cross-site requests that meet both of the following criteria:\n   *         - The request is a top-level navigation: this essentially means that the request causes the URL shown in the browser's address bar to change.\n   *           - This would exclude, for example, requests made using the [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window.fetch()) API, or requests for subresources from [img](https://developer.mozilla.org/en-US/docs/htmlelement/img) or [script](https://developer.mozilla.org/en-US/docs/htmlelement/script) elements, or navigations inside [iframe](https://developer.mozilla.org/en-US/docs/htmlelement/iframe) elements.\n   *\n   *           - It would include requests made when the user clicks a link in the top-level browsing context from one site to another, or an assignment to [document.location](https://developer.mozilla.org/en-US/docs/domxref/Document.location), or a [form](https://developer.mozilla.org/en-US/docs/htmlelement/form) submission.\n   *\n   *         - The request uses a [safe](https://developer.mozilla.org/en-US/docs/glossary/Safe/HTTP) method: in particular, this excludes [POST](https://developer.mozilla.org/en-US/docs/httpmethod/POST), [PUT](https://developer.mozilla.org/en-US/docs/httpmethod/PUT), and [DELETE](https://developer.mozilla.org/en-US/docs/httpmethod/DELETE).\n   *\n   *         Some browsers use `Lax` as the default value if `SameSite` is not specified: see [Browser compatibility](#browser_compatibility) for details.\n   *\n   *         > [!NOTE]\n   *         > When `Lax` is applied as a default, a more permissive version is used. In this more permissive version, cookies are also included in [POST](https://developer.mozilla.org/en-US/docs/httpmethod/POST) requests, as long as they were set no more than two minutes before the request was made.\n   *\n   *     - `None`\n   *       - : Send the cookie with both cross-site and same-site requests.\n   *         The `Secure` attribute must also be set when using this value.\n   *\n   * - `Secure`\n   *   - : Indicates that the cookie is sent to the server only when a request is made with the `https:` scheme (except on localhost), and therefore, is more resistant to [man-in-the-middle](/en-US/docs/Glossary/MitM) attacks.\n   *\n   *     > [!NOTE]\n   *     > Do not assume that `Secure` prevents all access to sensitive information in cookies (session keys, login details, etc.).\n   *     > Cookies with this attribute can still be read/modified either with access to the client's hard disk or from JavaScript if the `HttpOnly` cookie attribute is not set.\n   *     >\n   *     > Insecure sites (`http:`) cannot set cookies with the `Secure` attribute. The `https:` requirements are ignored when the `Secure` attribute is set by localhost.\n   *\n   * ## Examples\n   *\n   * ### Session cookie\n   *\n   * Session cookies are removed when the client shuts down. Cookies are session cookies if they do not specify the `Expires` or `Max-Age` attribute.\n   *\n   * ```http\n   * Set-Cookie: sessionId=38afes7a8\n   * ```\n   *\n   * ### Permanent cookie\n   *\n   * Permanent cookies are removed at a specific date (`Expires`) or after a specific length of time (`Max-Age`) and not when the client is closed.\n   *\n   * ```http\n   * Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT\n   * ```\n   *\n   * ```http\n   * Set-Cookie: id=a3fWa; Max-Age=2592000\n   * ```\n   *\n   * ### Invalid domains\n   *\n   * A cookie for a domain that does not include the server that set it [should be rejected by the user agent](https://datatracker.ietf.org/doc/html/rfc6265#section-4.1.2.3).\n   *\n   * The following cookie will be rejected if set by a server hosted on `original-company.com`:\n   *\n   * ```http\n   * Set-Cookie: qwerty=219ffwef9w0f; Domain=some-company.co.uk\n   * ```\n   *\n   * A cookie for a subdomain of the serving domain will be rejected.\n   *\n   * The following cookie will be rejected if set by a server hosted on `example.com`:\n   *\n   * ```http\n   * Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com\n   * ```\n   *\n   * ### Cookie prefixes\n   *\n   * Cookie names prefixed with `__Secure-` or `__Host-` can be used only if they are set with the `secure` attribute from a secure (HTTPS) origin.\n   *\n   * In addition, cookies with the `__Host-` prefix must have a path of `/` (meaning any path at the host) and must not have a `Domain` attribute.\n   *\n   * > [!WARNING]\n   * > For clients that don't implement cookie prefixes, you cannot count on these additional assurances, and prefixed cookies will always be accepted.\n   *\n   * ```http\n   * // Both accepted when from a secure origin (HTTPS)\n   * Set-Cookie: __Secure-ID=123; Secure; Domain=example.com\n   * Set-Cookie: __Host-ID=123; Secure; Path=/\n   *\n   * // Rejected due to missing Secure attribute\n   * Set-Cookie: __Secure-id=1\n   *\n   * // Rejected due to the missing Path=/ attribute\n   * Set-Cookie: __Host-id=1; Secure\n   *\n   * // Rejected due to setting a Domain\n   * Set-Cookie: __Host-id=1; Secure; Path=/; Domain=example.com\n   * ```\n   *\n   * ### Partitioned cookie\n   *\n   * ```http\n   * Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;\n   * ```\n   *\n   * > [!NOTE]\n   * > Partitioned cookies must be set with `Secure`. In addition, it is recommended to use the `__Host` prefix when setting partitioned cookies to make them bound to the hostname and not the registrable domain.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTTP cookies](/en-US/docs/Web/HTTP/Guides/Cookies)\n   * - [Cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie)\n   * - [Document.cookie](https://developer.mozilla.org/en-US/docs/domxref/Document.cookie)\n   * - [Samesite cookies explained](https://web.dev/articles/samesite-cookies-explained) (web.dev blog)\n   */\n  'Set-Cookie' = 'Set-Cookie',\n\n  /**\n   * The HTTP **`Set-Login`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is sent by a federated identity provider (IdP) to set its login status, and indicates whether any users are logged into the IdP on the current browser or not.\n   * This is stored by the browser and used by the [FedCM API](/en-US/docs/Web/API/FedCM_API) to reduce the number of requests it makes to the IdP as the browser doesn't need to request accounts when there are no users logged in to the IdP.\n   * It also mitigates [potential timing attacks](https://github.com/w3c-fedid/FedCM/issues/447).\n   *\n   * The header may be set on any response resulting from a top-level navigation or a same-origin subresource request on the IdP's origin site.\n   * Any interaction with the IdP site may result in this header being set, and the login status being stored by the browser.\n   *\n   * See [Update login status using the Login Status API](/en-US/docs/Web/API/FedCM_API/IDP_integration#update_login_status_using_the_login_status_api) for more information about FedCM login status.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Set-Login: <status>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<status>`\n   *   - : A string representing the login status to set for the IdP. Possible values are:\n   *     - `logged-in`: The IdP has at least one user account signed in.\n   *     - `logged-out`: All IdP user accounts are currently signed out.\n   *\n   *     > [!NOTE]\n   *     > Browsers ignore this header if it contains any other value.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Set-Login: logged-in\n   *\n   * Set-Login: logged-out\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Federated Credential Management (FedCM) API](/en-US/docs/Web/API/FedCM_API)\n   */\n  'Set-Login' = 'Set-Login',\n\n  /**\n   * The HTTP **`SourceMap`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) provides the location of a [source map](https://developer.mozilla.org/en-US/docs/Glossary/source_map) for the resource.\n   *\n   * The HTTP `SourceMap` header has precedence over a source annotation (`sourceMappingURL=path-to-map.js.map`), and if both are present, the header URL is used to resolve the source map file.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * SourceMap: <url>\n   * X-SourceMap: <url> (deprecated)\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<url>`\n   *   - : A relative (to the request URL) or absolute URL pointing to a source map file.\n   *\n   * ## Examples\n   *\n   * ### Linking to a source map using the `SourceMap` header\n   *\n   * The following response contains an absolute path in the `SourceMap` header.\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Type: text/javascript\n   * SourceMap: /path/to/file.js.map\n   *\n   * <optimized-javascript>\n   * ```\n   *\n   * Developer tools use the source map to reconstruct the original source from the optimized JavaScript returned in the response, allowing developers to debug the original code rather than the format that has been optimized for sending.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Source map](https://developer.mozilla.org/en-US/docs/Glossary/Source_map)\n   * - [Firefox Developer Tools: using a source map](https://firefox-source-docs.mozilla.org/devtools-user/debugger/how_to/use_a_source_map/index.html)\n   * - [What are source maps?](https://web.dev/articles/source-maps) on web.dev (2023)\n   */\n  'SourceMap' = 'SourceMap',\n\n  /**\n   * The HTTP **`Speculation-Rules`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) provides one or more URLs pointing to text resources containing speculation rule JSON definitions. When the response is an HTML document, these rules will be added to the document's speculation rule set. See the [Speculation Rules API](/en-US/docs/Web/API/Speculation_Rules_API) for more information.\n   *\n   * The resource file containing the speculation rules JSON can have any valid name and extension, but it will be requested with a [`destination`](/en-US/docs/Web/API/Request/destination) type of [`speculationrules`](/en-US/docs/Web/API/Request/destination#speculationrules), and must be served with an `application/speculationrules+json` MIME type.\n   *\n   * > [!NOTE]\n   * > This mechanism provides an alternative to specifying the JSON definition inside an inline [`\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Speculation-Rules: <url-list>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<url-list>`\n   *   - : A comma-separated list of URLs pointing to text resources containing speculation rule JSON definitions. The JSON contained in the text files must follow the same rules as that contained inside inline `<script type=\"speculationrules\">` elements. See [Speculation rules JSON representation](/en-US/docs/Web/HTML/Reference/Elements/script/type/speculationrules#speculation_rules_json_representation) for the syntax reference.\n   *\n   * ## Examples\n   *\n   * ### Speculation-Rules field with a single file\n   *\n   * The following response contains one file reference:\n   *\n   * ```http\n   * Speculation-Rules: \"/rules/prefetch.json\"\n   * ```\n   *\n   * ### Speculation-Rules field with multiple files\n   *\n   * The following response contains multiple file reference as a comma-separated list:\n   *\n   * ```http\n   * Speculation-Rules: \"/rules/prefetch.json\",\"/rules/prerender.json\"\n   * ```\n   *\n   * > [!NOTE]\n   * > The URL values must be contained in quotes.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Speculation Rules API](/en-US/docs/Web/API/Speculation_Rules_API)\n   * - [`<script type=\"speculationrules\">`](/en-US/docs/Web/HTML/Reference/Elements/script/type/speculationrules)\n   */\n  'Speculation-Rules' = 'Speculation-Rules',\n\n  /**\n   * The HTTP **`Strict-Transport-Security`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) (often abbreviated as [HSTS](https://developer.mozilla.org/en-US/docs/Glossary/HSTS)) informs browsers that the [host](https://developer.mozilla.org/en-US/docs/Glossary/host) should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be upgraded to HTTPS.\n   * Additionally, on future connections to the host, the browser will not allow the user to bypass secure connection errors, such as an invalid certificate.\n   * HSTS identifies a host by its domain name only.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Strict-Transport-Security: max-age=<expire-time>\n   * Strict-Transport-Security: max-age=<expire-time>; includeSubDomains\n   * Strict-Transport-Security: max-age=<expire-time>; includeSubDomains; preload\n   * ```\n   *\n   * ## Directives\n   *\n   * - `max-age=<expire-time>`\n   *   - : The time, in seconds, that the browser should remember that a host is only to be accessed using HTTPS.\n   * - `includeSubDomains`\n   *   - : If this directive is specified, the HSTS policy applies to all subdomains of the host's domain as well.\n   * - `preload`\n   *   - : See [Preloading Strict Transport Security](#preloading_strict_transport_security) for details. When using `preload`, the `max-age` directive must be at least `31536000` (1 year), and the `includeSubDomains` directive must be present.\n   *\n   * ## Description\n   *\n   * The `Strict-Transport-Security` header informs the browser that all connections to the host must use HTTPS.\n   * Although it is a response header, it does not affect how the browser handles the current response, but rather\n   * how it makes future requests.\n   *\n   * When an HTTPS response includes the `Strict-Transport-Security` header, the browser adds the host's domain name\n   * to its persistent list of HSTS hosts.\n   * If the domain name is already in the list, the expiration time and `includeSubDomains` directive are updated.\n   * The host is identified only by its domain name. An IP address cannot be an HSTS host.\n   * HSTS applies to all ports of the host, regardless of what port was used for the request.\n   *\n   * Before loading an `http` URL, the browser checks the domain name against its HSTS hosts list.\n   * If the domain name is a case insensitive match for an HSTS host or is a subdomain of one that specified `includeSubDomains`,\n   * then the browser replaces the URL scheme with `https`.\n   * If the URL specifies port 80, the browser changes it to 443.\n   * Any other explicit port number remains unchanged, and the browser connects to that port using HTTPS.\n   *\n   * If a TLS warning or error, such as an invalid certificate, occurs when connecting to an HSTS host,\n   * the browser does not offer the user a way to proceed or \"click through\" the error message, which would compromise\n   * the intention of strict security.\n   *\n   * > [!NOTE]\n   * > The host must send the `Strict-Transport-Security` header over HTTPS only, not insecure HTTP.\n   * > Browsers ignore the header if sent over HTTP to prevent a [manipulator-in-the-middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM)\n   * > from altering the header to expire prematurely or adding it for a host that doesn't support HTTPS.\n   *\n   * ### Expiration\n   *\n   * Every time the browser receives a `Strict-Transport-Security` header, it updates the host's HSTS expiration time by\n   * adding `max-age` to the current time.\n   * Using a fixed value for `max-age` can prevent HSTS from expiring, as each subsequent response will push the expiration farther into the future.\n   *\n   * If the `Strict-Transport-Security` header is missing in a response from a host that previously sent one, the previous header remains in effect until its expiration time.\n   *\n   * To disable HSTS, set `max-age=0`.\n   * This only takes effect once the browser makes a secure request and receives the response header.\n   * By design, you cannot disable HSTS over insecure HTTP.\n   *\n   * ### Subdomains\n   *\n   * The `includeSubDomains` directive instructs the browser to apply a domain's HSTS policy to its subdomains as well.\n   * An HSTS policy for `secure.example.com` with `includeSubDomains` also applies to `login.secure.example.com`\n   * and `admin.login.secure.example.com`. But it does not apply to `example.com` or `insecure.example.com`.\n   *\n   * Each subdomain host should include `Strict-Transport-Security` headers in its responses even if the\n   * superdomain uses `includeSubDomains`, because a browser may contact a subdomain host before the superdomain.\n   * For example, if `example.com` includes the HSTS header with `includeSubDomains`, but all existing links\n   * go directly to `www.example.com`, the browser will never see `example.com`'s HSTS header.\n   * Therefore, `www.example.com` also should send HSTS headers.\n   *\n   * The browser stores the HSTS policy for each domain and subdomain independently, regardless of the `includeSubDomains` directive.\n   * If both `example.com` and `login.example.com` send HSTS headers, the browser stores two separate HSTS policies,\n   * and they can expire independently. If `example.com` used `includeSubDomains`, then `login.example.com` remains covered\n   * if either one of the policies expires.\n   *\n   * If `max-age=0`, `includeSubDomains` has no effect, since the domain that specified `includeSubDomains` is\n   * immediately deleted from the HSTS hosts list; this does not delete separate HSTS policies of each subdomain.\n   *\n   * ### Insecure HTTP requests\n   *\n   * If the host accepts insecure HTTP requests, it should respond with a permanent redirect (such as status code [301](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301))\n   * having an `https` URL in the [Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location) header.\n   * The redirect must not include the `Strict-Transport-Security` header since the request used insecure HTTP\n   * but the header must be sent via HTTPS only.\n   * After the browser follows the redirect and makes a new request using HTTPS, the response\n   * should include the `Strict-Transport-Security` header to ensure that future attempts to load an `http` URL\n   * will use HTTPS immediately, without requiring a redirect.\n   *\n   * One weakness of HSTS is that it does not take effect until the browser has made at least one secure connection to the host\n   * and received the `Strict-Transport-Security` header.\n   * If the browser loads an insecure `http` URL prior to knowing that the host is an HSTS host, the initial request is\n   * vulnerable to network attacks.\n   * [Preloading](#preloading_strict_transport_security) mitigates this problem.\n   *\n   * ### Strict Transport Security example scenario\n   *\n   * 1. At home, the user visits `http://example.com/` for the first time.\n   * 2. Since the URL scheme is `http` and the browser does not have it in its HSTS hosts list, the connection uses insecure HTTP.\n   * 3. The server responds with a `301 Moved Permanently` redirect to `https://example.com/`.\n   * 4. The browser makes a new request, this time using HTTPS.\n   * 5. The response, made via HTTPS, includes the header:\n   *\n   *    ```http\n   *    Strict-Transport-Security: max-age=31536000; includeSubDomains\n   *    ```\n   *\n   *    The browser remembers `example.com` as an HSTS host, and that it specified `includeSubDomains`.\n   *\n   * 6. A few weeks later, the user is at the airport and decides to use the free Wi-Fi. But unknowingly, they connect to a rogue access point running on an attacker's laptop.\n   * 7. The user opens `http://login.example.com/`. Because the browser remembers `example.com` as an HSTS host and the `includeSubDomains` directive was used, the browser uses HTTPS.\n   * 8. The attacker intercepts the request with a fake HTTPS server, but does not have a valid certificate for the domain.\n   * 9. The browser displays an invalid certificate error, and does not allow the user to bypass it, thus preventing them from giving their password to the attacker.\n   *\n   * ### Preloading Strict Transport Security\n   *\n   * Google maintains [an HSTS preload service](https://hstspreload.org/).\n   * By following the guidelines and successfully submitting your domain, you can ensure that browsers will connect to your domain only via secure connections.\n   * While the service is hosted by Google, all browsers are using this preload list.\n   * However, it is not part of the HSTS specification and should not be treated as official.\n   *\n   * - Information regarding the HSTS preload list in Chrome: https://www.chromium.org/hsts/\n   * - Consultation of the Firefox HSTS preload list: [nsSTSPreloadList.inc](https://searchfox.org/mozilla-central/source/security/manager/ssl/nsSTSPreloadList.inc)\n   *\n   * ## Examples\n   *\n   * ### Using Strict-Transport-Security\n   *\n   * All present and future subdomains will be HTTPS for a `max-age` of 1 year.\n   * This blocks access to pages or subdomains that can only be served over HTTP.\n   *\n   * ```http\n   * Strict-Transport-Security: max-age=31536000; includeSubDomains\n   * ```\n   *\n   * Although a `max-age` of 1 year is acceptable for a domain, two years is the recommended value as explained on https://hstspreload.org.\n   *\n   * In the following example, `max-age` is set to 2 years, and is suffixed with `preload`, which is necessary for inclusion in all major web browsers' HSTS preload lists, like Chromium, Edge, and Firefox.\n   *\n   * ```http\n   * Strict-Transport-Security: max-age=63072000; includeSubDomains; preload\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Features restricted to secure contexts](/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts)\n   * - [HTTP Strict Transport Security has landed!](https://blog.sidstamm.com/2010/08/http-strict-transport-security-has.html) on blog.sidstamm.com (2010)\n   * - [HTTP Strict Transport Security (force HTTPS)](https://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-force-https/) on hacks.mozilla.org (2010)\n   * - [HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) cheatsheet on owasp.org\n   * - [HTTP Strict Transport Security](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) on Wikipedia\n   * - [HSTS preload service](https://hstspreload.org/)\n   */\n  'Strict-Transport-Security' = 'Strict-Transport-Security',\n\n  /**\n   * The HTTP **`Supports-Loading-Mode`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) allows a response to opt-in to being loaded in a novel, higher-risk context that it would otherwise fail to be loaded in.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Supports-Loading-Mode: <client-hint-headers>\n   * ```\n   *\n   * ## Directives\n   *\n   * The `Supports-Loading-Mode` header value is a list of one or more tokens, which can include the following values:\n   *\n   * - `credentialed-prerender`\n   *   - : Indicates that a destination origin opts in to loading documents via cross-origin, same-site [prerendering](/en-US/docs/Web/API/Speculation_Rules_API#using_prerendering).\n   * - `fenced-frame`\n   *   - : The response can loaded inside a [fenced frame](/en-US/docs/Web/API/Fenced_frame_API). Without this explicit opt-in, all navigations inside of a fenced frame will fail.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Supports-Loading-Mode: fenced-frame\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Fenced Frame API](/en-US/docs/Web/API/Fenced_frame_API)\n   * - [Speculation Rules API](/en-US/docs/Web/API/Speculation_Rules_API)\n   * - [Speculative loading](/en-US/docs/Web/Performance/Guides/Speculative_loading)\n   * - [Prerender pages in Chrome for instant page navigations](https://developer.chrome.com/docs/web-platform/prerender-pages) on developer.chrome.com\n   */\n  'Supports-Loading-Mode' = 'Supports-Loading-Mode',\n\n  /**\n   * The HTTP **`TE`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) specifies the transfer encodings the user agent is willing to accept.\n   * The transfer encodings are for message compression and chunking of data during transmission.\n   *\n   * Transfer encodings are applied at the protocol layer, so an application consuming responses receives the body as if no encoding was applied.\n   *\n   * > [!NOTE]\n   * > In [HTTP/2](https://httpwg.org/specs/rfc9113.html#ConnectionSpecific) and [HTTP/3](https://httpwg.org/specs/rfc9114.html#header-formatting), the `TE` header field is only accepted if the `trailers` value is set.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * TE: compress\n   * TE: deflate\n   * TE: gzip\n   * TE: trailers\n   * ```\n   *\n   * Multiple directives in a comma-separated list with [quality values](https://developer.mozilla.org/en-US/docs/glossary/quality_values) as weights:\n   *\n   * ```http\n   * TE: trailers, deflate;q=0.5\n   * ```\n   *\n   * ## Directives\n   *\n   * - `compress`\n   *   - : A format using the [Lempel-Ziv-Welch](https://en.wikipedia.org/wiki/LZW) (LZW) algorithm is accepted as a transfer coding name.\n   * - `deflate`\n   *   - : Using the [zlib](https://en.wikipedia.org/wiki/Zlib) structure is accepted as a transfer coding name.\n   * - `gzip`\n   *   - : A format using the [Lempel-Ziv coding](https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) (LZ77), with a 32-bit CRC is accepted as a transfer coding name.\n   * - `trailers`\n   *   - : Indicates that the client will not discard trailer fields in a [chunked transfer coding](/en-US/docs/Web/HTTP/Reference/Headers/Transfer-Encoding#chunked).\n   * - `q`\n   *   - : When multiple transfer codings are acceptable, the `q` parameter ([quality values](https://developer.mozilla.org/en-US/docs/glossary/quality_values)) syntax orders codings by preference.\n   *\n   * Note that `chunked` is always supported by HTTP/1.1 recipients, so you don't need to specify it using the `TE` header.\n   * See the [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding) header for more details.\n   *\n   * ## Examples\n   *\n   * ### Using the TE header with quality values\n   *\n   * In the following request, the client indicates a preference for `gzip`-encoded responses with `deflate` as a second preference using a `q` value:\n   *\n   * ```http\n   * GET /resource HTTP/1.1\n   * Host: example.com\n   * TE: gzip; q=1.0, deflate; q=0.8\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding)\n   * - [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding)\n   * - [Trailer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer)\n   * - [Chunked transfer encoding](https://en.wikipedia.org/wiki/Chunked_transfer_encoding)\n   */\n  'TE' = 'TE',\n\n  /**\n   * The HTTP **`Timing-Allow-Origin`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) specifies origins that are allowed to see values of attributes retrieved via features of the [Resource Timing API](/en-US/docs/Web/API/Performance_API/Resource_timing), which would otherwise be reported as zero due to cross-origin restrictions.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Timing-Allow-Origin: *\n   * Timing-Allow-Origin: <origin>, …, <originN>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `*` (wildcard)\n   *   - : Any origin may see timing resources.\n   * - `<origin>`\n   *   - : Specifies a URI that may see the timing resources. You can specify multiple origins, separated by commas.\n   *\n   * ## Examples\n   *\n   * ### Using Timing-Allow-Origin\n   *\n   * To allow any resource to see timing resources:\n   *\n   * ```http\n   * Timing-Allow-Origin: *\n   * ```\n   *\n   * To allow `https://developer.mozilla.org` to see timing resources, you can specify:\n   *\n   * ```http\n   * Timing-Allow-Origin: https://developer.mozilla.org\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Resource Timing API](/en-US/docs/Web/API/Performance_API/Resource_timing)\n   * - [Server-Timing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing) header\n   * - [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   */\n  'Timing-Allow-Origin' = 'Timing-Allow-Origin',\n\n  /**\n   * > [!NOTE]\n   * > The DNT (Do Not Track) specification has been discontinued. See [Navigator.doNotTrack](https://developer.mozilla.org/en-US/docs/domxref/Navigator.doNotTrack) for more information.\n   * > An alternative is [Global Privacy Control](https://globalprivacycontrol.org/), which is communicated to servers using the [Sec-GPC](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-GPC) header, and accessible to clients from [navigator.globalPrivacyControl](https://developer.mozilla.org/en-US/docs/domxref/navigator.globalPrivacyControl).\n   *\n   * The HTTP **`Tk`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates the tracking status that applied to the corresponding request.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Tk: !  (under construction)\n   * Tk: ?  (dynamic)\n   * Tk: G  (gateway or multiple parties)\n   * Tk: N  (not tracking)\n   * Tk: T  (tracking)\n   * Tk: C  (tracking with consent)\n   * Tk: P  (potential consent)\n   * Tk: D  (disregarding DNT)\n   * Tk: U  (updated)\n   * ```\n   *\n   * ### Directives\n   *\n   * - `!`\n   *   - : Under construction. The origin server is currently testing its communication of\n   *     tracking status.\n   * - `?`\n   *   - : Dynamic. The origin server needs more information to determine tracking status.\n   * - `G`\n   *   - : Gateway or multiple parties. The server is acting as a gateway to an exchange\n   *     involving multiple parties.\n   * - `N`\n   *   - : Not tracking.\n   * - `T`\n   *   - : Tracking.\n   * - `C`\n   *   - : Tracking with consent. The origin server believes it has received prior consent for\n   *     tracking this user, user agent, or device.\n   * - `P`\n   *   - : Potential consent. The origin server does not know, in real-time, whether it has\n   *     received prior consent for tracking this user, user agent, or device, but promises not\n   *     to use or share any `DNT:1` data until such consent has been determined,\n   *     and further promises to delete or permanently de-identify within 48 hours any\n   *     `DNT:1` data received for which such consent has not been received.\n   * - `D`\n   *   - : Disregarding DNT. The origin server is unable or unwilling to respect a tracking\n   *     preference received from the requesting user agent.\n   * - `U`\n   *   - : Updated. The request resulted in a potential change to the tracking status\n   *     applicable to this user, user agent, or device.\n   *\n   * ## Examples\n   *\n   * A `Tk` header for a resource that claims not to be tracking would look like:\n   *\n   * ```http\n   * Tk: N\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## See also\n   *\n   * - [DNT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DNT) header\n   * - [Navigator.doNotTrack](https://developer.mozilla.org/en-US/docs/domxref/Navigator.doNotTrack)\n   * - [Do Not Track on Wikipedia](https://en.wikipedia.org/wiki/Do_Not_Track)\n   * - [What Does the \"Track\" in \"Do Not Track\" Mean? – EFF](https://www.eff.org/deeplinks/2011/02/what-does-track-do-not-track-mean)\n   * - [DNT on Electronic Frontier Foundation](https://www.eff.org/issues/do-not-track)\n   * - [GPC - Global Privacy Control](https://globalprivacycontrol.org/)\n   *   - [Enabling GPC in Firefox](https://support.mozilla.org/en-US/kb/global-privacy-control?as=u&utm_source=inproduct)\n   */\n  'Tk' = 'Tk',\n\n  /**\n   * The HTTP **Trailer** [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) allows the sender to include additional fields at the end of chunked messages in order to supply metadata that might be dynamically generated while the message body is sent.\n   *\n   * > [!NOTE]\n   * > The [TE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/TE) request header needs to be set to `trailers` to allow trailer fields.\n   *\n   * > [!WARNING]\n   * > Developers cannot access HTTP trailers via the Fetch API or XHR.\n   * > Additionally, browsers ignore HTTP trailers, with the exception of [Server-Timing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing).\n   * > See [Browser compatibility](#browser_compatibility) for more information.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Trailer: header-names\n   * ```\n   *\n   * ## Directives\n   *\n   * - `header-names`\n   *   - : HTTP header fields which will be present in the trailer part of chunked messages.\n   *     The following header names are **disallowed**:\n   *     - [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding), [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type), [Content-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range), and `Trailer`\n   *     - Authentication headers (e.g., [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) or [Set-Cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie))\n   *     - Message framing headers (e.g., [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding) and [Content-Length](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length))\n   *     - Routing headers (e.g., [Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host))\n   *     - Request modifiers (e.g., controls and conditionals, like [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control), [Max-Forwards](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Max-Forwards), or [TE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/TE))\n   *\n   * ## Examples\n   *\n   * ### Server-Timing as HTTP trailer\n   *\n   * Some browsers support showing server timing data in developer tools when the [Server-Timing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing) header is sent as a trailer.\n   * In the following response, the `Trailer` header is used to indicate that a `Server-Timing` header will follow the response body.\n   * A metric `custom-metric` with a duration of `123.4` milliseconds is sent:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Transfer-Encoding: chunked\n   * Trailer: Server-Timing\n   *\n   * --- response body ---\n   * Server-Timing: custom-metric;dur=123.4\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Server-Timing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing)\n   * - [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding)\n   * - [TE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/TE)\n   * - [Chunked transfer encoding](https://en.wikipedia.org/wiki/Chunked_transfer_encoding)\n   */\n  'Trailer' = 'Trailer',\n\n  /**\n   * The HTTP **`Transfer-Encoding`** [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) specifies the form of encoding used to transfer messages between nodes on the network.\n   *\n   * `Transfer-Encoding` is a [hop-by-hop header](/en-US/docs/Web/HTTP/Reference/Headers#hop-by-hop_headers), that is applied to a message between two nodes, not to a resource itself.\n   * Each segment of a multi-node connection can use different `Transfer-Encoding` values.\n   * If you want to compress data over the whole connection, use the end-to-end [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) header instead.\n   *\n   * In practice this header is rarely used, and in those cases it is almost always used with `chunked`.\n   *\n   * That said, the specification indicates that when present in a message it indicates the compression used on the message in that hop, and/or whether the message has been chunked.\n   * For example, `Transfer-Encoding: gzip, chunked` indicates that the content has been compressed using the gzip coding and then chunked using the chunked coding while forming the message body.\n   *\n   * The header is optional in responses to a [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD) request as these messages have no body and, therefore, no transfer encoding.\n   * When present it indicates the value that would have applied to the corresponding response to a [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) message, if that `GET` request did not include a preferred `Transfer-Encoding`.\n   *\n   * > [!WARNING]\n   * > HTTP/2 disallows all uses of the `Transfer-Encoding` header.\n   * > HTTP/2 and later provide more efficient mechanisms for data streaming than chunked transfer.\n   * > Usage of the header in HTTP/2 may likely result in a specific `protocol error`.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Transfer-Encoding: chunked\n   * Transfer-Encoding: compress\n   * Transfer-Encoding: deflate\n   * Transfer-Encoding: gzip\n   *\n   * // Several values can be listed, separated by a comma\n   * Transfer-Encoding: gzip, chunked\n   * ```\n   *\n   * ## Directives\n   *\n   * - `chunked`\n   *   - : Data is sent in a series of chunks.\n   *     Content can be sent in streams of unknown size to be transferred as a sequence of length-delimited buffers, so the sender can keep a connection open, and let the recipient know when it has received the entire message.\n   *     The [Content-Length](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length) header must be omitted, and at the beginning of each chunk, a string of hex digits indicate the size of the chunk-data in octets, followed by `\\r\\n` and then the chunk itself, followed by another `\\r\\n`.\n   *     The terminating chunk is a zero-length chunk.\n   * - `compress`\n   *   - : A format using the [Lempel-Ziv-Welch](https://en.wikipedia.org/wiki/LZW) (LZW) algorithm.\n   *     The value name was taken from the UNIX _compress_ program, which implemented this algorithm.\n   *     Like the compress program, which has disappeared from most UNIX distributions, this content-encoding is used by almost no browsers today, partly because of a patent issue (which expired in 2003).\n   * - `deflate`\n   *   - : Using the [zlib](https://en.wikipedia.org/wiki/Zlib) structure (defined in [RFC 1950](https://datatracker.ietf.org/doc/html/rfc1950)), with the [_deflate_](https://en.wikipedia.org/wiki/DEFLATE) compression algorithm (defined in [RFC 1951](https://datatracker.ietf.org/doc/html/rfc1952)).\n   * - `gzip`\n   *   - : A format using the [Lempel-Ziv coding](https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) (LZ77), with a 32-bit CRC.\n   *     This is originally the format of the UNIX _gzip_ program.\n   *     The HTTP/1.1 standard also recommends that the servers supporting this content-encoding should recognize `x-gzip` as an alias, for compatibility purposes.\n   *\n   * ## Examples\n   *\n   * ### Response with chunked encoding\n   *\n   * Chunked encoding is useful when larger amounts of data are sent to the client and the total size of the response may not be known until the request has been fully processed.\n   * For example, when generating a large HTML table resulting from a database query or when transmitting large images.\n   * A chunked response looks like this:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Content-Type: text/plain\n   * Transfer-Encoding: chunked\n   *\n   * 7\\r\\n\n   * Mozilla\\r\\n\n   * 11\\r\\n\n   * Developer Network\\r\\n\n   * 0\\r\\n\n   * \\r\\n\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Accept-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding)\n   * - [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding)\n   * - [Content-Length](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length)\n   * - [Chunked transfer encoding](https://en.wikipedia.org/wiki/Chunked_transfer_encoding)\n   */\n  'Transfer-Encoding' = 'Transfer-Encoding',\n\n  /**\n   * The HTTP **`Upgrade-Insecure-Requests`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) sends a signal to the server indicating the client's preference for an encrypted and authenticated response, and that the client can successfully handle the [upgrade-insecure-requests](https://developer.mozilla.org/en-US/docs/CSP/upgrade-insecure-requests) [CSP](/en-US/docs/Web/HTTP/Guides/CSP) directive.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Upgrade-Insecure-Requests: <boolean>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<boolean>`\n   *   - : `1` indicates 'true' and is the only valid value for this field.\n   *\n   * ## Examples\n   *\n   * ### Using Upgrade-Insecure-Requests\n   *\n   * A client's request signals to the server that it supports the upgrade mechanisms of [upgrade-insecure-requests](https://developer.mozilla.org/en-US/docs/CSP/upgrade-insecure-requests):\n   *\n   * ```http\n   * GET / HTTP/1.1\n   * Host: example.com\n   * Upgrade-Insecure-Requests: 1\n   * ```\n   *\n   * The server can now redirect to a secure version of the site. A [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header can be used so that the site isn't served by caches to clients that don't support the upgrade mechanism.\n   *\n   * ```http\n   * Location: https://example.com/\n   * Vary: Upgrade-Insecure-Requests\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)\n   * - CSP [upgrade-insecure-requests](https://developer.mozilla.org/en-US/docs/CSP/upgrade-insecure-requests) directive\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   */\n  'Upgrade-Insecure-Requests' = 'Upgrade-Insecure-Requests',\n\n  /**\n   * The HTTP `Upgrade` [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) can be used to upgrade an already-established client/server connection to a different protocol (over the same transport protocol).\n   * For example, it can be used by a client to upgrade a connection from HTTP/1.1 to HTTP/2, or an HTTP(S) connection to a WebSocket connection.\n   *\n   * > [!WARNING]\n   * > HTTP/2 explicitly disallows the use of this mechanism and header; it is specific to HTTP/1.1.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Upgrade: <protocol>[/<protocol_version>]\n   * Upgrade: <protocol>[/<protocol_version>], …, <protocolN>[/<protocol_versionN>]\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<protocol>`\n   *   - : Protocols are listed, comma-separated, in order of descending preference.\n   * - `<protocol_version>`\n   *   - : An optional protocol version may be provided prefixed with a `/` forward slash.\n   *\n   * ## Description\n   *\n   * The `Upgrade` header field may be used by clients to invite a server to switch to one (or more) of the listed protocols, in descending preference order.\n   * For example, the client might send a `GET` request as shown, listing the preferred protocols to switch to (in this case `example/1` and `foo/2`):\n   *\n   * ```http\n   * GET /index.html HTTP/1.1\n   * Host: www.example.com\n   * Connection: upgrade\n   * Upgrade: example/1, foo/2\n   * ```\n   *\n   * > [!NOTE]\n   * > The [Connection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection) header with type `upgrade` must _always_ be sent with the `Upgrade` header.\n   *\n   * The server can ignore the request, for any reason, in which case it should respond as though the `Upgrade` header had not been sent (for example, with a ).\n   * If the server will upgrade the connection, it must:\n   *\n   * 1. Send back a  response status with an `Upgrade` header that specifies the protocol(s) being switched to. For example:\n   *\n   *    ```http\n   *    HTTP/1.1 101 Switching Protocols\n   *    Upgrade: foo/2\n   *    Connection: Upgrade\n   *    ```\n   *\n   * 2. Send a response to the original request _using the new protocol_ (the server may only switch to a protocol with which it can complete the original request).\n   *\n   * A server may also send the header as part of a [426](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/426) `Upgrade Required` response, to indicate that the server won't perform the request using the current protocol, but might do so if the protocol is changed. The client can then request a protocol change using the process above.\n   *\n   * More detail and examples are provided in the topic [Protocol upgrade mechanism](/en-US/docs/Web/HTTP/Guides/Protocol_upgrade_mechanism).\n   *\n   * ## Examples\n   *\n   * ### Upgrade header with multiple protocols\n   *\n   * The following request lists multiple protocols in descending preference:\n   *\n   * ```http\n   * Connection: upgrade\n   * Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11\n   * ```\n   *\n   * ### Upgrading to WebSocket\n   *\n   * This is a common combination of headers to use to begin upgrading a HTTP connection to WebSockets.\n   * See [Upgrading to a WebSocket connection](/en-US/docs/Web/HTTP/Guides/Protocol_upgrade_mechanism#upgrading_to_a_websocket_connection) for more information.\n   *\n   * ```http\n   * Connection: Upgrade\n   * Upgrade: websocket\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Protocol upgrade mechanism](/en-US/docs/Web/HTTP/Guides/Protocol_upgrade_mechanism)\n   * -\n   * -\n   * - [Connection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection)\n   */\n  'Upgrade' = 'Upgrade',\n\n  /**\n   * The HTTP **`Use-As-Dictionary`** response header lists the matching criteria that the [Compression Dictionary Transport](https://developer.mozilla.org/en-US/docs/glossary/Compression_Dictionary_Transport) dictionary can be used for, for future requests.\n   *\n   * See the [Compression Dictionary Transport guide](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport) for more information.\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Use-As-Dictionary: match=\"<url-pattern>\"\n   * Use-As-Dictionary: match-dest=(\"<destination1>\" \"<destination2>\", …)\n   * Use-As-Dictionary: id=\"<string-identifier>\"\n   * Use-As-Dictionary: type=\"raw\"\n   *\n   * // Multiple, in any order\n   * Content-Encoding: match=\"<url-pattern>\", match-dest=(\"<destination1>\")\n   * ```\n   *\n   * ## Directives\n   *\n   * - `match`\n   *   - : A string value containing a [URL Pattern](/en-US/docs/Web/API/URL_Pattern_API): only resources whose URLs match this pattern may use this resource as a dictionary. Regular expression capturing groups are not allowed, so [URLPattern.hasRegExpGroups](https://developer.mozilla.org/en-US/docs/domxref/URLPattern.hasRegExpGroups) must be `false`.\n   * - `match-dest`\n   *   - : A space-separated list of strings, with each string in quotes and the whole value enclosed in parentheses, that provides a list of [Fetch request destinations](/en-US/docs/Web/API/Request/destination) that requests must match if they are to use this dictionary.\n   * - `id`\n   *   - : A string value that specifies a server identifier for the dictionary. This ID value will then be added in the [Dictionary-ID](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Dictionary-ID) request header when the browser requests a resource which can use this dictionary.\n   * - `type`\n   *   - : A string value that describes the file format of the supplied dictionary. Currently only `raw` is supported (which is the default) so this is more for future compatibility.\n   *\n   * ## Examples\n   *\n   * ### Path prefix\n   *\n   * ```http\n   * Use-As-Dictionary: match=\"/product/*\"\n   * ```\n   *\n   * This says the dictionary is only to be used for URLs starting with `/product/`.\n   *\n   * ### Versioned directories\n   *\n   * ```http\n   * Use-As-Dictionary: match=\"/app/* /main.js\"\n   * ```\n   *\n   * This uses a wildcard to match multiple versions of a file.\n   *\n   * ### Destinations\n   *\n   * ```http\n   * Use-As-Dictionary: match=\"/product/*\", match-dest=(\"document\")\n   * ```\n   *\n   * This uses `match-dest` to ensure the dictionary is only used for `document` requests so `<script src=\"/product/js/app.js\">` resource requests for example would not match.\n   *\n   * ```http\n   * Use-As-Dictionary: match=\"/product/*\", match-dest=(\"document\" \"frame\")\n   * ```\n   *\n   * This would allow the dictionary to match both top-level documents and iframes.\n   *\n   * ### Id\n   *\n   * ```http\n   * Use-As-Dictionary: match=\"/product/*\", id=\"dictionary-12345\"\n   * ```\n   *\n   * When `Use-As-Dictionary` includes an `id` directive, as in this example, the `id` value will be included in the [Dictionary-ID](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Dictionary-ID) request header for resources that can use this dictionary. The resource request will also include the SHA-256 hash of the dictionary surrounded by colons in the [Available-Dictionary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Available-Dictionary) header:\n   *\n   * ```http\n   * Accept-Encoding: gzip, br, zstd, dcb, dcz\n   * Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:\n   * Dictionary-ID: \"dictionary-12345\"\n   * ```\n   *\n   * The server must still check the hash from the `Available-Dictionary` header — the `Dictionary-ID` is additional information for the server to identify the dictionary but does not replace the need for the `Available-Dictionary` header.\n   *\n   * ### Type\n   *\n   * ```http\n   * Use-As-Dictionary: match=\"/product/*\", type=\"raw\"\n   * ```\n   *\n   * Currently, only `raw` is supported (which is the default) so this is more for future compatibility.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Compression Dictionary Transport guide](/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport)\n   * - [Available-Dictionary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Available-Dictionary)\n   * - [Dictionary-ID](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Dictionary-ID)\n   */\n  'Use-As-Dictionary' = 'Use-As-Dictionary',\n\n  /**\n   * The HTTP **User-Agent** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a characteristic string that lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting [user agent](https://developer.mozilla.org/en-US/docs/Glossary/user_agent).\n   *\n   * > [!WARNING]\n   * > See [Browser detection using the user agent](/en-US/docs/Web/HTTP/Guides/Browser_detection_using_the_user_agent) for reasons why serving different content to different browsers is usually a bad idea.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * User-Agent: <product> / <product-version> <comment>\n   * ```\n   *\n   * Common format for web browsers:\n   *\n   * ```http\n   * User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>) <extensions>\n   * ```\n   *\n   * ### Directives\n   *\n   * - `<product>`\n   *   - : A product identifier — its name or development codename.\n   * - `<product-version>`\n   *   - : Version number of the product.\n   * - `<comment>`\n   *   - : Zero or more comments containing more details. For example, sub-product information.\n   *\n   * ## Firefox UA string\n   *\n   * For more on Firefox- and Gecko-based user agent strings, see the [Firefox user agent string reference](/en-US/docs/Web/HTTP/Reference/Headers/User-Agent/Firefox). The UA string of Firefox is broken down into 4 components:\n   *\n   * ```plain\n   * Mozilla/5.0 (platform; rv:gecko-version) Gecko/gecko-trail Firefox/firefox-version\n   * ```\n   *\n   * 1. `Mozilla/5.0` is the general token that says that the browser is Mozilla-compatible. For historical reasons, almost every browser today sends it.\n   * 2. **_platform_** describes the native platform that the browser is running on (Windows, Mac, Linux, Android, etc.) and if it is a mobile phone. [Firefox OS](https://developer.mozilla.org/en-US/docs/Glossary/Firefox_OS) phones say `Mobile` — the web is the platform. Note that **_platform_** can consist of multiple `;`-separated tokens. See below for further details and examples.\n   * 3. **rv:_gecko-version_** indicates the release version of Gecko (such as \"_17.0_\"). In recent browsers, **_gecko-version_** is the same as **_firefox-version_**.\n   * 4. **_Gecko/gecko-trail_** indicates that the browser is based on Gecko. (On the desktop, **_gecko-trail_** is always the fixed string `20100101`.)\n   * 5. **_Firefox/firefox-version_** indicates that the browser is Firefox and provides the version (such as \"_17.0_\").\n   *\n   * ### Examples\n   *\n   * ```plain\n   * Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0\n   * Mozilla/5.0 (Macintosh; Intel Mac OS X x.y; rv:42.0) Gecko/20100101 Firefox/42.0\n   * ```\n   *\n   * ## Chrome UA string\n   *\n   * The Chrome (or Chromium/Blink-based engines) user agent string is similar to Firefox's. For compatibility, it adds strings like `KHTML, like Gecko` and `Safari`.\n   *\n   * ### Examples\n   *\n   * ```plain\n   * Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36\n   * ```\n   *\n   * ## Opera UA string\n   *\n   * The Opera browser is also based on the Blink engine, which is why it almost looks the same as the Chrome UA string, but adds `\"OPR/<version>\"`.\n   *\n   * ### Examples\n   *\n   * ```plain\n   * Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 OPR/38.0.2220.41\n   * ```\n   *\n   * Older, Presto-based Opera releases used:\n   *\n   * ```plain\n   * Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15 Version/10.00\n   * Opera/9.60 (Windows NT 6.0; U; en) Presto/2.1.1\n   * ```\n   *\n   * ## Microsoft Edge UA string\n   *\n   * The Edge browser is also based on the Blink engine. It adds `\"Edg/<version>\"`.\n   *\n   * ### Examples\n   *\n   * ```plain\n   * Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 Edg/91.0.864.59\n   * ```\n   *\n   * ## Safari UA string\n   *\n   * In this example, the user agent string is mobile Safari's version. It contains the word `\"Mobile\"`.\n   *\n   * ### Examples\n   *\n   * ```plain\n   * Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Mobile/15E148 Safari/604.1\n   * ```\n   *\n   * ## Crawler and bot UA strings\n   *\n   * ### Examples\n   *\n   * ```plain\n   * Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)\n   * ```\n   *\n   * ```plain\n   * Mozilla/5.0 (compatible; YandexAccessibilityBot/3.0; +http://yandex.com/bots)\n   * ```\n   *\n   * ## Library and net tool UA strings\n   *\n   * ### Examples\n   *\n   * ```plain\n   * curl/7.64.1\n   * ```\n   *\n   * ```plain\n   * PostmanRuntime/7.26.5\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [User-Agent detection, history and checklist](https://hacks.mozilla.org/2013/09/user-agent-detection-history-and-checklist/)\n   * - [Firefox user agent string reference](/en-US/docs/Web/HTTP/Reference/Headers/User-Agent/Firefox)\n   * - [Browser detection using the user agent](/en-US/docs/Web/HTTP/Guides/Browser_detection_using_the_user_agent)\n   * - [Client hints](/en-US/docs/Web/HTTP/Guides/Client_hints)\n   */\n  'User-Agent' = 'User-Agent',\n\n  /**\n   * The HTTP **`Vary`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) describes the parts of the request message (aside from the method and URL) that influenced the content of the response it occurs in.\n   * Including a `Vary` header ensures that responses are separately cached based on the headers listed in the `Vary` field.\n   * Most often, this is used to create a cache key when [content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation) is in use.\n   *\n   * The same `Vary` header value should be used on all responses for a given URL, including [304](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304) `Not Modified` responses and the \"default\" response.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Vary: *\n   * Vary: <header-name>, …, <header-nameN>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `*` (wildcard)\n   *   - : Factors other than request headers influenced the generation of this response. Implies that the response is uncacheable.\n   * - `<header-name>`\n   *   - : A request header name that could have influenced the generation of this response.\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Content negotiation](/en-US/docs/Web/HTTP/Guides/Content_negotiation)\n   * - [HTTP caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary)\n   * - [Understanding The Vary Header](https://www.smashingmagazine.com/2017/11/understanding-vary-header/) on smashingmagazine.com (2017)\n   * - [Best Practices for Using the Vary Header](https://www.fastly.com/blog/best-practices-using-vary-header) on fastly.com\n   */\n  'Vary' = 'Vary',\n\n  /**\n   * The **`Via`** [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) is added by [proxies](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server), both forward and reverse.\n   * It is used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders along the request/response chain.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Via: [<protocol-name>/]<protocol-version> <host>[:<port>]\n   * Via: [<protocol-name>/]<protocol-version> <pseudonym>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<protocol-name>`\n   *   - : The name of the protocol used, such as \"HTTP\".\n   * - `<protocol-version>`\n   *   - : The version of the protocol used, such as \"1.1\".\n   * - `<host>`\n   *   - : Public proxy URL and optional `<port>`.\n   *     If a host is not provided, then a `<pseudonym>` must be used.\n   * - `<pseudonym>`\n   *   - : Name/alias of an internal proxy.\n   *     If a pseudonym is not provided, then a `<host>` must be used.\n   *\n   * ## Examples\n   *\n   * ```http\n   * Via: 1.1 vegur\n   * Via: HTTP/1.1 GWA\n   * Via: 1.0 fred, 1.1 p.example.net\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [X-Forwarded-For](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For)\n   * - [Heroku's proxy library Vegur](https://github.com/heroku/vegur)\n   */\n  'Via' = 'Via',\n\n  /**\n   * > [!WARNING]\n   * > The `Viewport-Width` header was removed from the client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07).\n   * > The proposed replacement is [`Sec-CH-Viewport-Width`](https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-width) (Responsive Image Client Hints).\n   *\n   * The HTTP **`Viewport-Width`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [device client hint](/en-US/docs/Web/HTTP/Guides/Client_hints) which provides the client's layout viewport width in [CSS pixels](https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel).\n   * The value is rounded up to the smallest following integer (i.e., ceiling value).\n   *\n   * The hint can be used with other screen-specific hints to deliver images optimized for a specific screen size, or to omit resources that are not needed for a particular screen width.\n   * If the `Viewport-Width` header appears more than once in a message the last occurrence is used.\n   *\n   * A server has to opt-in to receive the `Viewport-Width` header from the client, by sending the [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) response header.\n   * Servers that opt-in will typically also specify it in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header which informs caches that the server may send different responses based on the header value in a request.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Viewport-Width: <number>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<number>`\n   *   - : The width of the user's viewport in [CSS pixels](https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel), rounded up to the nearest integer.\n   *\n   * ## Examples\n   *\n   * ### Using Viewport-Width\n   *\n   * A server must first opt-in to receive the `Viewport-Width` header by sending the response header [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) containing the directive `Viewport-Width`.\n   *\n   * ```http\n   * Accept-CH: Viewport-Width\n   * ```\n   *\n   * In subsequent requests, the client might send `Viewport-Width` header:\n   *\n   * ```http\n   * Viewport-Width: 320\n   * ```\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   * - [Content-DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-DPR), [Device-Memory](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Device-Memory), [DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DPR), [Width](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Width) device client hints\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   */\n  'Viewport-Width' = 'Viewport-Width',\n\n  /**\n   * The HTTP **`Want-Content-Digest`** [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) indicates a preference for the recipient to send a [Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Digest) integrity header in messages associated with the request URI and representation metadata.\n   *\n   * The header includes hashing algorithm preferences that the recipient can use in subsequent messages.\n   * The preferences only serve as a hint, and the recipient may ignore the algorithm choices, or the integrity headers entirely.\n   *\n   * Some implementations may send unsolicited `Content-Digest` headers without requiring a `Want-Content-Digest` header in a previous message.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Want-Content-Digest: <algorithm>=<preference>\n   * Want-Content-Digest: <algorithm>=<preference>, …, <algorithmN>=<preferenceN>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<algorithm>`\n   *   - : The requested algorithm to create a digest of the message content.\n   *     Only two registered digest algorithms are considered secure: `sha-512` and `sha-256`.\n   *     The insecure (legacy) registered digest algorithms are: `md5`, `sha` (SHA-1), `unixsum`, `unixcksum`, `adler` (ADLER32) and `crc32c`.\n   * - `<preference>`\n   *   - : An integer from 0 to 9 where `0` means \"not acceptable\", and the values `1` to `9` convey ascending, relative, weighted preference.\n   *     In contrast to earlier drafts of the specifications, the weighting is _not_ declared via `q` [quality values](/en-US/docs/Glossary/Quality_values).\n   *\n   * ## Examples\n   *\n   * ### Using Want-Content-Digest in requests\n   *\n   * The following message asks the recipient to send a `Content-Digest` header using SHA-512 algorithm:\n   *\n   * ```http\n   * Want-Content-Digest: sha-512=9\n   * ```\n   *\n   * ### Want-Content-Digest with multiple values\n   *\n   * The following header contains three algorithms, and indicates that SHA-256 is the preferred digest algorithm that the recipient should use, followed by SHA-512, and MD5:\n   *\n   * ```http\n   * Want-Content-Digest: md5=1, sha-512=2, sha-256=3\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * This header has no specification-defined browser integration (\"browser compatibility\" does not apply).\n   * Developers can set and get HTTP headers using `fetch()` in order to provide application-specific implementation behavior.\n   *\n   * ## See also\n   *\n   * - [Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Digest), [Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Repr-Digest), [Want-Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Repr-Digest) digest headers\n   * - [Digital Signatures for APIs](https://developer.ebay.com/develop/guides/digital-signatures-for-apis) SDK guide uses `Content-Digest`s for digital signatures in HTTP calls (developer.ebay.com)\n   */\n  'Want-Content-Digest' = 'Want-Content-Digest',\n\n  /**\n   * The HTTP **`Want-Repr-Digest`** [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) indicates a preference for the recipient to send a [Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Repr-Digest) integrity header in messages associated with the request URI and representation metadata.\n   *\n   * The header includes hashing algorithm preferences that the recipient can use in subsequent messages.\n   * The preferences only serve as a hint, and the recipient may ignore the algorithm choices, or the integrity headers entirely.\n   *\n   * Some implementations may send unsolicited `Repr-Digest` headers without requiring a `Want-Repr-Digest` header in a previous message.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Want-Repr-Digest: <algorithm>=<preference>\n   * Want-Repr-Digest: <algorithm>=<preference>, …, <algorithmN>=<preferenceN>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<algorithm>`\n   *   - : The requested algorithm to create a digest of the representation.\n   *     Only two registered digest algorithms are considered secure: `sha-512` and `sha-256`.\n   *     The insecure (legacy) registered digest algorithms are: `md5`, `sha` (SHA-1), `unixsum`, `unixcksum`, `adler` (ADLER32) and `crc32c`.\n   * - `<preference>`\n   *   - : An integer from 0 to 9 where `0` means \"not acceptable\", and the values `1` to `9` convey ascending, relative, weighted preference.\n   *     In contrast to earlier drafts of the specifications, the weighting is _not_ declared via `q` [quality values](/en-US/docs/Glossary/Quality_values).\n   *\n   * ## Examples\n   *\n   * ```http\n   * Want-Repr-Digest: sha-512=8, sha-256=6, adler=0, sha=1\n   * Want-Repr-Digest: sha-512=10, sha-256=1, md5=0\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * This header has no specification-defined browser integration (\"browser compatibility\" does not apply).\n   * Developers can set and get HTTP headers using `fetch()` in order to provide application-specific implementation behavior.\n   *\n   * ## See also\n   *\n   * - [Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Digest), [Repr-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Repr-Digest), [Want-Content-Digest](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Content-Digest) digest headers\n   * - [Digital Signatures for APIs](https://developer.ebay.com/develop/guides/digital-signatures-for-apis) SDK guide uses `Content-Digest`s for digital signatures in HTTP calls (developer.ebay.com)\n   */\n  'Want-Repr-Digest' = 'Want-Repr-Digest',\n\n  /**\n   * > [!NOTE]\n   * > The header was deprecated because it is not widely generated or surfaced to users (see [RFC9111](https://www.rfc-editor.org/rfc/rfc9111#field.warning)).\n   * > Some of the information can be inferred from other headers such as [Age](https://developer.mozilla.org/en-US/docs/httpheader/Age).\n   *\n   * The HTTP **`Warning`** [request](https://developer.mozilla.org/en-US/docs/glossary/request_header) and [response header](https://developer.mozilla.org/en-US/docs/glossary/response_header) contains information about possible problems with the status of the message.\n   * More than one `Warning` header may appear in a response.\n   *\n   * `Warning` header fields can, in general, be applied to any message.\n   * However, some warn-codes are specific to caches and can only be applied to response messages.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<warn-code>`\n   *   - : A three-digit warning number. The first digit indicates whether the `Warning` is required to be deleted from a stored response after validation.\n   *     - `1xx` warn-codes describe the freshness or validation status of the response and will be deleted by a cache after successful validation.\n   *     - `2xx` warn-codes describe some aspect of the representation that is not rectified by a validation and will not be deleted by a cache after validation unless a full response is sent.\n   *\n   * - `<warn-agent>`\n   *   - : The name or pseudonym of the server or software adding the `Warning` header (might be \"-\" when the agent is unknown).\n   * - `<warn-text>`\n   *   - : An advisory text describing the error.\n   * - `<warn-date>`\n   *   - : A date. If more than one `Warning` header is sent, include a date that matches the [Date](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date) header.\n   *\n   * ## Warning codes\n   *\n   * The [HTTP Warn Codes registry at iana.org](https://www.iana.org/assignments/http-warn-codes/http-warn-codes.xhtml) defines the namespace for warning codes.\n   *\n   * | Code | Text                             | Description                                                                                                                                                                                      |\n   * | ---- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n   * | 110  | Response is Stale                | The response provided by a cache is stale (the expiration time set for the response has passed).                                                                                                 |\n   * | 111  | Revalidation Failed              | An attempt to validate the stale response failed due to an inability to reach the server.                                                                                                        |\n   * | 112  | Disconnected Operation           | The cache is intentionally disconnected from the rest of the network.                                                                                                                            |\n   * | 113  | Heuristic Expiration             | A cache heuristically chose a [freshness lifetime](/en-US/docs/Web/HTTP/Guides/Caching#fresh_and_stale_based_on_age) greater than 24 hours and the age of the response is greater than 24 hours. |\n   * | 199  | Miscellaneous Warning            | Arbitrary information that should be presented to a user or logged.                                                                                                                              |\n   * | 214  | Transformation Applied           | Added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type or the like.                                                            |\n   * | 299  | Miscellaneous Persistent Warning | Arbitrary information that should be presented to a user or logged. This warn-code is similar to the warn-code 199 and additionally indicates a persistent warning.                              |\n   *\n   * ## Examples\n   *\n   * ```http\n   * Warning: 110 anderson/1.3.37 \"Response is stale\"\n   *\n   * Date: Wed, 21 Oct 2015 07:28:00 GMT\n   * Warning: 112 - \"cache down\" \"Wed, 21 Oct 2015 07:28:00 GMT\"\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Date](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date)\n   * - [HTTP response status codes](/en-US/docs/Web/HTTP/Reference/Status)\n   */\n  'Warning' = 'Warning',\n\n  /**\n   * > [!WARNING]\n   * > The `Width` header was removed from the client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07). The proposed replacement is [`Sec-CH-Width`](https://wicg.github.io/responsive-image-client-hints/#sec-ch-width) (Responsive Image Client Hints).\n   *\n   * The HTTP **`Width`** [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a [device client hint](/en-US/docs/Web/HTTP/Guides/Client_hints#device_client_hints) which indicates the desired resource width in physical pixels — the intrinsic size of an image. The provided pixel value is a number rounded to the smallest following integer (i.e., ceiling value).\n   *\n   * The hint allows the client to request a resource that is optimal for both the screen and the layout: taking into account both the density-corrected width of the screen and the image's extrinsic size within the layout.\n   *\n   * If the desired resource width is not known at the time of the request or the resource does not have a display width, the `Width` header field can be omitted.\n   * If the `Width` header appears more than once in a message the last occurrence is used.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * Width: <number>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<number>`\n   *   - : The width of the resource in physical pixels, rounded up to the nearest integer.\n   *\n   * ## Examples\n   *\n   * The server first needs to opt in to receive the `Width` header by sending the response headers [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH) containing `Width`.\n   *\n   * ```http\n   * Accept-CH: Width\n   * ```\n   *\n   * Then on subsequent requests the client might send `Width` header back:\n   *\n   * ```http\n   * Width: 1920\n   * ```\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Content-DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-DPR), [Device-Memory](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Device-Memory), [DPR](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DPR), [Viewport-Width](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Viewport-Width) device client hints\n   * - [Accept-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH)\n   * - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Guides/Caching#vary) and [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) header\n   * - [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)\n   */\n  'Width' = 'Width',\n\n  /**\n   * The HTTP **`WWW-Authenticate`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) advertises the [HTTP authentication](/en-US/docs/Web/HTTP/Guides/Authentication) methods (or [challenges](https://developer.mozilla.org/en-US/docs/Glossary/challenge)) that might be used to gain access to a specific resource.\n   *\n   * This header is part of the [General HTTP authentication framework](/en-US/docs/Web/HTTP/Guides/Authentication#the_general_http_authentication_framework), which can be used with a number of [authentication schemes](/en-US/docs/Web/HTTP/Guides/Authentication#authentication_schemes).\n   * Each challenge identifies a scheme supported by the server and additional parameters that are defined for that scheme type.\n   *\n   * A server using [HTTP authentication](/en-US/docs/Web/HTTP/Guides/Authentication) will respond with a [401 Unauthorized](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401) response to a request for a protected resource.\n   * This response must include at least one `WWW-Authenticate` header and at least one challenge to indicate what authentication schemes can be used to access the resource and any additional data that each particular scheme needs.\n   *\n   * Multiple challenges are allowed in one `WWW-Authenticate` header, and multiple `WWW-Authenticate` headers are allowed in one response.\n   * A server may also include the `WWW-Authenticate` header in other response messages to indicate that supplying credentials might affect the response.\n   *\n   * After receiving the `WWW-Authenticate` header, a client will typically prompt the user for credentials, and then re-request the resource.\n   * This new request uses the [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) header to supply the credentials to the server, encoded appropriately for the selected authentication method.\n   * The client is expected to select the most secure of the challenges it understands (note that in some cases the \"most secure\" method is debatable).\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * WWW-Authenticate: <challenge>\n   * ```\n   *\n   * Where a `<challenge>` is comprised of an `<auth-scheme>`, followed by an optional `<token68>` or a comma-separated list of `<auth-params>`:\n   *\n   * ```plain\n   * challenge = <auth-scheme> <auth-param>, …, <auth-paramN>\n   * challenge = <auth-scheme> <token68>\n   * ```\n   *\n   * For example:\n   *\n   * ```http\n   * WWW-Authenticate: <auth-scheme>\n   * WWW-Authenticate: <auth-scheme> token68\n   * WWW-Authenticate: <auth-scheme> auth-param1=param-token1\n   * WWW-Authenticate: <auth-scheme> auth-param1=param-token1, …, auth-paramN=param-tokenN\n   * ```\n   *\n   * The presence of a `token68` or authentication parameters depends on the selected `<auth-scheme>`.\n   * For example, [Basic authentication](/en-US/docs/Web/HTTP/Guides/Authentication#basic_authentication_scheme) requires a `<realm>`, and allows for optional use of `charset` key, but does not support a `token68`:\n   *\n   * ```http\n   * WWW-Authenticate: Basic realm=\"Dev\", charset=\"UTF-8\"\n   * ```\n   *\n   * Multiple challenges can be sent in a comma-separated list\n   *\n   * ```http\n   * WWW-Authenticate: <challenge>, …, <challengeN>\n   * ```\n   *\n   * Multiple headers can also be sent in a single response:\n   *\n   * ```http\n   * WWW-Authenticate: <challenge>\n   * WWW-Authenticate: <challengeN>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<auth-scheme>`\n   *   - : A case-insensitive token indicating the [Authentication scheme](/en-US/docs/Web/HTTP/Guides/Authentication#authentication_schemes) used.\n   *     Some of the more common types are [`Basic`](/en-US/docs/Web/HTTP/Guides/Authentication#basic_authentication_scheme), `Digest`, `Negotiate` and `AWS4-HMAC-SHA256`.\n   *     IANA maintains a [list of authentication schemes](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml), but there are other schemes offered by host services.\n   * - `<auth-param>`\n   *   - : An authentication parameter whose format depends on the `<auth-scheme>`.\n   *     `<realm>` is described below as it's a common authentication parameter among many auth schemes.\n   *     - `<realm>`\n   *       - : The string `realm` followed by `=` and a quoted string describing a protected area, for example `realm=\"staging environment\"`.\n   *         A realm allows a server to partition the areas it protects (if supported by a scheme that allows such partitioning).\n   *         Some clients show this value to the user to inform them about which particular credentials are required — though most browsers stopped doing so to counter phishing.\n   *         The only reliably supported character set for this value is `us-ascii`.\n   *         If no realm is specified, clients often display a formatted hostname instead.\n   * - `<token68>`\n   *   - : A token that may be useful for some schemes.\n   *     The token allows the 66 unreserved URI characters plus a few others.\n   *     It can hold a [base64](https://developer.mozilla.org/en-US/docs/glossary/base64), base64url, base32, or base16 (hex) encoding, with or without padding, but excluding whitespace.\n   *     The token68 alternative to auth-param lists is supported for consistency with legacy authentication schemes.\n   *\n   * Generally, you will need to check the relevant specifications for the authentication parameters needed for each `<auth-scheme>`.\n   * The following sections describe token and auth parameters for some common auth schemes.\n   *\n   * ### Basic authentication directives\n   *\n   * - `<realm>`\n   *   - : A `<realm>` as [described above](#realm).\n   *     Note that the realm is mandatory for `Basic` authentication.\n   * - `charset=\"UTF-8\"`\n   *   - : Tells the client the server's preferred encoding scheme when submitting a username and password.\n   *     The only allowed value is the case-insensitive string `UTF-8`.\n   *     This does not relate to the encoding of the realm string.\n   *\n   * ### Digest authentication directives\n   *\n   * - `<realm>`\n   *   - : A `<realm>` as [described above](#realm) indicating which username/password to use.\n   *     Minimally should include the host name, but might indicate the users or group that have access.\n   * - `domain`\n   *   - : A quoted, space-separated list of URI prefixes that define all the locations where the authentication information may be used.\n   *     If this key is not specified then the authentication information may be used anywhere on the web root.\n   * - `nonce`\n   *   - : A server-specified quoted string that the server can use to control the lifetime in which particular credentials will be considered valid.\n   *     This must be uniquely generated each time a 401 response is made, and may be regenerated more often (for example, allowing a digest to be used only once).\n   *     The specification contains advice on possible algorithms for generating this value.\n   *     The nonce value is opaque to the client.\n   * - `opaque`\n   *   - : A server-specified quoted string that should be returned unchanged in the [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization).\n   *     This is opaque to the client. The server is recommended to include Base64 or hexadecimal data.\n   * - `stale`\n   *   - : A case-insensitive flag indicating that the previous request from the client was rejected because the `nonce` used is too old (stale).\n   *     If this is `true` the request can be retried using the same username/password encrypted using the new `nonce`.\n   *     If it is any other value then the username/password are invalid and must be re-requested from the user.\n   * - `algorithm`\n   *   - : A string indicating the algorithm used to produce a digest.\n   *     Valid non-session values are: `MD5` (default if `algorithm` not specified), `SHA-256`, `SHA-512`.\n   *     Valid session values are: `MD5-sess`, `SHA-256-sess`, `SHA-512-sess`.\n   * - `qop`\n   *   - : Quoted string indicating the quality of protection supported by the server. This must be supplied, and unrecognized options must be ignored.\n   *     - `\"auth\"`: Authentication\n   *     - `\"auth-int\"`: Authentication with integrity protection\n   * - `charset=\"UTF-8\"`\n   *   - : Tells the client the server's preferred encoding scheme when submitting a username and password.\n   *     The only allowed value is the case-insensitive string \"UTF-8\".\n   * - `userhash`\n   *   - : A server may specify `\"true\"` to indicate that it supports username hashing (default is `\"false\"`)\n   *\n   * ### HTTP Origin-Bound Authentication (HOBA)\n   *\n   * - `<challenge>`\n   *   - : A set of pairs in the format of `<len>:<value>` concatenated together to be given to a client.\n   *     The challenge is made of up a nonce, algorithm, origin, realm, key identifier, and the challenge.\n   * - `<max-age>`\n   *   - : The number of seconds from the time the HTTP response is emitted for which responses to this challenge can be accepted.\n   * - `<realm>`\n   *   - : As above in the [directives](#directives) section.\n   *\n   * ## Examples\n   *\n   * ### Issuing multiple authentication challenges\n   *\n   * Multiple challenges may be specified in a single response header:\n   *\n   * ```http\n   * HTTP/1.1 401 Unauthorized\n   * WWW-Authenticate: challenge1, …, challengeN\n   * ```\n   *\n   * Multiple challenges can be sent in separate `WWW-Authenticate` headers in the same response:\n   *\n   * ```http\n   * HTTP/1.1 401 Unauthorized\n   * WWW-Authenticate: challenge1\n   * WWW-Authenticate: challengeN\n   * ```\n   *\n   * ### Basic authentication\n   *\n   * A server that only supports basic authentication might have a `WWW-Authenticate` response header which looks like this:\n   *\n   * ```http\n   * HTTP/1.1 401 Unauthorized\n   * WWW-Authenticate: Basic realm=\"Staging server\", charset=\"UTF-8\"\n   * ```\n   *\n   * A user-agent receiving this header would first prompt the user for their username and password, and then re-request the resource with the encoded credentials in the `Authorization` header.\n   * The `Authorization` header might look like this:\n   *\n   * ```http\n   * Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l\n   * ```\n   *\n   * For `Basic` authentication, the credentials are constructed by first combining the username and the password with a colon (`aladdin:opensesame`), and then by encoding the resulting string in [`base64`](/en-US/docs/Glossary/Base64) (`YWxhZGRpbjpvcGVuc2VzYW1l`).\n   *\n   * > [!NOTE]\n   * > See also [HTTP authentication](/en-US/docs/Web/HTTP/Guides/Authentication) for examples on how to configure Apache or Nginx servers to password protect your site with HTTP basic authentication.\n   *\n   * ### Digest authentication with SHA-256 and MD5\n   *\n   * > [!NOTE]\n   * > This example is taken from [7616](https://developer.mozilla.org/en-US/docs/RFC/7616) \"HTTP Digest Access Authentication\" (other examples in the specification show the use of `SHA-512`, `charset`, and `userhash`).\n   *\n   * The client attempts to access a document at URI `http://www.example.org/dir/index.html` that is protected via digest authentication.\n   * The username for this document is \"Mufasa\" and the password is \"Circle of Life\" (note the single space between each of the words).\n   *\n   * The first time the client requests the document, no [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) header field is sent.\n   * Here the server responds with an HTTP 401 message that includes a challenge for each digest algorithm it supports, in its order of preference (`SHA256` and then `MD5`)\n   *\n   * ```http\n   * HTTP/1.1 401 Unauthorized\n   * WWW-Authenticate: Digest\n   *     realm=\"http-auth@example.org\",\n   *     qop=\"auth, auth-int\",\n   *     algorithm=SHA-256,\n   *     nonce=\"7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v\",\n   *     opaque=\"FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS\"\n   * WWW-Authenticate: Digest\n   *     realm=\"http-auth@example.org\",\n   *     qop=\"auth, auth-int\",\n   *     algorithm=MD5,\n   *     nonce=\"7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v\",\n   *     opaque=\"FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS\"\n   * ```\n   *\n   * The client prompts the user for their username and password, and then responds with a new request that encodes the credentials in the [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) header field.\n   * If the client chose the MD5 digest the [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) header field might look as shown below:\n   *\n   * ```http\n   * Authorization: Digest username=\"Mufasa\",\n   *     realm=\"http-auth@example.org\",\n   *     uri=\"/dir/index.html\",\n   *     algorithm=MD5,\n   *     nonce=\"7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v\",\n   *     nc=00000001,\n   *     cnonce=\"f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ\",\n   *     qop=auth,\n   *     response=\"8ca523f5e9506fed4657c9700eebdbec\",\n   *     opaque=\"FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS\"\n   * ```\n   *\n   * If the client chose the SHA-256 digest the [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) header field might look as shown below:\n   *\n   * ```http\n   * Authorization: Digest username=\"Mufasa\",\n   *     realm=\"http-auth@example.org\",\n   *     uri=\"/dir/index.html\",\n   *     algorithm=SHA-256,\n   *     nonce=\"7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v\",\n   *     nc=00000001,\n   *     cnonce=\"f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ\",\n   *     qop=auth,\n   *     response=\"753927fa0e85d155564e2e272a28d1802ca10daf449\n   *         6794697cf8db5856cb6c1\",\n   *     opaque=\"FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS\"\n   * ```\n   *\n   * ### HOBA Authentication\n   *\n   * A server that supports HOBA authentication might have a `WWW-Authenticate` response header which looks like this:\n   *\n   * ```http\n   * HTTP/1.1 401 Unauthorized\n   * WWW-Authenticate: HOBA max-age=\"180\", challenge=\"16:MTEyMzEyMzEyMw==1:028:https://www.example.com:8080:3:MTI48:NjgxNDdjOTctNDYxYi00MzEwLWJlOWItNGM3MDcyMzdhYjUz\"\n   * ```\n   *\n   * The to-be-signed blob challenge is made from these parts: `www.example.com` using port 8080, the nonce is `1123123123`, the algorithm for signing is RSA-SHA256, the key identifier is `123`, and finally the challenge is `68147c97-461b-4310-be9b-4c707237ab53`.\n   *\n   * A client would receive this header, extract the challenge, sign it with their private key that corresponds to key identifier 123 in our example using RSA-SHA256, and then send the result in the `Authorization` header as a dot-separated key id, challenge, nonce, and signature.\n   *\n   * ```http\n   * Authorization: 123.16:MTEyMzEyMzEyMw==1:028:https://www.example.com:8080:3:MTI48:NjgxNDdjOTctNDYxYi00MzEwLWJlOWItNGM3MDcyMzdhYjUz.1123123123.<signature-of-challenge>\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [HTTP authentication](/en-US/docs/Web/HTTP/Guides/Authentication)\n   * - [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization)\n   * - [Proxy-Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authorization)\n   * - [Proxy-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authenticate)\n   * - [401](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401), [403](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403), [407](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407)\n   */\n  'WWW-Authenticate' = 'WWW-Authenticate',\n\n  /**\n   * The HTTP **`X-Content-Type-Options`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) indicates that the [MIME types](/en-US/docs/Web/HTTP/Guides/MIME_types) advertised in the [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) headers should be respected and not changed.\n   * The header allows you to avoid [MIME type sniffing](/en-US/docs/Web/HTTP/Guides/MIME_types#mime_sniffing) by specifying that the MIME types are deliberately configured.\n   *\n   * Site security testers usually expect this header to be set.\n   *\n   * > [!NOTE]\n   * > The `X-Content-Type-Options` header only apply request-blocking [due to `nosniff`](https://fetch.spec.whatwg.org/#ref-for-determine-nosniff) for [request destinations](/en-US/docs/Web/API/Request/destination) of `\"script\"` and `\"style\"`.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * X-Content-Type-Options: nosniff\n   * ```\n   *\n   * ## Directives\n   *\n   * - `nosniff`\n   *   - : Blocks a request if the request destination is of type\n   *     `style` and the MIME type is not `text/css`,\n   *     or of type `script` and the MIME type is not a [JavaScript MIME type](https://html.spec.whatwg.org/multipage/scripting.html#javascript-mime-type).\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type)\n   * - The [original definition](https://learn.microsoft.com/en-us/archive/blogs/ie/ie8-security-part-vi-beta-2-update) of X-Content-Type-Options by Microsoft.\n   * - Use [HTTP Observatory](/en-US/observatory) to test the security configuration of websites (including this header).\n   * - [Mitigating MIME Confusion Attacks in Firefox](https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/)\n   */\n  'X-Content-Type-Options' = 'X-Content-Type-Options',\n\n  /**\n   * The HTTP **`X-DNS-Prefetch-Control`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.\n   *\n   * The intention is that prefetching is performed in the background so that the [DNS](https://developer.mozilla.org/en-US/docs/glossary/DNS) resolution is complete by the time the referenced items are needed by the browser.\n   * This reduces latency when the user clicks a link, for example.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * X-DNS-Prefetch-Control: on\n   * X-DNS-Prefetch-Control: off\n   * ```\n   *\n   * ### Directives\n   *\n   * - `on`\n   *   - : Enables DNS prefetching. This is what browsers do if they support the feature when this header is not present.\n   * - `off`\n   *   - : Disables DNS prefetching. This is useful if you don't control the link on the pages or know that you don't want to leak information to these domains.\n   *\n   * ## Description\n   *\n   * DNS requests are very small in terms of bandwidth, but latency can be quite high,\n   * especially on mobile networks. By speculatively prefetching DNS results, latency can be\n   * reduced significantly at certain times, such as when the user clicks the link. In some\n   * cases, latency can be reduced by a second.\n   *\n   * The implementation of this prefetching in some browsers allows domain name resolution\n   * to occur in parallel with (instead of in serial with) the fetching of actual page\n   * content. By doing this, the high-latency domain name resolution process doesn't cause\n   * any delay while fetching content.\n   *\n   * Page load times – especially on mobile networks – can be measurably improved in this\n   * way. If the domain names for images can be resolved in advance of the images being\n   * requested, pages that load many images can see an improvement of 5% or more in the time\n   * of loading images.\n   *\n   * ### Configuring prefetching in the browser\n   *\n   * In general, you don't need to do anything to manage prefetching. However, the user may\n   * wish to disable prefetching. On Firefox, this can be done by setting the\n   * `network.dns.disablePrefetch` preference to `true`.\n   *\n   * Also, by default, prefetching of embedded link hostnames is not performed on documents\n   * loaded over [HTTPS](https://developer.mozilla.org/en-US/docs/glossary/HTTPS). On Firefox, this can be changed by setting the\n   * `network.dns.disablePrefetchFromHTTPS` preference to `false`.\n   *\n   * ## Examples\n   *\n   * ### Turning on and off prefetching\n   *\n   * You can either send the `X-DNS-Prefetch-Control` header server-side, or from\n   * individual documents, using the [`http-equiv`](/en-US/docs/Web/HTML/Reference/Elements/meta/http-equiv) attribute on\n   * the [meta](https://developer.mozilla.org/en-US/docs/HTMLElement/meta) element, like this:\n   *\n   * ```html\n   * <meta http-equiv=\"x-dns-prefetch-control\" content=\"off\" />\n   * ```\n   *\n   * You can reverse this setting by setting `content` to `\"on\"`.\n   *\n   * ### Forcing lookup of specific hostnames\n   *\n   * You can force the lookup of specific hostnames without providing specific anchors using\n   * that hostname by using the [`rel`](/en-US/docs/Web/HTML/Reference/Elements/link#rel) attribute on the\n   * [link](https://developer.mozilla.org/en-US/docs/HTMLElement/link) element with a [link type](/en-US/docs/Web/HTML/Reference/Attributes/rel) of `dns-prefetch`:\n   *\n   * ```html\n   * <link rel=\"dns-prefetch\" href=\"https://www.mozilla.org\" />\n   * ```\n   *\n   * In this example, the domain name `www.mozilla.org` will be pre-resolved.\n   *\n   * Similarly, the link element can be used to resolve hostnames without providing a\n   * complete URL, but only, by preceding the hostname with two slashes:\n   *\n   * ```html\n   * <link rel=\"dns-prefetch\" href=\"//www.mozilla.org\" />\n   * ```\n   *\n   * Forced prefetching of hostnames might be useful, for example, on the homepage of a site\n   * to force pre-resolution of domain names that are referenced frequently throughout the\n   * site even though they are not used on the home page itself. This will improve the\n   * overall performance of site even though the performance of the home page may not be\n   * affected.\n   *\n   * ## Specifications\n   *\n   * Not part of any current specification.\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [DNS Prefetching for Firefox (blog post)](https://bitsup.blogspot.com/2008/11/dns-prefetching-for-firefox.html)\n   * - [Google Chrome handles DNS prefetching control](https://www.chromium.org/developers/design-documents/dns-prefetching/)\n   */\n  'X-DNS-Prefetch-Control' = 'X-DNS-Prefetch-Control',\n\n  /**\n   * The HTTP **`X-Forwarded-For`** (XFF) [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through a [proxy server](https://developer.mozilla.org/en-US/docs/Glossary/proxy_server).\n   *\n   * A standardized version of this header is the HTTP [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded) header, although it's much less frequently used.\n   *\n   * > [!WARNING]\n   * > Improper use of this header can be a security risk.\n   * > For details, see the [Security and privacy concerns](#security_and_privacy_concerns) section.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * X-Forwarded-For: <client>, <proxy>\n   * X-Forwarded-For: <client>, <proxy>, …, <proxyN>\n   * ```\n   *\n   * For example, an IPV6 client IP in the first header, an IPV4 client IP in the second header, and an IPV4 client IP and an IPV6 proxy IP in the third example:\n   *\n   * ```http\n   * X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348\n   * X-Forwarded-For: 203.0.113.195\n   * X-Forwarded-For: 203.0.113.195, 2001:db8:85a3:8d3:1319:8a2e:370:7348\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<client>`\n   *   - : The client IP address.\n   * - `<proxy>`\n   *   - : A proxy IP address.\n   *     If a request goes through multiple proxies, the IP addresses of each successive proxy are listed.\n   *     This means that the rightmost IP address is the IP address of the most recent proxy and the leftmost IP address is the address of the originating client (assuming well-behaved client and proxies).\n   *\n   * ## Description\n   *\n   * When a client connects directly to a server, the client's IP address is sent to the server and is often written to server access logs.\n   * If a client connection passes through any forward or reverse proxies, the server only sees the final proxy's IP address, which is often of little use.\n   * That's especially true if the final proxy is a load balancer which is part of the same deployment as the server.\n   * To provide a more useful client IP address to the server, the `X-Forwarded-For` request header is used.\n   *\n   * For detailed guidance on using `X-Forwarded-For`, see the [Parsing](#parsing) and [Selecting an IP address](#selecting_an_ip_address) sections.\n   *\n   * ### Security and privacy concerns\n   *\n   * This header exposes privacy-sensitive information by design, such as the IP address of the client.\n   * Therefore, the user's privacy must be kept in mind when using this header.\n   *\n   * If you know that all proxies in the request chain are trusted (i.e., you control them) and are configured correctly, the parts of the header added by your proxies can be trusted.\n   * If any proxy is malicious or misconfigured, any part of the header not added by a trusted proxy may be spoofed or may have an unexpected format or contents.\n   * If the server can be directly connected to from the internet — even if it is also behind a trusted reverse proxy — **no part** of the `X-Forwarded-For` IP list can be considered trustworthy or safe for security-related uses.\n   *\n   * Any security-related use of `X-Forwarded-For` (such as for rate limiting or IP-based access control) _must only_ use IP addresses added by a trusted proxy.\n   * Using untrustworthy values can result in rate-limiter avoidance, access-control bypass, memory exhaustion, or other negative security or availability consequences.\n   *\n   * Leftmost (untrusted) values must only be used for cases where there is no negative impact from using spoofed values.\n   *\n   * ### Parsing\n   *\n   * Improper parsing of the `X-Forwarded-For` header may have a negative security impact with consequences as described in the previous section.\n   * For this reason, the following points should be considered when parsing the header values.\n   *\n   * There may be multiple `X-Forwarded-For` headers present in a request.\n   * The IP addresses in these headers must be treated as a single list, starting with the first IP address of the first header and continuing to the last IP address of the last header.\n   * There are two ways of making this single list:\n   *\n   * - Join the `X-Forwarded-For` full header values with commas and then split by comma into a list, or\n   * - split each `X-Forwarded-For` header by comma into lists and then join the lists.\n   *\n   * It is insufficient to use only one of multiple `X-Forwarded-For` headers.\n   *\n   * Some reverse proxies will automatically join multiple `X-Forwarded-For` headers into one, but it is safer not to assume that this is the case.\n   *\n   * ### Selecting an IP address\n   *\n   * When selecting an address, the full list of IPs (from all `X-Forwarded-For` headers) must be used.\n   *\n   * When choosing the `X-Forwarded-For` IP address closest to the client (untrustworthy and _not_ for security-related purposes), the first IP from the leftmost that is _a valid address_ and _not private/internal_ should be selected.\n   *\n   * > [!NOTE]\n   * > We say \"a valid address\" above because spoofed values may not be actual IP addresses.\n   * > Additionally, we say \"not internal/private\" because clients may have used proxies on their internal network, which may have added addresses from the [private IP space](https://en.wikipedia.org/wiki/Private_network).\n   *\n   * When choosing the first _trustworthy_ `X-Forwarded-For` client IP address, additional configuration is required.\n   * There are two common methods:\n   *\n   * - Trusted proxy count\n   *   - : The count of reverse proxies between the internet and the server is configured.\n   *     The `X-Forwarded-For` IP list is searched from the rightmost by that count minus one.\n   *     For example, if there is only one reverse proxy, that proxy will add the client's IP address, so the rightmost address should be used.\n   *     If there are three reverse proxies, the last two IP addresses will be internal.\n   * - Trusted proxy list\n   *   - : The IPs or IP ranges of the trusted reverse proxies are configured.\n   *     The `X-Forwarded-For` IP list is searched from the rightmost, skipping all addresses that are on the trusted proxy list.\n   *     The first non-matching address is the target address.\n   *\n   * The first trustworthy `X-Forwarded-For` IP address may belong to an untrusted intermediate proxy rather than the actual client, but it is the only IP suitable to identify a client for security purposes.\n   *\n   * ## Examples\n   *\n   * ### Client and proxy IPs\n   *\n   * From the following `X-Forwarded-For` request header, we can infer that the client IP address is `203.0.113.195`, and the request has passed through two proxies.\n   * The first proxy has an IPv6 address of `2001:db8:85a3:8d3:1319:8a2e:370:7348` and the last proxy in the request chain has an IPv4 address of `198.51.100.178`:\n   *\n   * ```http\n   * X-Forwarded-For: 203.0.113.195,2001:db8:85a3:8d3:1319:8a2e:370:7348,198.51.100.178\n   * ```\n   *\n   * ## Specifications\n   *\n   * Not part of any current specification. The standardized version of this header is [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded).\n   *\n   * ## See also\n   *\n   * - [X-Forwarded-Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host), [X-Forwarded-Proto](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto) headers\n   * - [Via](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Via)\n   * - [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded)\n   * - [What is X-Forwarded-For and when can you trust it?](https://httptoolkit.com/blog/what-is-x-forwarded-for/) httptoolkit.com (2024)\n   */\n  'X-Forwarded-For' = 'X-Forwarded-For',\n\n  /**\n   * The HTTP **`X-Forwarded-Host`** (XFH) [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a de-facto standard header for identifying the original host requested by the client in the [Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host) HTTP request header.\n   *\n   * Host names and ports of reverse [proxies](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server) (load balancers, CDNs) may differ from the origin server handling the request, in that case the `X-Forwarded-Host` header is useful to determine which `Host` was originally used.\n   *\n   * A standardized version of this header is the HTTP [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded) header, although it's much less frequently used.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * X-Forwarded-Host: <host>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<host>`\n   *   - : The domain name of the forwarded server.\n   *\n   * ## Examples\n   *\n   * ```http\n   * X-Forwarded-Host: id42.example-cdn.com\n   * ```\n   *\n   * ## Specifications\n   *\n   * Not part of any current specification.\n   *\n   * ## See also\n   *\n   * - [X-Forwarded-For](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For), [X-Forwarded-Proto](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto) headers\n   * - [Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host)\n   * - [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded)\n   */\n  'X-Forwarded-Host' = 'X-Forwarded-Host',\n\n  /**\n   * The HTTP **`X-Forwarded-Proto`** (XFP) [request header](https://developer.mozilla.org/en-US/docs/Glossary/request_header) is a de-facto standard header for identifying the protocol (HTTP or HTTPS) that a client used to connect to a [proxy](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server) or load balancer.\n   *\n   * Server access logs contain the protocol used between the server and the load balancer, but not the protocol used between the client and the load balancer.\n   * To determine the protocol used between the client and the load balancer, the `X-Forwarded-Proto` request header can be used.\n   *\n   * A standardized version of this header is the HTTP [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded) header, although it's much less frequently used.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * X-Forwarded-Proto: <protocol>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<protocol>`\n   *   - : The forwarded protocol (`http` or `https`).\n   *\n   * ## Examples\n   *\n   * ### X-Forwarded-Proto client protocol\n   *\n   * The following header indicates that the original request was made over HTTPS before being forwarded by a proxy or load balancer:\n   *\n   * ```http\n   * X-Forwarded-Proto: https\n   * ```\n   *\n   * ### Non-standard forms\n   *\n   * The following forms may be seen in request headers:\n   *\n   * ```http\n   * # Microsoft\n   * Front-End-Https: on\n   *\n   * X-Forwarded-Protocol: https\n   * X-Forwarded-Ssl: on\n   * X-Url-Scheme: https\n   * ```\n   *\n   * ## Specifications\n   *\n   * Not part of any current specification. The standardized version of this header is [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded).\n   *\n   * ## See also\n   *\n   * - [X-Forwarded-Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host), [X-Forwarded-For](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For) headers\n   * - [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded)\n   */\n  'X-Forwarded-Proto' = 'X-Forwarded-Proto',\n\n  /**\n   * > [!NOTE]\n   * > For more comprehensive options than offered by this header, see the [frame-ancestors](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) directive in a [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) header.\n   *\n   * The HTTP **`X-Frame-Options`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) can be used to indicate whether a browser should be allowed to render a page in a [frame](https://developer.mozilla.org/en-US/docs/HTMLElement/frame), [iframe](https://developer.mozilla.org/en-US/docs/HTMLElement/iframe), [embed](https://developer.mozilla.org/en-US/docs/HTMLElement/embed) or [object](https://developer.mozilla.org/en-US/docs/HTMLElement/object). Sites can use this to avoid [clickjacking](/en-US/docs/Web/Security/Attacks/Clickjacking) attacks, by ensuring that their content is not embedded into other sites.\n   *\n   * The added security is provided only if the user accessing the document is using a browser that supports `X-Frame-Options`.\n   *\n   *\n   * ```\n   *\n   * For more information, see the [Microsoft support article on setting this configuration using the IIS Manager](https://support.microsoft.com/en-US/office/mitigating-framesniffing-with-the-x-frame-options-header-1911411b-b51e-49fd-9441-e8301dcdcd79) user interface.\n   *\n   * ### Configuring HAProxy\n   *\n   * To configure HAProxy to send the `X-Frame-Options` header, add this to your front-end, listen, or backend configuration:\n   *\n   * ```plain\n   * rspadd X-Frame-Options:\\ SAMEORIGIN\n   * ```\n   *\n   * Alternatively, in newer versions:\n   *\n   * ```plain\n   * http-response set-header X-Frame-Options SAMEORIGIN\n   * ```\n   *\n   * ### Configuring Express\n   *\n   * To set `X-Frame-Options` to `SAMEORIGIN` using [Helmet](https://helmetjs.github.io/) add the following to your server configuration:\n   *\n   * ```js\n   * import helmet from \"helmet\";\n   *\n   * const app = express();\n   * app.use(\n   *   helmet({\n   *     xFrameOptions: { action: \"sameorigin\" },\n   *   }),\n   * );\n   * ```\n   *\n   * ## Specifications\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) directive [frame-ancestors](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors)\n   * - [ClickJacking Defenses - IEBlog](https://learn.microsoft.com/en-us/archive/blogs/ie/ie8-security-part-vii-clickjacking-defenses)\n   * - [Combating ClickJacking with X-Frame-Options - IEInternals](https://learn.microsoft.com/en-us/archive/blogs/ieinternals/combating-clickjacking-with-x-frame-options)\n   */\n  'X-Frame-Options' = 'X-Frame-Options',\n\n  /**\n   * The HTTP **`X-Permitted-Cross-Domain-Policies`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) defines a meta-policy that controls whether site resources can be accessed cross-origin by a document running in a web client like Adobe Acrobat or Microsoft Silverlight.\n   *\n   * It can be used in cases where the website needs to declare a cross-domain policy, but cannot write to the root directory of the domain.\n   *\n   * Usage of this header is less common since Adobe Flash Player and Microsoft Silverlight have been deprecated.\n   * Some security testing tools will still check for the presence of a `X-Permitted-Cross-Domain-Policies: none` header because it can mitigate the risk of an overly-permissive policy file added to your site by accident or through malicious actions.\n   *\n   *\n   * ```\n   *\n   * The `X-Permitted-Cross-Domain-Policies` header can specify a meta-policy for the HTTP response it's included in, or override a meta-policy defined in the master cross-domain policy file, if present.\n   * It takes the same values as the file's `permitted-cross-domain-policies` attribute and additionally `none-this-response`.\n   *\n   * Most commonly, it's used to prevent any access to site resources in cases where the developer does not have access to create a master cross-domain policy file in the site root.\n   *\n   * ## Examples\n   *\n   * ### Disallowing cross-domain policy files\n   *\n   * If you don't need to load application data in clients such as Adobe Flash Player or Adobe Acrobat (or legacy clients), then the header should be configured as `X-Permitted-Cross-Domain-Policies: none`:\n   *\n   * ```http\n   * X-Permitted-Cross-Domain-Policies: none\n   * ```\n   *\n   * ## Specifications\n   *\n   * Documented in the [Adobe Cross Domain Policy File Specification](https://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/CrossDomain_PolicyFile_Specification.pdf).\n   *\n   * ## See also\n   *\n   * - [Cross-Origin Resource Sharing (CORS)](/en-US/docs/Web/HTTP/Guides/CORS)\n   * - [Practical security implementation guides](/en-US/docs/Web/Security/Practical_implementation_guides)\n   * - [HTTP Observatory](/en-US/observatory/) header testing tool\n   * - [Cross Domain Configuration](https://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/xdomain.html) on adobe.com\n   * - [X-Permitted-Cross-Domain-Policies](https://github.com/OWASP/www-project-secure-headers/blob/master/tab_headers.md#x-permitted-cross-domain-policies) in OWASP Secure Headers Project\n   */\n  'X-Permitted-Cross-Domain-Policies' = 'X-Permitted-Cross-Domain-Policies',\n\n  /**\n   * The HTTP **`X-Powered-By`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) is a non-standard header for identifying the application or framework that generated the response.\n   *\n   *\n   *\n   * ## Syntax\n   *\n   * ```http\n   * X-Powered-By: <application>\n   * ```\n   *\n   * ## Directives\n   *\n   * - `<application>`\n   *   - : A string describing the server application or framework.\n   *\n   * ## Examples\n   *\n   * ### Express X-Powered-By header\n   *\n   * Express applications will usually include the `X-Powered-By` header in responses with the string `express` as the field value:\n   *\n   * ```http\n   * X-Powered-By: express\n   * ```\n   *\n   * ## Specifications\n   *\n   * Not part of any current specification.\n   *\n   * ## See also\n   *\n   * - [X-Forwarded-Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host), [X-Forwarded-For](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For), [X-Forwarded-Proto](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto) headers\n   * - [Via](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Via)\n   * - [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded)\n   */\n  'X-Powered-By' = 'X-Powered-By',\n\n  /**\n   * The **`X-Robots-Tag`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) defines how [crawlers](https://developer.mozilla.org/en-US/docs/glossary/Crawler) should index URLs.\n   * While not part of any specification, it is a de-facto standard method for communicating with search bots, web crawlers, and similar user agents.\n   * Search-related crawlers use the rules from the `X-Robots-Tag` header to adjust how to present web pages or other resources in search results.\n   *\n   * Indexing rules are defined in a `X-Robots-Tag` header or a [`\n   *\n   * ## Syntax\n   *\n   * ```http\n   * X-Robots-Tag: <indexing-rule>\n   * X-Robots-Tag: <indexing-rule>, …, <indexing-ruleN>\n   * ```\n   *\n   * An optional `<bot-name>:` specifies the user agent that the subsequent rules should apply to:\n   *\n   * ```http\n   * X-Robots-Tag: <indexing-rule>, <bot-name>: <indexing-rule>\n   * X-Robots-Tag: <bot-name>: <indexing-rule>, …, <indexing-ruleN>\n   * ```\n   *\n   * See [Specifying user agents](#specifying_user_agents) for an example.\n   *\n   * ## Directives\n   *\n   * Any of the following indexing rules may be used:\n   *\n   * - `all`\n   *   - : No restrictions for indexing or serving in search results.\n   *     This rule is the default value and has no effect if explicitly listed.\n   * - `noindex`\n   *   - : Do not show this page, media, or resource in search results.\n   *     If omitted, the page, media, or resource may be indexed and shown in search results.\n   * - `nofollow`\n   *   - : Do not follow the links on this page.\n   *     If omitted, search engines may use the links on the page to discover those linked pages.\n   * - `none`\n   *   - : Equivalent to `noindex, nofollow`.\n   * - `nosnippet`\n   *   - : Do not show a text snippet or video preview in the search results for this page.\n   *     A static image thumbnail (if available) may still be visible.\n   *     If omitted, search engines may generate a text snippet and video preview based on information found on the page.\n   *     To exclude certain sections of your content from appearing in search result snippets, use the [`data-nosnippet` HTML attribute](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag#data-nosnippet-attr).\n   * - `indexifembedded`\n   *   - : A search engine is allowed to index the content of a page if it's embedded in another page through iframes or similar HTML elements, in spite of a `noindex` rule.\n   *     `indexifembedded` only has an effect if it's accompanied by `noindex`.\n   * - `max-snippet: <number>`\n   *   - : Use a maximum of `<number>` characters as a textual snippet for this search result.\n   *     Ignored if no valid `<number>` is specified.\n   * - `max-image-preview: <setting>`\n   *   - : The maximum size of an image preview for this page in a search results.\n   *     If omitted, search engines may show an image preview of the default size.\n   *     If you don't want search engines to use larger thumbnail images, specify a `max-image-preview` value of `standard` or `none`. Values include:\n   *     - `none`\n   *       - : No image preview is to be shown.\n   *     - `standard`\n   *       - : A default image preview may be shown.\n   *     - `large`\n   *       - : A larger image preview, up to the width of the viewport, may be shown.\n   * - `max-video-preview: <number>`\n   *   - : Use a maximum of `<number>` seconds as a video snippet for videos on this page in search results.\n   *     If omitted, search engines may show a video snippet in search results, and the search engine decides how long a preview may be.\n   *     Ignored if no valid `<number>` is specified.\n   *     Special values are as follows:\n   *     - `0`\n   *       - : At most, a static image may be used, in accordance to the `max-image-preview` setting.\n   *     - `-1`\n   *       - : No video length limit.\n   * - `notranslate`\n   *   - : Don't offer translation of this page in search results.\n   *     If omitted, search engines may translate the search result title and snippet into the language of the search query.\n   * - `noimageindex`\n   *   - : Do not index images on this page.\n   *     If omitted, images on the page may be indexed and shown in search results.\n   * - `unavailable_after: <date/time>`\n   *   - : Requests not to show this page in search results after the specified `<date/time>`.\n   *     Ignored if no valid `<date/time>` is specified.\n   *     A date must be specified in a format such as [822](https://developer.mozilla.org/en-US/docs/RFC/822), [850](https://developer.mozilla.org/en-US/docs/RFC/850), or ISO 8601.\n   *\n   *     By default there is no expiration date for content.\n   *     If omitted, this page may be shown in search results indefinitely.\n   *     Crawlers are expected to considerably decrease the crawl rate of the URL after the specified date and time.\n   *\n   * ## Description\n   *\n   * Indexing rules via `<meta name=\"robots\">` and `X-Robots-Tag` are discovered when a URL is crawled.\n   * Most crawlers support rules in the `X-Robots-Tag` HTTP header that can be used in a `<meta name=\"robots\">` element.\n   *\n   * In the case of conflicting robot rules within the `X-Robots-Tag` or between the `X-Robots-Tag` HTTP header and the `<meta name=\"robots\">` element, the more restrictive rule applies.\n   * For example, if a page has both `max-snippet:50` and `nosnippet` rules, the `nosnippet` rule will apply.\n   * Indexing rules won't be discovered or applied if paths are blocked from being crawled by a `robots.txt` file.\n   *\n   * Some values are mutually exclusive, such as `index` and `noindex`, or `follow` and `nofollow`.\n   * In these cases, the crawler's behavior is undefined and may vary.\n   *\n   * ### Interaction with robots.txt\n   *\n   * If a resource is blocked from crawling through a `robots.txt` file, then any information about indexing or serving rules specified using `<meta name=\"robots\">` or the `X-Robots-Tag` HTTP header will not be detected and will therefore be ignored.\n   *\n   * A page that's blocked from crawling may still be indexed if it is referenced from another document (see the [`nofollow`](#nofollow) directive).\n   * If you want to remove a page from search indexes, `X-Robots-Tag: noindex` will typically work, but a robot must first revisit the page to detect the `X-Robots-Tag` rule.\n   *\n   * ## Examples\n   *\n   * ### Using X-Robots-Tag\n   *\n   * The following `X-Robots-Tag` header adds `noindex`, asking crawlers not to show this page, media, or resource in search results:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Date: Tue, 03 Dec 2024 17:08:49 GMT\n   * X-Robots-Tag: noindex\n   * ```\n   *\n   * ### Multiple headers\n   *\n   * The following response has two `X-Robots-Tag` headers, each with an indexing rule specified:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Date: Tue, 03 Dec 2024 17:08:49 GMT\n   * X-Robots-Tag: noimageindex\n   * X-Robots-Tag: unavailable_after: Wed, 03 Dec 2025 13:09:53 GMT\n   * ```\n   *\n   * ### Specifying user agents\n   *\n   * It's possible to specify which user agent the rules should apply to.\n   * The following example contains two `X-Robots-Tag` headers which ask that `googlebot` not follow the links on this page and that a fictional `BadBot` crawler not index the page or follow any links on it, either:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Date: Tue, 03 Dec 2024 17:08:49 GMT\n   * X-Robots-Tag: BadBot: noindex, nofollow\n   * X-Robots-Tag: googlebot: nofollow\n   * ```\n   *\n   * In the response below, the same indexing rules are defined, but in a single header.\n   * Each indexing rule applies to the user agent specified behind it:\n   *\n   * ```http\n   * HTTP/1.1 200 OK\n   * Date: Tue, 03 Dec 2024 17:08:49 GMT\n   * X-Robots-Tag: BadBot: noindex, nofollow, googlebot: nofollow\n   * ```\n   *\n   * For situations where multiple crawlers are specified along with different rules, the search engine will use the sum of the negative rules.\n   * For example:\n   *\n   * ```http\n   * X-Robots-Tag: nofollow\n   * X-Robots-Tag: googlebot: noindex\n   * ```\n   *\n   * The page containing these headers will be interpreted as having a `noindex, nofollow` rule when crawled by `googlebot`.\n   *\n   * ## Specifications\n   *\n   * Not part of any current specification.\n   *\n   * ## See also\n   *\n   * - [robots.txt](https://developer.mozilla.org/en-US/docs/Glossary/robots.txt)\n   * - [Search engine](https://developer.mozilla.org/en-US/docs/Glossary/Search_engine)\n   * - [`<meta name=\"robots\">`](/en-US/docs/Web/HTML/Reference/Elements/meta/name/robots) HTML element (\"robots tag\")\n   * - [robots.txt configuration](/en-US/docs/Web/Security/Practical_implementation_guides/Robots_txt) security guide\n   * - [Robots Exclusion Protocol](https://developer.mozilla.org/en-US/docs/RFC/9309)\n   * - [Using the X-Robots-Tag HTTP header](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag#xrobotstag) on developers.google.com\n   */\n  'X-Robots-Tag' = 'X-Robots-Tag',\n\n  /**\n   * > [!WARNING]\n   * > Even though this feature can protect users of older web browsers that don't support [CSP](https://developer.mozilla.org/en-US/docs/Glossary/CSP), in some cases, **`X-XSS-Protection` can create XSS vulnerabilities** in otherwise safe websites.\n   * > See the [Security considerations](#security_considerations) section below for more information.\n   *\n   * The HTTP **`X-XSS-Protection`** [response header](https://developer.mozilla.org/en-US/docs/Glossary/response_header) was a feature of Internet Explorer, Chrome and Safari that stopped pages from loading when they detected reflected cross-site scripting ([XSS](https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting)) attacks.\n   * These protections are largely unnecessary in modern browsers when sites implement a strong [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) that disables the use of inline JavaScript (`'unsafe-inline'`).\n   *\n   * It is recommended that you use [`Content-Security-Policy`](/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy) instead of XSS filtering.\n   *\n   *\n   * ```\n   *\n   * Nginx\n   *\n   * ```nginx\n   * add_header \"X-XSS-Protection\" \"1; mode=block\";\n   * ```\n   *\n   * ## Specifications\n   *\n   * Not part of any specifications or drafts.\n   *\n   * ## Browser compatibility\n   *\n   * ## See also\n   *\n   * - [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)\n   * - [Controlling the XSS Filter – Microsoft](https://learn.microsoft.com/en-us/archive/blogs/ieinternals/controlling-the-xss-filter)\n   * - [Understanding XSS Auditor – Virtue Security](https://www.virtuesecurity.com/understanding-xss-auditor/)\n   * - [The misunderstood X-XSS-Protection – blog.innerht.ml](https://web.archive.org/web/20230527023943/https://blog.innerht.ml/the-misunderstood-x-xss-protection/)\n   */\n  'X-XSS-Protection' = 'X-XSS-Protection',\n}\n"],"names":["HttpHeader"],"mappings":"AAEO,IAAK,aAAL,kBAAKA,iBAqCVA,YAAA,WAAA,IAAc,aAmGdA,YAAA,iBAAA,IAAoB,mBAwEpBA,YAAA,iBAAA,IAAoB,mBAyDpBA,YAAA,cAAA,IAAiB,gBA4DjBA,YAAA,aAAA,IAAgB,eA4ChBA,YAAA,eAAA,IAAkB,iBAyFlBA,YAAA,SAAW,UAqEXA,YAAA,kCAAA,IAAqC,oCAoGrCA,YAAA,8BAAA,IAAiC,gCA0CjCA,YAAA,8BAAA,IAAiC,gCAkEjCA,YAAA,6BAAA,IAAgC,+BAyDhCA,YAAA,+BAAA,IAAkC,iCAuClCA,YAAA,wBAAA,IAA2B,0BAgC3BA,YAAA,gCAAA,IAAmC,kCAiCnCA,YAAA,+BAAA,IAAkC,iCAoClCA,YAAA,MAAQ,OAkCRA,YAAA,QAAU,SAoDVA,YAAA,SAAA,IAAY,WAqCZA,YAAA,UAAA,IAAa,YA8CbA,YAAA,gCAAA,IAAmC,kCAkInCA,YAAA,uCAAA,IAA0C,yCA8G1CA,YAAA,wCAAA,IAA2C,0CA2H3CA,YAAA,gBAAkB,iBAqClBA,YAAA,sBAAA,IAAyB,wBAsEzBA,YAAA,eAAA,IAAkB,iBA8GlBA,YAAA,iBAAA,IAAoB,mBAsDpBA,YAAA,aAAe,cA0IfA,YAAA,gBAAA,IAAmB,kBA8CnBA,YAAA,qBAAA,IAAwB,uBA6CxBA,YAAA,aAAA,IAAgB,eAoFhBA,YAAA,kBAAA,IAAqB,oBAoCrBA,YAAA,kBAAA,IAAqB,oBA0BrBA,YAAA,gBAAA,IAAmB,kBAuBnBA,YAAA,kBAAA,IAAqB,oBAiErBA,YAAA,eAAA,IAAkB,iBAgElBA,YAAA,qCAAA,IAAwC,uCAmIxCA,YAAA,yBAAA,IAA4B,2BA6D5BA,YAAA,cAAA,IAAiB,gBAuCjBA,YAAA,SAAW,UAoEXA,YAAA,aAAA,IAAgB,eAiGhBA,YAAA,8BAAA,IAAiC,gCAkLjCA,YAAA,4BAAA,IAA+B,8BAiD/BA,YAAA,8BAAA,IAAiC,gCAmEjCA,YAAA,OAAS,QAwDTA,YAAA,eAAA,IAAkB,iBAkDlBA,YAAA,eAAA,IAAkB,iBA4DlBA,YAAA,MAAQ,OAuDRA,YAAA,WAAa,YAyDbA,YAAA,MAAQ,OA+CRA,YAAA,YAAA,IAAe,cAwDfA,YAAA,MAAQ,OAkFRA,YAAA,OAAS,QAkFTA,YAAA,WAAA,IAAc,aA4DdA,YAAA,SAAW,UAqDXA,YAAA,UAAY,WAoFZA,YAAA,YAAc,aAqCdA,YAAA,OAAS,QAwCTA,YAAA,OAAS,QAyDTA,YAAA,UAAA,IAAa,YAuDbA,YAAA,mBAAA,IAAsB,qBAyDtBA,YAAA,eAAA,IAAkB,iBA8DlBA,YAAA,UAAA,IAAa,YAyDbA,YAAA,qBAAA,IAAwB,uBAgFxBA,YAAA,8BAAA,IAAiC,gCAgFjCA,YAAA,kBAAA,IAAqB,oBA+DrBA,YAAA,YAAA,IAAe,cAqDfA,YAAA,eAAA,IAAkB,iBA6BlBA,YAAA,OAAS,QAgDTA,YAAA,WAAa,YAuCbA,YAAA,cAAA,IAAiB,gBAqBjBA,YAAA,MAAQ,OA+HRA,YAAA,gBAAA,IAAmB,kBAkCnBA,YAAA,yBAAA,IAA4B,2BAoE5BA,YAAA,sBAAA,IAAyB,wBA2EzBA,YAAA,SAAW,UAqBXA,YAAA,oBAAA,IAAuB,sBAsCvBA,YAAA,SAAW,UA+GXA,YAAA,SAAW,UAiDXA,YAAA,oBAAA,IAAuB,sBA2IvBA,YAAA,WAAa,YAoFbA,YAAA,wBAAuB,sBA0DvBA,YAAA,qBAAA,IAAwB,uBAuIxBA,YAAA,QAAU,SAgDVA,YAAA,UAAY,WAmHZA,YAAA,iBAAA,IAAoB,mBAkDpBA,YAAA,UAAY,WA8FZA,YAAA,WAAA,IAAc,aA0DdA,YAAA,qBAAA,IAAwB,uBA+KxBA,YAAA,aAAA,IAAgB,eAoDhBA,YAAA,aAAA,IAAgB,eAsDhBA,YAAA,MAAQ,OA0FRA,YAAA,WAAA,IAAc,aAwDdA,YAAA,qBAAA,IAAwB,uBAgFxBA,YAAA,6BAAA,IAAgC,+BAqEhCA,YAAA,+BAAA,IAAkC,iCAoElCA,YAAA,qCAAA,IAAwC,uCA0DxCA,YAAA,gBAAA,IAAmB,kBAyDnBA,YAAA,mBAAA,IAAsB,qBAuEtBA,YAAA,wBAAA,IAA2B,0BA0E3BA,YAAA,6BAAA,IAAgC,+BAyDhCA,YAAA,wBAAA,IAA2B,0BAoD3BA,YAAA,kBAAA,IAAqB,oBAuDrBA,YAAA,iBAAA,IAAoB,mBAuDpBA,YAAA,4BAAA,IAA+B,8BA6C/BA,YAAA,oBAAA,IAAuB,sBAwDvBA,YAAA,iBAAA,IAAoB,mBAkFpBA,YAAA,WAAA,IAAc,aAkHdA,YAAA,gBAAA,IAAmB,kBAqEnBA,YAAA,gBAAA,IAAmB,kBA8DnBA,YAAA,gBAAA,IAAmB,kBA0CnBA,YAAA,gBAAA,IAAmB,kBA2CnBA,YAAA,SAAA,IAAY,WA+DZA,YAAA,aAAA,IAAgB,eAyBhBA,YAAA,sBAAA,IAAyB,wBA4DzBA,YAAA,sBAAA,IAAyB,wBAgFzBA,YAAA,0BAAA,IAA6B,4BAkE7BA,YAAA,mBAAA,IAAsB,qBA8EtBA,YAAA,wBAAA,IAA2B,0BAwE3BA,YAAA,uBAAA,IAA0B,yBAwG1BA,YAAA,eAAA,IAAkB,iBA6ClBA,YAAA,SAAW,UAgEXA,YAAA,wBAAA,IAA2B,0BAmD3BA,YAAA,mCAAA,IAAsC,qCA6BtCA,YAAA,gBAAA,IAAmB,kBAoOnBA,YAAA,YAAA,IAAe,cA8CfA,YAAA,WAAA,IAAc,aA+CdA,YAAA,YAAc,aAmDdA,YAAA,mBAAA,IAAsB,qBAkKtBA,YAAA,2BAAA,IAA8B,6BAuC9BA,YAAA,uBAAA,IAA0B,yBAmE1BA,YAAA,KAAO,MA+CPA,YAAA,qBAAA,IAAwB,uBA2ExBA,YAAA,KAAO,MA4DPA,YAAA,UAAY,WAsFZA,YAAA,mBAAA,IAAsB,qBA+CtBA,YAAA,2BAAA,IAA8B,6BAyF9BA,YAAA,UAAY,WAgGZA,YAAA,mBAAA,IAAsB,qBAsItBA,YAAA,YAAA,IAAe,cAoCfA,YAAA,OAAS,QA6CTA,YAAA,MAAQ,OAsDRA,YAAA,gBAAA,IAAmB,kBA2DnBA,YAAA,qBAAA,IAAwB,uBAgDxBA,YAAA,kBAAA,IAAqB,oBAmErBA,YAAA,UAAY,WAiDZA,YAAA,QAAU,SA4QVA,YAAA,kBAAA,IAAqB,oBAqCrBA,YAAA,wBAAA,IAA2B,0BAqG3BA,YAAA,wBAAA,IAA2B,0BA2H3BA,YAAA,iBAAA,IAAoB,mBAsCpBA,YAAA,kBAAA,IAAqB,oBAuDrBA,YAAA,mBAAA,IAAsB,qBAsDtBA,YAAA,iBAAA,IAAoB,mBAwCpBA,YAAA,mCAAA,IAAsC,qCAsCtCA,YAAA,cAAA,IAAiB,gBA2KjBA,YAAA,cAAA,IAAiB,gBAkCjBA,YAAA,kBAAA,IAAqB,oBAp/UXA,cAAA,cAAA,CAAA,CAAA;"}