@unshared/client 0.2.0

package/dist/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sources":["../types/HttpHeaders.ts","../types/HttpMethods.ts","../types/HttpStatusCodes.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","export enum HttpMethod {\n\n  /**\n   * The **`CONNECT`** HTTP method requests that a [proxy](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server) establish a HTTP tunnel to a destination server, and if successful, blindly forward data in both directions until the tunnel is closed.\n   *\n   * The request target is unique to this method in that it consists of only the host and port number of the tunnel destination, separated by a colon (see [Syntax](#syntax) for details).\n   * Any [2XX successful response status code](/en-US/docs/Web/HTTP/Status#successful_responses) means that the proxy will switch to 'tunnel mode' and any data in the success response body is from the server identified by the request target.\n   *\n   * If a website is behind a proxy and it's enforced via network rules that all external traffic must pass through the proxy, the `CONNECT` method allows you to establish a [TLS](https://developer.mozilla.org/en-US/docs/Glossary/TLS) ([HTTPS](https://developer.mozilla.org/en-US/docs/Glossary/HTTPS)) connection with that website:\n   *\n   * - The client asks the proxy to tunnel the [TCP](https://developer.mozilla.org/en-US/docs/Glossary/TCP) connection to the desired destination.\n   * - The proxy server makes a secure connection to the server on behalf of the client.\n   * - Once the connection is established, the proxy server continues to relay the TCP stream to and from the client.\n   *\n   * Aside from enabling secure access to websites behind proxies, a HTTP tunnel provides a way to allow traffic that would otherwise be restricted (SSH or FTP) over the HTTP(S) protocol.\n   *\n   * `CONNECT` is a hop-by-hop method, meaning proxies will only forward the `CONNECT` request if there is another inbound proxy in front of the origin server since most origin servers do not implement `CONNECT`.\n   *\n   * > [!WARNING]\n   * > If you are running a proxy that supports `CONNECT`, restrict its use to a set of known ports or a configurable list of safe request targets.\n   * > There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic.\n   * > A loosely-configured proxy may be abused to forward traffic such as SMTP to relay spam email, for example.\n   */\n  CONNECT = 'CONNECT',\n\n  /**\n   * The **`DELETE`** HTTP method asks the server to delete a specified resource.\n   *\n   * The `DELETE` method has no defined semantics for the message body, so this should be empty.\n   */\n  DELETE = 'DELETE',\n\n  /**\n   * The **`GET`** HTTP method requests a representation of the specified resource.\n   * Requests using `GET` should only be used to request data and shouldn't contain a body.\n   *\n   * > [!NOTE]\n   * > The semantics of sending a message body in `GET` requests are undefined.\n   * > Some servers may reject the request with a [4XX client error](/en-US/docs/Web/HTTP/Status#client_error_responses) response.\n   */\n  GET = 'GET',\n\n  /**\n   * The **`HEAD`** HTTP method requests the metadata of a resource in the form of [headers](/en-US/docs/Web/HTTP/Headers) that the server would have sent if the [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) method was used instead.\n   * This method can be used in cases where a URL might produce a large download, for example, a `HEAD` request can read the [Content-Length](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length) header to check the file size before downloading the file with a `GET`.\n   *\n   * If the response to a `HEAD` request shows that a cached URL response is now outdated, the cached copy is invalidated even if no `GET` request was made.\n   *\n   * > [!WARNING]\n   * > If a response to a `HEAD` request has a body, the response body must be ignored.\n   * > Any [representation headers](https://developer.mozilla.org/en-US/docs/glossary/Representation_header) that describe the erroneous body are assumed to describe the response body that a `GET` request would have received.\n   */\n  HEAD = 'HEAD',\n\n  /**\n   * The **`OPTIONS`** HTTP method requests permitted communication options for a given URL or server.\n   * This can be used to test the allowed HTTP methods for a request, or to determine whether a request would succeed when making a CORS preflighted request.\n   * A client can specify a URL with this method, or an asterisk (`*`) to refer to the entire server.\n   */\n  OPTIONS = 'OPTIONS',\n\n  /**\n   * The **`PATCH`** HTTP method applies partial modifications to a resource.\n   *\n   * `PATCH` is somewhat analogous to the \"update\" concept found in [CRUD](https://developer.mozilla.org/en-US/docs/Glossary/CRUD) (in general, HTTP is different than [CRUD](https://developer.mozilla.org/en-US/docs/Glossary/CRUD), and the two should not be confused).\n   *\n   * In comparison with [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT), a `PATCH` serves as a set of instructions for modifying a resource, whereas `PUT` represents a complete replacement of the resource.\n   * A `PUT` request is always [idempotent](https://developer.mozilla.org/en-US/docs/Glossary/idempotent) (repeating the same request multiple times results in the resource remaining in the same state), whereas a `PATCH` request may not always be idempotent.\n   * For instance, if a resource includes an auto-incrementing counter, a `PUT` request will overwrite the counter (since it replaces the entire resource), but a `PATCH` request may not.\n   *\n   * Like [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST), a `PATCH` request can potentially have side effects on other resources.\n   *\n   * A server can advertise support for `PATCH` by adding it to the list in the [Allow](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Allow) or [Access-Control-Allow-Methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods) (for [CORS](/en-US/docs/Web/HTTP/CORS)) response headers.\n   * Another implicit indication that `PATCH` is supported is the [Accept-Patch](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Patch) header (usually after an [OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/OPTIONS) request on a resource), which lists the media-types the server is able to understand in a `PATCH` request for a resource.\n   */\n  PATCH = 'PATCH',\n\n  /**\n   * The **`POST`** HTTP method sends data to the server. The type of the body of the request is indicated by the [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) header.\n   *\n   * The difference between [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT) and `POST` is that `PUT` is [idempotent](https://developer.mozilla.org/en-US/docs/Glossary/idempotent): calling it once is no different from calling it several times successively (there are no _side_ effects).\n   * Successive identical `POST` requests may have additional effects, such as creating the same order several times.\n   *\n   * [HTML forms](/en-US/docs/Learn/Forms) typically send data using `POST` and this usually results in a change on the server.\n   * For HTML forms the format/encoding of the body content is determined by the [`enctype`](/en-US/docs/Web/HTML/Element/form#enctype) attribute of the [form](https://developer.mozilla.org/en-US/docs/HTMLElement/form) element or the [`formenctype`](/en-US/docs/Web/HTML/Element/input#formenctype) attribute of the [input\") }} or _or_{{HTMLElement(\"button) elements.\n   * The encoding may be one of the following:\n   *\n   * - `application/x-www-form-urlencoded`: the keys and values are encoded in key-value tuples separated by an ampersand (`&`), with an equals symbol (`=`) between the key and the value (e.g., `first-name=Frida&last-name=Kahlo`).\n   * Non-alphanumeric characters in both keys and values are [percent-encoded](https://developer.mozilla.org/en-US/docs/Glossary/Percent-encoding): this is the reason why this type is not suitable to use with binary data and you should use `multipart/form-data` for this purpose instead.\n   * - `multipart/form-data`: each value is sent as a block of data (\"body part\"), with a user agent-defined delimiter (for example, `boundary=\"delimiter12345\"`) separating each part.\n   * The keys are described in the [Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) header of each part or block of data.\n   * - `text/plain`\n   *\n   * When the `POST` request is sent following a [fetch()](https://developer.mozilla.org/en-US/docs/domxref/Window/fetch) call, or for any other reason than an HTML form, the body can be any type.\n   * As described in the HTTP 1.1 specification, `POST` is designed to allow a uniform method to cover the following functions:\n   *\n   * - Annotation of existing resources\n   * - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles\n   * - Adding a new user through a signup form\n   * - Providing a block of data, such as the result of submitting a form, to a data-handling process\n   * - Extending a database through an append operation\n   */\n  POST = 'POST',\n\n  /**\n   * The **`PUT`** HTTP method creates a new resource or replaces a representation of the target resource with the request [content](https://developer.mozilla.org/en-US/docs/Glossary/HTTP_Content).\n   *\n   * The difference between `PUT` and [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) is that `PUT` is [idempotent](https://developer.mozilla.org/en-US/docs/Glossary/idempotent): calling it once is no different from calling it several times successively (there are no _side_ effects).\n   */\n  PUT = 'PUT',\n\n  /**\n   * The **`TRACE`** HTTP method performs a message loop-back test along the path to the target resource.\n   *\n   * The final recipient of the request should reflect the message as received (excluding any fields that might include sensitive data) back to the client as the message body of a [200 OK](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) response with a [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) of `message/http`.\n   * The final recipient is either the origin server or the first server to receive a [Max-Forwards](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Max-Forwards) value of `0` in the request.\n   *\n   * The client must not send [content](https://developer.mozilla.org/en-US/docs/Glossary/HTTP_Content) in the request, or generate headers that might include sensitive data such as user credentials or cookies.\n   * Not all servers implement the `TRACE` method, and some server owners have historically disallowed the use of the `TRACE` method due to security concerns.\n   * In such cases, a [405 Method Not Allowed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405) [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) will be sent.\n   */\n  TRACE = 'TRACE',\n}\n","export enum HttpStatusCode {\n\n  /**\n   * The HTTP **`100 Continue`** [informational response](/en-US/docs/Web/HTTP/Status#informational_responses) status code indicates that the initial part of a request has been received and has not yet been rejected by the server.\n   * The client should continue with a request or discard the 100 response if the request is already finished.\n   *\n   * When a request has an [Expect: 100-continue](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect) header, the 100 Continue response indicates that the server is ready or capable of receiving the request content.\n   * Waiting for a 100 Continue 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  CONTINUE = 100,\n\n  /**\n   * The HTTP **`101 Switching Protocols`** [informational response](/en-US/docs/Web/HTTP/Status#informational_responses) status code indicates the protocol that a server has switched to.\n   * The protocol is specified in the [Upgrade](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade) request header received from a client.\n   *\n   * The server includes an [Upgrade](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade) header in this response to indicate the protocol it has agreed to switch to.\n   * The process is described in detail in the [Protocol upgrade mechanism](/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism) guide.\n   */\n  SWITCHING_PROTOCOLS = 101,\n\n  /**\n   * The HTTP **`102 Processing`** [informational response](/en-US/docs/Web/HTTP/Status#informational_responses) status code indicates to client that a full request has been received and the server is working on it.\n   * This status code is only sent if the server expects the request to take significant time.\n   *\n   * > [!NOTE]\n   * > Regular web servers do not return this response.\n   * > This status code was first introduced in Web Distributed Authoring and Versioning ([WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV)) [2518](https://developer.mozilla.org/en-US/docs/RFC/2518), but it was removed from WebDAV in [4918](https://developer.mozilla.org/en-US/docs/RFC/4918).\n   */\n  PROCESSING = 102,\n\n  /**\n   * The HTTP **`103 Early Hints`** [informational response](/en-US/docs/Web/HTTP/Status#informational_responses) may be sent by a server while it is still preparing a response, with hints about the sites and resources that the server expects the final response will link to.\n   * This allows a browser to [preconnect](/en-US/docs/Web/HTML/Attributes/rel/preconnect) to sites or start [preloading](/en-US/docs/Web/HTML/Attributes/rel/preload) resources even before the server has prepared and sent a final response.\n   * Preloaded resources indicated by early hints are fetched by the client as soon as the hints are received.\n   *\n   * The early hint response is primarily intended for use with the [Link](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link) header, which indicates the resources to be loaded.\n   * It may also contain a [`Content-Security-Policy`](/en-US/docs/Web/HTTP/CSP) header that is enforced while processing the early hint.\n   *\n   * A server might send multiple `103` responses, for example, following a redirect.\n   * Browsers only process the first early hints response, and this response must be discarded if the request results in a cross-origin redirect.\n   *\n   * > [!NOTE]\n   * > For compatibility and security reasons, it is recommended to [only send HTTP `103 Early Hints` responses over HTTP/2 or later](https://www.rfc-editor.org/rfc/rfc8297#section-3) unless the client is known to handle informational responses correctly.\n   * >\n   * > Most browsers limit support to HTTP/2 or later for this reason. See [browser compatibility](#browser_compatibility) below.\n   * > Despite this, the examples below use HTTP/1.1-style notation as per usual convention.\n   */\n  EARLY_HINTS = 103,\n\n  /**\n   * The HTTP **`200 OK`** [successful response](/en-US/docs/Web/HTTP/Status#successful_responses) status code indicates that a request has succeeded.\n   * A `200 OK` response is cacheable by default.\n   *\n   * A `200 OK` response has a different meaning and format depending on the HTTP request method.\n   * Here's how they vary for different methods:\n   *\n   * - [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET): A resource was retrieved by the server and included in the response body.\n   * - [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST): An action succeeded; the response has a message body describing the result.\n   * - [HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/HEAD): Identical to `GET`, except there is no message body.\n   * - [TRACE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/TRACE): The response has a message body containing the request as received by the server.\n   *\n   * Although possible, successful [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT) or [DELETE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/DELETE) requests often do not result in a `200 OK` response.\n   * It is more common to see [201 Created](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201) if the resource is uploaded or created for the first time, or [204 No Content](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204) upon successful deletion of a resource.\n   */\n  OK = 200,\n\n  /**\n   * The HTTP **`201 Created`** [successful response](/en-US/docs/Web/HTTP/Status#successful_responses) status code indicates that the HTTP request has led to the creation of a resource.\n   * This status code is commonly sent as the result of a [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) request.\n   *\n   * The new resource, or a description and link to the new resource, is created before the response is returned.\n   * The newly-created items are returned in the body of the message, located at either the **URL of the initial request** or the URL in the value of the [Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location) header in the response.\n   */\n  CREATED = 201,\n\n  /**\n   * The HTTP **`202 Accepted`** [successful response](/en-US/docs/Web/HTTP/Status#successful_responses) status code indicates that a request has been accepted for processing, but processing has not been completed or may not have started.\n   * The actual processing of the request is not guaranteed; a task or action may fail or be disallowed when a server tries to process it.\n   *\n   * A `202` response is non-committal, meaning there is no way to later send an asynchronous HTTP response to indicate the outcome of the processing.\n   * This response code is typically used when the request is handled by another process or server, or when requests are processed in batches.\n   */\n  ACCEPTED = 202,\n\n  /**\n   * The HTTP **`203 Non-Authoritative Information`** [successful response](/en-US/docs/Web/HTTP/Status#successful_responses) status code indicates that the request was successful, but a _transforming [proxy](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server)_ has modified the headers or enclosed content from the origin server's [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) (`OK`) response.\n   *\n   * The purpose of this status code is to allow transforming proxies to notify clients when changes have been applied to successful responses, since this may impact decisions regarding the content later.\n   * Transformations to messages can mean modifications of headers to indicate that a resource is from a mirror or a backup, but may also mean modifying content in a way that are presumed to be desirable to the client.\n   * These modifications might include malware filtering, format transcoding, privacy filtering, or other hints to the client about future requests.\n   *\n   * The `203` response is similar to the [`214`](/en-US/docs/Web/HTTP/Headers/Warning#warning_codes) `Transformation Applied` value of the deprecated [Warning](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Warning) header, which may be applicable to responses with any status code.\n   */\n  NON_AUTHORITATIVE_INFORMATION = 203,\n\n  /**\n   * The HTTP **`204 No Content`** [successful response](/en-US/docs/Web/HTTP/Status#successful_responses) status code indicates that a request has succeeded, but the client doesn't need to navigate away from its current page.\n   * A `204` response is cacheable by default, and an [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) header is included in such cases.\n   *\n   * A `204 No Content` in response to these request methods has the following meaning and results:\n   *\n   * - [DELETE](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/DELETE): The action was successful, and no further information needs to be supplied.\n   * - [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT): The action was successful, and the [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) value contains the entity tag for the new representation of that target resource.\n   *\n   * A `204` response can be used when implementing \"save and continue editing\" functionality for applications like wiki sites.\n   * In this case, a [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT) request could be used to save the page contents, and a `204 No Content` response indicates to the browser that the editor should not be replaced by other content.\n   */\n  NO_CONTENT = 204,\n\n  /**\n   * The HTTP **`205 Reset Content`** [successful response](/en-US/docs/Web/HTTP/Status#successful_responses) status code indicates that the request has been successfully processed and the client should reset the document view.\n   *\n   * This response is intended to support use cases where the user receives content that supports data entry, submits user-edited data in a request, and the content needs to be reset for the next entry.\n   * The instruction to \"reset content\" can mean clearing the contents of a form, resetting a canvas state, or refreshing a UI; the implementation depends on the client.\n   *\n   * > [!NOTE]\n   * > In web applications that use the `205` status, it's assumed that the client handles resetting content after a `205` response.\n   * > This is typically done via JavaScript, as resetting content such as forms after a `205` response is not handled natively by browsers.\n   *\n   * There must be no content in the response body, and this can be indicated using [Content-Length: 0](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length) header or [Transfer-Encoding: chunked](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding) header with an empty chunk.\n   */\n  RESET_CONTENT = 205,\n\n  /**\n   * The HTTP **`206 Partial Content`** [successful response](/en-US/docs/Web/HTTP/Status#successful_responses) status code is sent in response to a [range request](/en-US/docs/Web/HTTP/Range_requests).\n   * The response body contains the requested ranges of data as specified in the [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) header of the request.\n   *\n   * The format of the response depends on the number of ranges requested.\n   * If a single range is requested, the [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) of the entire response is set to the type of the document, and a [Content-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range) is provided.\n   * If several ranges are requested, the [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) is set to `multipart/byteranges`, and each fragment covers one range, with its own [Content-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range) and [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) headers describing it.\n   */\n  PARTIAL_CONTENT = 206,\n\n  /**\n   * The HTTP **`207 Multi-Status`** [successful response](/en-US/docs/Web/HTTP/Status#successful_responses) status code indicates a mixture of responses.\n   * This response is used exclusively in the context of Web Distributed Authoring and Versioning ([WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV)).\n   *\n   * The response body is a `text/xml` or `application/xml` HTTP entity with a `multistatus` root element that lists individual response codes.\n   *\n   * > [!NOTE]\n   * > Browsers accessing web pages will never encounter this status code.\n   * > The ability to return a _collection of resources_ is part of the [WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV) protocol and is only encountered by web applications that access a WebDAV server.\n   */\n  MULTI_STATUS = 207,\n\n  /**\n   * The HTTP **`208 Already Reported`** [successful response](/en-US/docs/Web/HTTP/Status#successful_responses) status code is used in a [207 Multi-Status](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/207) response to save space and avoid conflicts.\n   * This response is used exclusively in the context of Web Distributed Authoring and Versioning ([WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV)).\n   *\n   * If the same resource is requested several times (for example, as part of a collection) with different paths, only the first one is reported with [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200).\n   * Responses for all other bindings will report with this `208` status code, so no conflicts are created and the response stays shorter.\n   *\n   * > [!NOTE]\n   * > The ability to _bind_ a resource to several paths is an extension to the [WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV) protocol (it may be received by web applications accessing a WebDAV server).\n   * > Browsers accessing web pages will never encounter this status code.\n   */\n  ALREADY_REPORTED = 208,\n\n  /**\n   * The HTTP **`226 IM Used`** [successful response](/en-US/docs/Web/HTTP/Status#successful_responses) status code indicates that the server is returning a [delta](https://developer.mozilla.org/en-US/docs/Glossary/delta) in response to a [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) request.\n   * It is used in the context of _HTTP delta encodings_.\n   *\n   * IM stands for _instance manipulation_, which refers to the algorithm generating a _delta_.\n   * In delta encoding, a client sends a [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) request with two headers: `A-IM:`, which indicates a preference for a differencing algorithm, and [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match), which specifies the version of a resource it has.\n   * The server responds with deltas relative to a given base document, rather than the document in full.\n   * This response uses the `226` status code, an `IM:` header that describes the differencing algorithm used, and may include a `Delta-Base:` header with the [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) matching the base document associated to the delta.\n   *\n   * > [!WARNING]\n   * > Poor support for HTTP delta encodings means there are few implementations.\n   * > Instead, most systems rely solely on [compression methods](/en-US/docs/Web/HTTP/Compression) to reduce bandwidth, although a combination of compression and delta encodings is possible.\n   * >\n   * > Even if the client and server support delta encodings, proxies or caches may not, and the complexity of adding HTTP delta encodings to a system may outweigh the benefits.\n   */\n  IM_USED = 226,\n\n  /**\n   * The HTTP **`300 Multiple Choices`** [redirection response](/en-US/docs/Web/HTTP/Status#redirection_messages) status code indicates that the request has more than one possible response.\n   * The user-agent or the user should choose one of them.\n   *\n   * > [!NOTE]\n   * > In [agent-driven content negotiation](/en-US/docs/Web/HTTP/Content_negotiation#agent-driven_negotiation), a client and server collaboratively decide the best variant of a given resource when the server has multiple variants.\n   * > Most clients lack a method for automatically choosing from responses, and the additional round-trips slow down client-server interaction.\n   * > [Server-driven content negotiation](/en-US/docs/Web/HTTP/Content_negotiation#server-driven_content_negotiation) is far more common, where a server chooses the most appropriate resource for the client based on the request headers ([Accept-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language), [Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept), etc.).\n   *\n   * The server should include content in the response that contains a list of resource metadata and URIs from which the user or user agent can choose.\n   * The format of the content is implementation-specific, but should be easily parsed by the user agent (such as HTML or JSON).\n   *\n   * If the server has a preferred choice that the client should request, it can include it in a [Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location) header.\n   */\n  MULTIPLE_CHOICES = 300,\n\n  /**\n   * The HTTP **`301 Moved Permanently`** [redirection response](/en-US/docs/Web/HTTP/Status#redirection_messages) status code indicates that the requested resource has been permanently moved to the URL in the [Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location) header.\n   *\n   * A browser receiving this status will automatically request the resource at the URL in the `Location` header, redirecting the user to the new page.\n   * Search engines receiving this response will attribute links to the original URL to the redirected resource, passing the [SEO](https://developer.mozilla.org/en-US/docs/Glossary/SEO) ranking to the new URL.\n   *\n   * > [!NOTE]\n   * > In the [Fetch Standard](https://fetch.spec.whatwg.org/#http-redirect-fetch), when a user agent receives a `301` in response to a [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) request, it uses the [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) method in the subsequent redirection request, as permitted by the HTTP [specification](#specifications).\n   * > To avoid user agents modifying the request, use [308 Permanent Redirect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308) instead, as altering the method after a `308` response is prohibited.\n   */\n  MOVED_PERMANENTLY = 301,\n\n  /**\n   * The HTTP **`302 Found`** [redirection response](/en-US/docs/Web/HTTP/Status#redirection_messages) status code indicates that the requested resource has been temporarily moved to the URL in the [Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location) header.\n   *\n   * A browser receiving this status will automatically request the resource at the URL in the `Location` header, redirecting the user to the new page.\n   * Search engines receiving this response will not attribute links to the original URL to the new resource, meaning no [SEO](https://developer.mozilla.org/en-US/docs/Glossary/SEO) value is transferred to the new URL.\n   *\n   * > [!NOTE]\n   * > In the [Fetch Standard](https://fetch.spec.whatwg.org/#http-redirect-fetch), when a user agent receives a `302` in response to a [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) request, it uses the [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) method in the subsequent redirection request, as permitted by the HTTP [specification](#specifications).\n   * > To avoid user agents modifying the request, use [307 Temporary Redirect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307) instead, as altering the method after a `307` response is prohibited.\n   * >\n   * > In cases where you want any request method to be changed to [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET), use [303 See Other](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/303).\n   * > This is useful when you want to give a response to a [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT) method that is not the uploaded resource but a confirmation message such as: \"you successfully uploaded XYZ\".\n   */\n  FOUND = 302,\n\n  /**\n   * The HTTP **`303 See Other`** [redirection response](/en-US/docs/Web/HTTP/Status#redirection_messages) status code indicates that the browser should redirect to the URL in the [Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location) header instead of rendering the requested resource.\n   *\n   * This response code is often sent back as a result of [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT) or [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) methods so the client may retrieve a confirmation, or view a representation of a real-world object (see [HTTP range-14](https://en.wikipedia.org/wiki/HTTPRange-14)).\n   * The method to retrieve the redirected resource is always [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET).\n   */\n  SEE_OTHER = 303,\n\n  /**\n   * The HTTP **`304 Not Modified`** [redirection response](/en-US/docs/Web/HTTP/Status#redirection_messages) status code indicates that there is no need to retransmit the requested resources.\n   *\n   * This response code is sent when the request is a [conditional](/en-US/docs/Web/HTTP/Conditional_requests) [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 with an [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match) or an [If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since) header and the condition evaluates to 'false'.\n   * It confirms that the resource cached by the client is still valid and that the server would have sent a [200 OK](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) response with the resource if the condition evaluated to 'true'.\n   * See [HTTP caching](/en-US/docs/Web/HTTP/Caching) for more information.\n   *\n   * The response must not contain a body and must include the headers that would have been sent in an equivalent [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) response, such as:\n   *\n   * - [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)\n   * - [Content-Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Location)\n   * - [Date](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date)\n   * - [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag)\n   * - [Expires](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires)\n   * - [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary)\n   *\n   * > [!NOTE]\n   * > Many [developer tools' network panels](https://firefox-source-docs.mozilla.org/devtools-user/network_monitor/index.html) of browsers create extraneous requests leading to `304` responses, so that access to the local cache is visible to developers.\n   */\n  NOT_MODIFIED = 304,\n\n  /**\n   * The HTTP **`307 Temporary Redirect`** [redirection response](/en-US/docs/Web/HTTP/Status#redirection_messages) status code indicates that the resource requested has been temporarily moved to the URL in the [Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location) header.\n   *\n   * A browser receiving this status will automatically request the resource at the URL in the `Location` header, redirecting the user to the new page.\n   * Search engines receiving this response will not attribute links to the original URL to the new resource, meaning no [SEO](https://developer.mozilla.org/en-US/docs/Glossary/SEO) value is transferred to the new URL.\n   *\n   * The method and the body of the original request are reused to perform the redirected request.\n   * In the cases where you want the request method to be changed to [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET), use [303 See Other](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/303) instead.\n   * This is useful when you want to give an answer to a successful [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/PUT) request that is not the uploaded resource, but a status monitor or confirmation message like \"You have successfully uploaded XYZ\".\n   *\n   * The difference between `307` and [302](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302) is that `307` guarantees that the client **will not change** the request method and body when the redirected request is made.\n   * With `302`, older clients incorrectly changed the method to [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET).\n   * `307` and `302` responses are identical when the request method is [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET).\n   */\n  TEMPORARY_REDIRECT = 307,\n\n  /**\n   * The HTTP **`308 Permanent Redirect`** [redirection response](/en-US/docs/Web/HTTP/Status#redirection_messages) status code indicates that the requested resource has been permanently moved to the URL given by the [Location](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location) header.\n   *\n   * A browser receiving this status will automatically request the resource at the URL in the `Location` header, redirecting the user to the new page.\n   * Search engines receiving this response will attribute links to the original URL to the redirected resource, passing the [SEO](https://developer.mozilla.org/en-US/docs/Glossary/SEO) ranking to the new URL.\n   *\n   * The request method and the body **will not be modified** by the client in the redirected request.\n   * A [301 Moved Permanently](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301) requires the request method and the body to remain unchanged when redirection is performed, but this is incorrectly handled by older clients to use the [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) method instead.\n   *\n   * > [!NOTE]\n   * > Some Web applications may use the `308 Permanent Redirect` in a non-standard way and for different purposes.\n   * > For example, Google Drive uses a `308 Resume Incomplete` response to indicate to the client when an unfinished upload has stalled.\n   * > See [Perform a resumable download](https://developers.google.com/drive/api/guides/manage-uploads) on the Google Drive documentation for more information.\n   */\n  PERMANENT_REDIRECT = 308,\n\n  /**\n   * The HTTP **`400 Bad Request`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server would not process the request due to something the server considered to be a client error.\n   * The reason for a `400` response is typically due to malformed request syntax, invalid request message framing, or deceptive request routing.\n   *\n   * Clients that receive a `400` response should expect that repeating the request without modification will fail with the same error.\n   */\n  BAD_REQUEST = 400,\n\n  /**\n   * The HTTP **`401 Unauthorized`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource.\n   * This status code is sent with an HTTP [WWW-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate) response header that contains information on the [authentication scheme](/en-US/docs/Web/HTTP/Authentication#authentication_schemes) the server expects the client to include to make the request successfully.\n   *\n   * A `401 Unauthorized` is similar to the [403 Forbidden](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403) response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.\n   */\n  UNAUTHORIZED = 401,\n\n  /**\n   * The HTTP **`402 Payment Required`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code is a **nonstandard** response status code reserved for future use.\n   *\n   * This status code was created to enable digital cash or (micro) payment systems and would indicate that requested content is not available until the client makes a payment.\n   * No standard use convention exists and different systems use it in different contexts.\n   */\n  PAYMENT_REQUIRED = 402,\n\n  /**\n   * The HTTP **`403 Forbidden`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server understood the request but refused to process it.\n   * This status is similar to [401](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401), except that for **`403 Forbidden`** responses, authenticating or re-authenticating makes no difference.\n   * The request failure is tied to application logic, such as insufficient permissions to a resource or action.\n   *\n   * Clients that receive a `403` response should expect that repeating the request without modification will fail with the same error.\n   * Server owners may decide to send a [404](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404) response instead of a 403 if acknowledging the existence of a resource to clients with insufficient privileges is not desired.\n   */\n  FORBIDDEN = 403,\n\n  /**\n   * The HTTP **`404 Not Found`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server cannot find the requested resource.\n   * Links that lead to a 404 page are often called broken or dead links and can be subject to [link rot](https://en.wikipedia.org/wiki/Link_rot).\n   *\n   * A 404 status code only indicates that the resource is missing without indicating if this is temporary or permanent.\n   * If a resource is permanently removed, servers should send the [410 Gone](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/410) status instead.\n   *\n   * 404 errors on a website can lead to a poor user experience for your visitors, so the number of broken links (internal and external) should be minimized to prevent frustration for readers.\n   * Common causes of 404 responses are mistyped URLs or pages that are moved or deleted without redirection.\n   * For more information, see the [Redirections in HTTP](/en-US/docs/Web/HTTP/Redirections) guide.\n   */\n  NOT_FOUND = 404,\n\n  /**\n   * The HTTP **`405 Method Not Allowed`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server knows the request method, but the target resource doesn't support this method.\n   * The server **must** generate an [Allow](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Allow) header in a 405 response with a list of methods that the target resource currently supports.\n   *\n   * Improper server-side permissions set on files or directories may cause a 405 response when the request would otherwise be expected to succeed.\n   */\n  METHOD_NOT_ALLOWED = 405,\n\n  /**\n   * The HTTP **`406 Not Acceptable`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server could not produce a response matching the list of acceptable values defined in the request's [proactive content negotiation](/en-US/docs/Web/HTTP/Content_negotiation#server-driven_content_negotiation) headers and that the server was unwilling to supply a default representation.\n   *\n   * Proactive content negotiation headers include:\n   *\n   * - [Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept)\n   * - [Accept-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding)\n   * - [Accept-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language)\n   *\n   * A server may return responses that differ from the request's accept headers.\n   * In such cases, a [200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200) response with a default resource that doesn't match the client's list of acceptable content negotiation values may be preferable to sending a 406 response.\n   *\n   * If a server returns a 406, the body of the message should contain the list of available representations for the resource, allowing the user to choose, although no standard way for this is defined.\n   */\n  NOT_ACCEPTABLE = 406,\n\n  /**\n   * The HTTP **`407 Proxy Authentication Required`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the request did not succeed because it lacks valid authentication credentials for the [proxy server](https://developer.mozilla.org/en-US/docs/Glossary/proxy_server) that sits between the client and the server with access to the requested resource.\n   *\n   * This response is sent with a [Proxy-Authenticate](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authenticate) header that contains information on how to correctly authenticate requests.\n   * The client may repeat the request with a new or replaced [Proxy-Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authorization) header field.\n   */\n  PROXY_AUTHENTICATION_REQUIRED = 407,\n\n  /**\n   * The HTTP **`408 Request Timeout`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server would like to shut down this unused connection.\n   * A `408` is sent on an idle connection by some servers, _even without any previous request by the client_.\n   *\n   * A server should send the [Connection: close](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection) header field in the response, since `408` implies that the server has decided to close the connection rather than continue waiting.\n   *\n   * This response is used much more since some browsers, like Chrome and Firefox, use HTTP pre-connection mechanisms to speed up surfing.\n   *\n   * > [!NOTE]\n   * > Some servers will shut down a connection without sending this message.\n   */\n  REQUEST_TIMEOUT = 408,\n\n  /**\n   * The HTTP **`409 Conflict`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates a request conflict with the current state of the target resource.\n   *\n   * In [WebDAV](https://developer.mozilla.org/en-US/docs/glossary/WebDAV) remote web authoring, 409 conflict responses are errors sent to the client so that a user might be able to resolve a conflict and resubmit the request.\n   * For example, conflicts occur if a request to create collection `/a/b/c/d/` is made, and `/a/b/c/` does not exist, the request must fail with a 409.\n   * Additionally, you may get a 409 response when uploading a file that is older than the existing one on the server, resulting in a version control conflict.\n   *\n   * In other systems, 409 responses may be used for implementation-specific purposes, such as to indicate that the server has received multiple requests to update the same resource.\n   */\n  CONFLICT = 409,\n\n  /**\n   * The HTTP **`410 Gone`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the target resource is no longer available at the origin server and that this condition is likely to be permanent.\n   * A 410 response is cacheable by default.\n   *\n   * Clients should not repeat requests for resources that return a 410 response, and website owners should remove or replace links that return this code.\n   * If server owners don't know whether this condition is temporary or permanent, a  status code should be used instead.\n   */\n  GONE = 410,\n\n  /**\n   * The HTTP **`411 Length Required`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server refused to accept the request without a defined [Content-Length](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length) header.\n   *\n   * > [!NOTE]\n   * > When sending data in a series of chunks, the `Content-Length` header is omitted, and at the beginning of each chunk, the length of the current chunk needs to be included in hexadecimal format.\n   * > See [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding) for more details.\n   */\n  LENGTH_REQUIRED = 411,\n\n  /**\n   * The HTTP **`412 Precondition Failed`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that access to the target resource was denied.\n   * This happens with [conditional requests](/en-US/docs/Web/HTTP/Conditional_requests) on methods other than [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) when the condition defined by the [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since) or [If-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match) headers is not fulfilled.\n   * In that case, the request (usually an upload or a modification of a resource) cannot be made and this error response is sent back.\n   */\n  PRECONDITION_FAILED = 412,\n\n  /**\n   * The HTTP **`413 Content Too Large`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the request entity was larger than limits defined by server.\n   * The server might close the connection or return a [Retry-After](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) header field.\n   *\n   * Prior to [9110](https://developer.mozilla.org/en-US/docs/rfc/9110) the response phrase for the status was **`Payload Too Large`**.\n   * This message is still widely used.\n   */\n  CONTENT_TOO_LARGE = 413,\n\n  /**\n   * The HTTP **`414 URI Too Long`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that a URI requested by the client was longer than the server is willing to interpret.\n   *\n   * There are a few rare conditions when this error might occur:\n   *\n   * - a client has improperly converted a [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/POST) request to a [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Method/GET) request with long query information,\n   * - a client has descended into a loop of redirection (for example, a redirected URI prefix that points to a suffix of itself), or\n   * - the server is under attack by a client attempting to exploit potential security holes.\n   *\n   * Some systems implement `414 URI Too Long` as `414 Request-URI Too Large`.\n   */\n  URI_TOO_LONG = 414,\n\n  /**\n   * The HTTP **`415 Unsupported Media Type`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server refused to accept the request because the message [content](https://developer.mozilla.org/en-US/docs/Glossary/HTTP_Content) format is not supported.\n   *\n   * The format problem might be due to the request's indicated [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) or [Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding), or as a result of processing the request message content.\n   * Some servers may be strict about the expected `Content-Type` of requests.\n   * For example, sending `UTF8` instead of `UTF-8` to specify the [UTF-8](https://developer.mozilla.org/en-US/docs/glossary/UTF-8) charset may cause the server to consider the media type invalid.\n   */\n  UNSUPPORTED_MEDIA_TYPE = 415,\n\n  /**\n   * The HTTP **`416 Range Not Satisfiable`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that a server could not serve the requested ranges.\n   * The most likely reason for this response is that the document doesn't contain such [ranges](/en-US/docs/Web/HTTP/Range_requests), or that the [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) header value, though syntactically correct, doesn't make sense.\n   *\n   * The `416` response message should contain a [Content-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range) indicating an unsatisfied range (that is a `'*'`) followed by a `'/'` and the current length of the resource, e.g., `Content-Range: bytes * /12777`\n   *\n   * When encountering this error, browsers typically either abort the operation (for example, a download will be considered non-resumable) or request the whole document again without ranges.\n   */\n  RANGE_NOT_SATISFIABLE = 416,\n\n  /**\n   * The HTTP **`417 Expectation Failed`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the expectation given in the request's [Expect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect) header could not be met.\n   * After receiving a 417 response, a client should repeat the request without an `Expect` request header, including the file in the request body without waiting for a [100](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100) response.\n   * See the [Expect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect) header documentation for more details.\n   */\n  EXPECTATION_FAILED = 417,\n\n  /**\n   * The HTTP **`418 I'm a teapot`** status response code indicates that the server refuses to brew coffee because it is, permanently, a teapot.\n   * A combined coffee/tea pot that is temporarily out of coffee should instead return [503](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503).\n   * This error is a reference to Hyper Text Coffee Pot Control Protocol defined in April Fools' jokes in 1998 and 2014.\n   *\n   * Some websites use this response for requests they do not wish to handle, such as automated queries.\n   */\n  I_M_A_TEAPOT = 418,\n\n  /**\n   * The HTTP **`421 Misdirected Request`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the request was directed to a server that is not able to produce a response.\n   * This can be sent by a server that is not configured to produce responses for the combination of [scheme](/en-US/docs/Web/URI/Schemes) and [authority](/en-US/docs/Web/URI/Authority) that are included in the request URI.\n   *\n   * Clients may retry the request over a different connection.\n   */\n  MISDIRECTED_REQUEST = 421,\n\n  /**\n   * The HTTP **`422 Unprocessable Content`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server understood the content type of the request content, and the syntax of the request content was correct, but it was unable to process the contained instructions.\n   *\n   * Clients that receive a `422` response should expect that repeating the request without modification will fail with the same error.\n   */\n  UNPROCESSABLE_CONTENT = 422,\n\n  /**\n   * The HTTP **`423 Locked`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that a resource is _locked_, meaning it can't be accessed.\n   * Its response body should contain information in [WebDAV](https://developer.mozilla.org/en-US/docs/glossary/WebDAV)'s XML format.\n   *\n   * > [!NOTE]\n   * > The ability to _lock_ a resource to prevent conflicts is specific to some [WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV) servers.\n   * > Browsers accessing web pages will never encounter this status code; in the erroneous cases it happens, they will handle it as a generic  status code.\n   */\n  LOCKED = 423,\n\n  /**\n   * The HTTP **`424 Failed Dependency`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the method could not be performed on the resource because the requested action depended on another action, and that action failed.\n   *\n   * Regular web servers typically do not return this status code, but some protocols like [WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV) can return it.\n   * For example, in [WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV), if a `PROPPATCH` request was issued, and one command fails then automatically every other command will also fail with `424 Failed Dependency`.\n   */\n  FAILED_DEPENDENCY = 424,\n\n  /**\n   * The HTTP **`425 Too Early`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server was unwilling to risk processing a request that might be replayed to avoid potential replay attacks.\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   * A client that sends a request in early data does not need to include the `Early-Data` header.\n   * See [Early-Data](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Early-Data) for more information.\n   */\n  TOO_EARLY = 425,\n\n  /**\n   * The HTTP **`426 Upgrade Required`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server refused to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol.\n   *\n   * The server sends an [Upgrade](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade) header with this response to indicate the required protocol(s).\n   */\n  UPGRADE_REQUIRED = 426,\n\n  /**\n   * The HTTP **`428 Precondition Required`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server requires the request to be [conditional](/en-US/docs/Web/HTTP/Conditional_requests).\n   *\n   * Typically, a 428 response means that a required precondition header such as [If-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match) **is missing**.\n   * When a precondition header does **not match** the server-side state, the response should be [412 Precondition Failed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412).\n   */\n  PRECONDITION_REQUIRED = 428,\n\n  /**\n   * The HTTP **`429 Too Many Requests`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates the client has sent too many requests in a given amount of time.\n   * This mechanism of asking the client to slow down the rate of requests is commonly called \"[rate limiting](https://developer.mozilla.org/en-US/docs/glossary/rate_limit)\".\n   *\n   * A [Retry-After](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) header may be included to this response to indicate how long a client should wait before making the request again.\n   *\n   * Implementations of rate limiting vary; restrictions may be server-wide or per resource.\n   * Typically, rate-limiting restrictions are based on a client's IP but can be specific to users or authorized applications if requests are authenticated or contain a [cookie](https://developer.mozilla.org/en-US/docs/Glossary/cookie).\n   */\n  TOO_MANY_REQUESTS = 429,\n\n  /**\n   * The HTTP **`431 Request Header Fields Too Large`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the server refuses to process the request because the request's [HTTP headers](/en-US/docs/Web/HTTP/Headers) are too long.\n   * The request may be resubmitted after reducing the size of the request headers.\n   *\n   * 431 can be used when the total size of request headers is too large or when a single header field is too large.\n   * To help clients running into this error, indicate which of the two is the problem in the response body and, ideally, say which headers are too large.\n   * This lets people attempt to fix the problem, such as by clearing cookies.\n   *\n   * Servers will often produce this status if:\n   *\n   * - The [Referer](https://developer.mozilla.org/en-US/docs/httpheader/Referer) URL is too long\n   * - There are too many [Cookies](/en-US/docs/Web/HTTP/Cookies) sent in the request\n   */\n  REQUEST_HEADER_FIELDS_TOO_LARGE = 431,\n\n  /**\n   * The HTTP **`451 Unavailable For Legal Reasons`** [client error response](/en-US/docs/Web/HTTP/Status#client_error_responses) status code indicates that the user requested a resource that is not available due to legal reasons, such as a web page for which a legal action has been issued.\n   */\n  UNAVAILABLE_FOR_LEGAL_REASONS = 451,\n\n  /**\n   * The HTTP **`500 Internal Server Error`** [server error response](/en-US/docs/Web/HTTP/Status#server_error_responses) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.\n   * This error is a generic \"catch-all\" response to server issues, indicating that the server cannot find a more appropriate [5XX error](/en-US/docs/Web/HTTP/Status#server_error_responses) to respond with.\n   *\n   * If you're a visitor seeing `500` errors on a web page, these issues require investigation by server owners or administrators.\n   * There are many possible causes of `500` errors, including: improper server configuration, out-of-memory (OOM) issues, unhandled exceptions, improper file permissions, or other complex factors.\n   * Server administrators may proactively log occurrences of server error responses, like the `500` status code, with details about the initiating requests to improve the stability of a service in the future.\n   */\n  INTERNAL_SERVER_ERROR = 500,\n\n  /**\n   * The HTTP **`501 Not Implemented`** [server error response](/en-US/docs/Web/HTTP/Status#server_error_responses) status code means that the server does not support the functionality required to fulfill the request.\n   *\n   * A response with this status may also include a [Retry-After](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) header, telling the client that they can retry the request after the specified time has elapsed.\n   * A `501` response is cacheable by default unless caching headers instruct otherwise.\n   *\n   * `501` is the appropriate response when the server does not recognize the request method and is incapable of supporting it for any resource.\n   * Servers are required to support [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), and therefore must not return `501` in response to requests with these methods.\n   * If the server does recognize the method, but intentionally does not allow it, the appropriate response is [405 Method Not Allowed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405).\n   *\n   * If you have visited a web page and you are seeing `501` errors, these issues require investigation and fixing by server owners or administrators.\n   * You can clear your browser cache for the domain, disable proxies if you are using one, or try again later to see if it works as expected.\n   *\n   * A `501` response can occur if proxies cannot not handle request methods used in the context of HTTP Extension Framework ([2774](https://developer.mozilla.org/en-US/docs/RFC/2774)) applications.\n   * This status can also occur in Web Distributed Authoring and Versioning ([WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV)) when a request method (`SEARCH`, `PROPFIND`) does not have a URL handler configured to process it.\n   */\n  NOT_IMPLEMENTED = 501,\n\n  /**\n   * The HTTP **`502 Bad Gateway`** [server error response](/en-US/docs/Web/HTTP/Status#server_error_responses) status code indicates that a server was acting as a gateway or [proxy](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server) and that it received an invalid response from the upstream server.\n   *\n   * This response is similar to a [500 Internal Server Error](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/500) response in the sense that it is a generic \"catch-call\" for server errors.\n   * The difference is that it is specific to the point in the request chain that the error has occurred.\n   * If the origin server sends a valid HTTP error response to the gateway, the response should be passed on to the client instead of a `502` to make the failure reason transparent.\n   * If the proxy or gateway did not receive any HTTP response from the origin, it instead sends a [504 Gateway Timeout](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/504) to the client.\n   *\n   * There are many causes of `502` errors, and fixing such problems probably requires investigation by server owners or administrators.\n   * Exceptions are client networking errors, particularly if the service works for other visitors, and if clients use VPNs or other custom networking setups.\n   * In such cases, clients should check network settings, firewall setup, proxy settings, DNS configuration, etc.\n   */\n  BAD_GATEWAY = 502,\n\n  /**\n   * The HTTP **`503 Service Unavailable`** [server error response](/en-US/docs/Web/HTTP/Status#server_error_responses) status code indicates that the server is not ready to handle the request.\n   *\n   * Common causes are that a server is down for maintenance or overloaded.\n   * During maintenance, server administrators may temporarily route all traffic to a `503` page, or this may happen automatically during software updates.\n   * In overload cases, some server-side applications will reject requests with a `503` status when resource thresholds like memory, CPU, or connection pool limits are met.\n   * Dropping incoming requests creates backpressure that prevents the server's compute resources from being exhausted, avoiding more severe failures.\n   * If requests from specific clients are being restricted due to [rate limiting](https://developer.mozilla.org/en-US/docs/Glossary/Rate_limit), the appropriate response is [429 Too Many Requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429).\n   *\n   * This response should be used for temporary conditions and the [Retry-After](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) HTTP header should contain the estimated time for the recovery of the service, if possible.\n   *\n   * A user-friendly page explaining the problem should be sent along with this response.\n   *\n   * > [!NOTE]\n   * > Caching-related headers sent with this response require special attention; a `503` indicates a temporary issue and responses shouldn't usually be cached as clients may receive outdated error pages after a fix has been deployed.\n   */\n  SERVICE_UNAVAILABLE = 503,\n\n  /**\n   * The HTTP **`504 Gateway Timeout`** [server error response](/en-US/docs/Web/HTTP/Status#server_error_responses) status code indicates that the server, while acting as a gateway or [proxy](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server), did not get a response in time from the upstream server in order to complete the request.\n   * This is similar to a [502 Bad Gateway](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/502), except that in a `504` status, the proxy or gateway did not receive any HTTP response from the origin within a certain time.\n   *\n   * There are many causes of `504` errors, and fixing such problems likely requires investigation and debugging by server administrators, or the site may work again at a later time.\n   * Exceptions are client networking errors, particularly if the service works for other visitors, and if clients use VPNs or other custom networking setups.\n   * In such cases, clients should check network settings, firewall setup, proxy settings, DNS configuration, etc.\n   */\n  GATEWAY_TIMEOUT = 504,\n\n  /**\n   * The HTTP **`505 HTTP Version Not Supported`** [server error response](/en-US/docs/Web/HTTP/Status#server_error_responses) status code indicates that the HTTP version used in the request is not supported by the server.\n   *\n   * It's common to see this error when a request line is improperly formed such as `GET /path to resource HTTP/1.1` or with `\\n` terminating the request line instead of `\\r\\n`.\n   * For example, intermediaries such as load balancers may not handle request lines of a forwarded request as illustrated in the example below.\n   */\n  HTTP_VERSION_NOT_SUPPORTED = 505,\n\n  /**\n   * The HTTP **`506 Variant Also Negotiates`** [server error response](/en-US/docs/Web/HTTP/Status#server_error_responses) status code is returned during content negotiation when there is recursive loop in the process of selecting a resource.\n   *\n   * [Agent-driven content negotiation](/en-US/docs/Web/HTTP/Content_negotiation#agent-driven_negotiation) enables a client and server to collaboratively decide the best variant of a given resource when the server has multiple variants.\n   * A server sends a `506` status code due to server misconfiguration that results in circular references when creating responses.\n   *\n   * Lack of standardization of how clients automatically choose from responses, and the additional round-trips that slow down client-server interaction mean this mechanism is rarely used.\n   * [Server-driven content negotiation](/en-US/docs/Web/HTTP/Content_negotiation#server-driven_content_negotiation) is far more common, where a server directly chooses the most appropriate resource for the client based on the request headers ([Accept-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language), [Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept), etc.).\n   */\n  VARIANT_ALSO_NEGOTIATES = 506,\n\n  /**\n   * The HTTP **`507 Insufficient Storage`** [server error response](/en-US/docs/Web/HTTP/Status#server_error_responses) status code indicates that an action could not be performed because the server does not have enough available storage to successfully complete the request.\n   *\n   * This status code was first used in the context of Web Distributed Authoring and Versioning ([WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV)), but has propagated into other use cases to describe situations where server resources are exhausted.\n   * Common causes of this error can be from server directories running out of available space, not enough available RAM for an operation, or internal limits reached (such as application-specific memory limits, for example).\n   * The request causing this error does not necessarily need to include content, as it may be a request that would create a resource on the server if it was successful.\n   *\n   * This issue is considered temporary, as opposed to a [413 Content Too Large](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413), which indicates that the client request is too large for the server to process regardless of server resource constraints.\n   */\n  INSUFFICIENT_STORAGE = 507,\n\n  /**\n   * The HTTP **`508 Loop Detected`** [server error response](/en-US/docs/Web/HTTP/Status#server_error_responses) status code indicates that the entire operation failed because it encountered an infinite loop while processing a request with `Depth: infinity`.\n   *\n   * The status may be given in the context of the Web Distributed Authoring and Versioning ([WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV)).\n   * It was introduced as a fallback for cases where WebDAV clients do not support [208 Already Reported](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/208) responses (when requests do not explicitly include a `DAV` header).\n   */\n  LOOP_DETECTED = 508,\n\n  /**\n   * The HTTP **`510 Not Extended`** [server error response](/en-US/docs/Web/HTTP/Status#server_error_responses) status code is sent when the client request declares an HTTP Extension ([2774](https://developer.mozilla.org/en-US/docs/RFC/2774)) that should be used to process the request, but the extension is not supported.\n   */\n  NOT_EXTENDED = 510,\n\n  /**\n   * The HTTP **`511 Network Authentication Required`** [server error response](/en-US/docs/Web/HTTP/Status#server_error_responses) status code indicates that the client needs to authenticate to gain network access.\n   * This status is not generated by origin servers, but by intercepting [proxies](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server) that control access to a network.\n   *\n   * Network operators sometimes require some authentication, acceptance of terms, or other user interaction before granting access (for example in an internet café or at an airport).\n   * They often identify clients who have not done so using their Media Access Control (MAC) addresses.\n   */\n  NETWORK_AUTHENTICATION_REQUIRED = 511,\n}\n"],"names":["HttpHeader","HttpMethod","HttpStatusCode"],"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,GCDA,aAAL,kBAAKC,iBAuBVA,YAAA,UAAU,WAOVA,YAAA,SAAS,UAUTA,YAAA,MAAM,OAYNA,YAAA,OAAO,QAOPA,YAAA,UAAU,WAgBVA,YAAA,QAAQ,SA2BRA,YAAA,OAAO,QAOPA,YAAA,MAAM,OAYNA,YAAA,QAAQ,SAzHEA,cAAA,cAAA,CAAA,CAAA,GCAA,iBAAAC,kBAAAA,qBASVA,gBAAA,gBAAA,WAAW,GAAX,IAAA,YASAA,gBAAA,gBAAA,sBAAsB,GAAtB,IAAA,uBAUAA,gBAAA,gBAAA,aAAa,GAAb,IAAA,cAmBAA,gBAAA,gBAAA,cAAc,GAAd,IAAA,eAiBAA,gBAAA,gBAAA,KAAK,GAAL,IAAA,MASAA,gBAAA,gBAAA,UAAU,GAAV,IAAA,WASAA,gBAAA,gBAAA,WAAW,OAAX,YAWAA,gBAAAA,gBAAA,gCAAgC,GAAA,IAAhC,iCAcAA,gBAAAA,gBAAA,aAAa,GAAA,IAAb,cAcAA,gBAAAA,gBAAA,gBAAgB,GAAA,IAAhB,iBAUAA,gBAAAA,gBAAA,kBAAkB,GAAA,IAAlB,mBAYAA,gBAAAA,gBAAA,eAAe,GAAA,IAAf,gBAaAA,gBAAAA,gBAAA,mBAAmB,GAAA,IAAnB,oBAiBAA,gBAAAA,gBAAA,UAAU,GAAA,IAAV,WAgBAA,gBAAAA,gBAAA,mBAAmB,GAAnB,IAAA,oBAYAA,gBAAA,gBAAA,oBAAoB,GAApB,IAAA,qBAeAA,gBAAA,gBAAA,QAAQ,GAAR,IAAA,SAQAA,gBAAA,gBAAA,YAAY,GAAZ,IAAA,aAqBAA,gBAAA,gBAAA,eAAe,GAAf,IAAA,gBAgBAA,gBAAA,gBAAA,qBAAqB,GAArB,IAAA,sBAgBAA,gBAAA,gBAAA,qBAAqB,GAArB,IAAA,sBAQAA,gBAAA,gBAAA,cAAc,GAAd,IAAA,eAQAA,gBAAA,gBAAA,eAAe,GAAf,IAAA,gBAQAA,gBAAA,gBAAA,mBAAmB,GAAnB,IAAA,oBAUAA,gBAAA,gBAAA,YAAY,GAAZ,IAAA,aAaAA,gBAAA,gBAAA,YAAY,GAAZ,IAAA,aAQAA,gBAAA,gBAAA,qBAAqB,GAArB,IAAA,sBAgBAA,gBAAA,gBAAA,iBAAiB,GAAjB,IAAA,kBAQAA,gBAAA,gBAAA,gCAAgC,GAAhC,IAAA,iCAaAA,gBAAA,gBAAA,kBAAkB,GAAlB,IAAA,mBAWAA,gCAAA,WAAW,GAAA,IAAX,YASAA,gBAAAA,gBAAA,OAAO,GAAA,IAAP,QASAA,gBAAAA,gBAAA,kBAAkB,GAAA,IAAlB,mBAOAA,gBAAAA,gBAAA,sBAAsB,GAAA,IAAtB,uBASAA,gBAAAA,gBAAA,oBAAoB,GAAA,IAApB,qBAaAA,gBAAAA,gBAAA,eAAe,GAAA,IAAf,gBASAA,gBAAAA,gBAAA,yBAAyB,GAAA,IAAzB,0BAUAA,gBAAAA,gBAAA,wBAAwB,GAAA,IAAxB,yBAOAA,gBAAAA,gBAAA,qBAAqB,GAAA,IAArB,sBASAA,gBAAAA,gBAAA,eAAe,GAAA,IAAf,gBAQAA,gBAAAA,gBAAA,sBAAsB,GAAA,IAAtB,uBAOAA,gBAAAA,gBAAA,wBAAwB,GAAA,IAAxB,yBAUAA,gBAAAA,gBAAA,SAAS,GAAA,IAAT,UAQAA,gBAAAA,gBAAA,oBAAoB,GAAA,IAApB,qBASAA,gBAAAA,gBAAA,YAAY,GAAA,IAAZ,aAOAA,gBAAAA,gBAAA,mBAAmB,GAAA,IAAnB,oBAQAA,gBAAA,gBAAA,wBAAwB,GAAxB,IAAA,yBAWAA,gBAAA,gBAAA,oBAAoB,GAApB,IAAA,qBAeAA,gBAAA,gBAAA,kCAAkC,GAAlC,IAAA,mCAKAA,gBAAA,gBAAA,gCAAgC,GAAhC,IAAA,iCAUAA,gBAAA,gBAAA,wBAAwB,GAAxB,IAAA,yBAkBAA,gBAAA,gBAAA,kBAAkB,GAAlB,IAAA,mBAcAA,gBAAA,gBAAA,cAAc,GAAd,IAAA,eAkBAA,gBAAA,gBAAA,sBAAsB,GAAtB,IAAA,uBAUAA,gBAAA,gBAAA,kBAAkB,GAAlB,IAAA,mBAQAA,gBAAA,gBAAA,6BAA6B,GAA7B,IAAA,8BAWAA,gBAAA,gBAAA,0BAA0B,GAA1B,IAAA,2BAWAA,gBAAA,gBAAA,uBAAuB,GAAvB,IAAA,wBAQAA,gBAAA,gBAAA,gBAAgB,GAAhB,IAAA,iBAKAA,gBAAA,gBAAA,eAAe,GAAf,IAAA,gBASAA,gBAAA,gBAAA,kCAAkC,GAAlC,IAAA,mCAhqBUA,kBAAA,kBAAA,CAAA,CAAA;"}