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

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

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

/**
 * The 100 (Continue) status code indicates that the initial
 * part of a request has been received and has not yet been
 * rejected by the server. The server intends to send a final
 * response after the request has been fully received and acted
 * upon.
 *
 * @see [Documentation → IETF RFC 7231 §6.2.1](https://datatracker.ietf.org/doc/html/rfc7231#section-6.2.1)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode100 = 100;

/**
 * The 101 (Switching Protocols) status code indicates that the
 * server understands and is willing to comply with the
 * client's request, via the Upgrade header field, for a change
 * in the application protocol being used on this connection.
 * The server MUST generate an Upgrade header field in the
 * response that indicates which protocol(s) will be switched
 * to immediately after the empty line that terminates the 101
 * response.
 *
 * @see [Documentation → IETF RFC 7231 §6.2.2](https://datatracker.ietf.org/doc/html/rfc7231#section-6.2.2)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode101 = 101;

/**
 * The 102 (Processing) status code is an interim response used
 * to inform the client that the server has accepted the
 * complete request, but has not yet completed it. This status
 * code SHOULD only be sent when the server has a reasonable
 * expectation that the request will take significant time to
 * complete. As guidance, if a method is taking longer than 20
 * seconds (a reasonable, but arbitrary value) to process the
 * server SHOULD return a 102 (Processing) response. The server
 * MUST send a final response after the request has been
 * completed.
 *
 * @see [Documentation → IETF RFC 2518 §10.1](https://datatracker.ietf.org/doc/html/rfc2518#section-10.1)
 * @see [Specification → RFC 2518](http://webconcepts.info/specs/IETF/RFC/2518)
 */
export type HttpStatusCode102 = 102;

/**
 * The 103 (Early Hints) status code indicates the client that
 * the server is likely to send a final request with the
 * headers included in the informational response.
 *
 * @see [Documentation → IETF RFC 8297 §2](https://datatracker.ietf.org/doc/html/rfc8297#section-2)
 * @see [Specification → RFC 8297](http://webconcepts.info/specs/IETF/RFC/8297)
 */
export type HttpStatusCode103 = 103;

/**
 * The 200 (OK) status code indicates that the request has
 * succeeded. The payload sent in a 200 response depends on the
 * request method.
 *
 * @see [Documentation → IETF RFC 7231 §6.3.1](https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.1)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode200 = 200;

/**
 * The 201 (Created) status code indicates that the request has
 * been fulfilled and has resulted in one or more new resources
 * being created. The primary resource created by the request
 * is identified by either a Location header field in the
 * response or, if no Location field is received, by the
 * effective request URI.
 *
 * @see [Documentation → IETF RFC 7231 §6.3.2](https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.2)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode201 = 201;

/**
 * The 202 (Accepted) status code indicates that the request
 * has been accepted for processing, but the processing has not
 * been completed. The request might or might not eventually be
 * acted upon, as it might be disallowed when processing
 * actually takes place. There is no facility in HTTP for
 * re-sending a status code from an asynchronous operation.
 *
 * @see [Documentation → IETF RFC 7231 §6.3.3](https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.3)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode202 = 202;

/**
 * The 203 (Non-Authoritative Information) status code
 * indicates that the request was successful but the enclosed
 * payload has been modified from that of the origin server's
 * 200 (OK) response by a transforming proxy.
 *
 * @see [Documentation → IETF RFC 7231 §6.3.4](https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.4)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode203 = 203;

/**
 * The 204 (No Content) status code indicates that the server
 * has successfully fulfilled the request and that there is no
 * additional content to send in the response payload body.
 * Metadata in the response header fields refer to the target
 * resource and its selected representation after the requested
 * action was applied.
 *
 * @see [Documentation → IETF RFC 7231 §6.3.5](https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.5)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode204 = 204;

/**
 * The 205 (Reset Content) status code indicates that the
 * server has fulfilled the request and desires that the user
 * agent reset the "document view", which caused the request to
 * be sent, to its original state as received from the origin
 * server.
 *
 * @see [Documentation → IETF RFC 7231 §6.3.6](https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.6)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode205 = 205;

/**
 * The 206 (Partial Content) status code indicates that the
 * server is successfully fulfilling a range request for the
 * target resource by transferring one or more parts of the
 * selected representation that correspond to the satisfiable
 * ranges found in the request's Range header field.
 *
 * @see [Documentation → IETF RFC 7233 §4.1](https://datatracker.ietf.org/doc/html/rfc7233#section-4.1)
 * @see [Specification → RFC 7233](http://webconcepts.info/specs/IETF/RFC/7233)
 */
export type HttpStatusCode206 = 206;

/**
 * The 207 (Multi-Status) status code provides status for
 * multiple independent operations.
 *
 * @see [Documentation → IETF RFC 4918 §11.1](https://datatracker.ietf.org/doc/html/rfc4918#section-11.1)
 * @see [Specification → RFC 4918](http://webconcepts.info/specs/IETF/RFC/4918)
 */
export type HttpStatusCode207 = 207;

/**
 * The 208 (Already Reported) status code can be used inside a
 * DAV: propstat response element to avoid enumerating the
 * internal members of multiple bindings to the same collection
 * repeatedly. For each binding to a collection inside the
 * request's scope, only one will be reported with a 200
 * status, while subsequent DAV:response elements for all other
 * bindings will use the 208 status, and no DAV:response
 * elements for their descendants are included.
 *
 * @see [Documentation → IETF RFC 5842 §7.1](https://datatracker.ietf.org/doc/html/rfc5842#section-7.1)
 * @see [Specification → RFC 5842](http://webconcepts.info/specs/IETF/RFC/5842)
 */
export type HttpStatusCode208 = 208;

/**
 * The server has fulfilled a GET request for the resource, and
 * the response is a representation of the result of one or
 * more instance-manipulations applied to the current instance.
 * The actual current instance might not be available except by
 * combining this response with other previous or future
 * responses, as appropriate for the specific
 * instance-manipulation(s).
 *
 * @see [Documentation → IETF RFC 3229 §10.4.1](https://datatracker.ietf.org/doc/html/rfc3229#section-10.4.1)
 * @see [Specification → RFC 3229](http://webconcepts.info/specs/IETF/RFC/3229)
 */
export type HttpStatusCode226 = 226;

/**
 * The 300 (Multiple Choices) status code indicates that the
 * target resource has more than one representation, each with
 * its own more specific identifier, and information about the
 * alternatives is being provided so that the user (or user
 * agent) can select a preferred representation by redirecting
 * its request to one or more of those identifiers. In other
 * words, the server desires that the user agent engage in
 * reactive negotiation to select the most appropriate
 * representation(s) for its needs.
 *
 * @see [Documentation → IETF RFC 7231 §6.4.1](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.1)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode300 = 300;

/**
 * The 301 (Moved Permanently) status code indicates that the
 * target resource has been assigned a new permanent URI and
 * any future references to this resource ought to use one of
 * the enclosed URIs. Clients with link-editing capabilities
 * ought to automatically re-link references to the effective
 * request URI to one or more of the new references sent by the
 * server, where possible.
 *
 * @see [Documentation → IETF RFC 7231 §6.4.2](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.2)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode301 = 301;

/**
 * The 302 (Found) status code indicates that the target
 * resource resides temporarily under a different URI. Since
 * the redirection might be altered on occasion, the client
 * ought to continue to use the effective request URI for
 * future requests.
 *
 * @see [Documentation → IETF RFC 7231 §6.4.3](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.3)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode302 = 302;

/**
 * The 303 (See Other) status code indicates that the server is
 * redirecting the user agent to a different resource, as
 * indicated by a URI in the Location header field, which is
 * intended to provide an indirect response to the original
 * request. A user agent can perform a retrieval request
 * targeting that URI (a GET or HEAD request if using HTTP),
 * which might also be redirected, and present the eventual
 * result as an answer to the original request. Note that the
 * new URI in the Location header field is not considered
 * equivalent to the effective request URI.
 *
 * @see [Documentation → IETF RFC 7231 §6.4.4](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.4)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode303 = 303;

/**
 * The 304 (Not Modified) status code indicates that a
 * conditional GET or HEAD request has been received and would
 * have resulted in a 200 (OK) response if it were not for the
 * fact that the condition evaluated to false. In other words,
 * there is no need for the server to transfer a representation
 * of the target resource because the request indicates that
 * the client, which made the request conditional, already has
 * a valid representation; the server is therefore redirecting
 * the client to make use of that stored representation as if
 * it were the payload of a 200 (OK) response.
 *
 * @see [Documentation → IETF RFC 7232 §4.1](https://datatracker.ietf.org/doc/html/rfc7232#section-4.1)
 * @see [Specification → RFC 7232](http://webconcepts.info/specs/IETF/RFC/7232)
 */
export type HttpStatusCode304 = 304;

/**
 * The 305 (Use Proxy) status code was defined in a previous
 * version of HTTP/1.1 and is now deprecated.
 *
 * @see [Documentation → IETF RFC 7231 §6.4.5](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.5)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode305 = 305;

/**
 * The 306 status code was defined in a previous version of
 * HTTP/1.1, is no longer used, and the code is reserved.
 *
 * @see [Documentation → IETF RFC 7231 §6.4.6](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.6)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode306 = 306;

/**
 * The 307 (Temporary Redirect) status code indicates that the
 * target resource resides temporarily under a different URI
 * and the user agent MUST NOT change the request method if it
 * performs an automatic redirection to that URI. Since the
 * redirection can change over time, the client ought to
 * continue using the original effective request URI for future
 * requests.
 *
 * @see [Documentation → IETF RFC 7231 §6.4.7](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.7)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode307 = 307;

/**
 * The 308 (Permanent Redirect) status code indicates that the
 * target resource has been assigned a new permanent URI and
 * any future references to this resource ought to use one of
 * the enclosed URIs.
 *
 * @see [Documentation → IETF RFC 7538 §3](https://datatracker.ietf.org/doc/html/rfc7538#section-3)
 * @see [Specification → RFC 7538](http://webconcepts.info/specs/IETF/RFC/7538)
 */
export type HttpStatusCode308 = 308;

/**
 * The 400 (Bad Request) status code indicates that the server
 * cannot or will not process the request due to something that
 * is perceived to be a client error (e.g., malformed request
 * syntax, invalid request message framing, or deceptive
 * request routing).
 *
 * @see [Documentation → IETF RFC 7231 §6.5.1](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.1)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode400 = 400;

/**
 * The 401 (Unauthorized) status code indicates that the
 * request has not been applied because it lacks valid
 * authentication credentials for the target resource. The
 * server generating a 401 response MUST send a
 * WWW-Authenticate header field (Section 4.1) containing at
 * least one challenge applicable to the target resource.
 *
 * @see [Documentation → IETF RFC 7235 §3.1](https://datatracker.ietf.org/doc/html/rfc7235#section-3.1)
 * @see [Specification → RFC 7235](http://webconcepts.info/specs/IETF/RFC/7235)
 */
export type HttpStatusCode401 = 401;

/**
 * The 402 (Payment Required) status code is reserved for
 * future use.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.2](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.2)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode402 = 402;

/**
 * The 403 (Forbidden) status code indicates that the server
 * understood the request but refuses to authorize it. A server
 * that wishes to make public why the request has been
 * forbidden can describe that reason in the response payload
 * (if any).
 *
 * @see [Documentation → IETF RFC 7231 §6.5.3](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.3)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode403 = 403;

/**
 * The 404 (Not Found) status code indicates that the origin
 * server did not find a current representation for the target
 * resource or is not willing to disclose that one exists. A
 * 404 status code does not indicate whether this lack of
 * representation is temporary or permanent; the 410 (Gone)
 * status code is preferred over 404 if the origin server
 * knows, presumably through some configurable means, that the
 * condition is likely to be permanent.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.4](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode404 = 404;

/**
 * The 405 (Method Not Allowed) status code indicates that the
 * method received in the request-line is known by the origin
 * server but not supported by the target resource. The origin
 * server MUST generate an Allow header field in a 405 response
 * containing a list of the target resource's currently
 * supported methods.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.5](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.5)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode405 = 405;

/**
 * The 406 (Not Acceptable) status code indicates that the
 * target resource does not have a current representation that
 * would be acceptable to the user agent, according to the
 * proactive negotiation header fields received in the request,
 * and the server is unwilling to supply a default
 * representation.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.6](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.6)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode406 = 406;

/**
 * The 407 (Proxy Authentication Required) status code is
 * similar to 401 (Unauthorized), but it indicates that the
 * client needs to authenticate itself in order to use a proxy.
 * The proxy MUST send a Proxy-Authenticate header field
 * containing a challenge applicable to that proxy for the
 * target resource. The client MAY repeat the request with a
 * new or replaced Proxy-Authorization header field.
 *
 * @see [Documentation → IETF RFC 7235 §3.2](https://datatracker.ietf.org/doc/html/rfc7235#section-3.2)
 * @see [Specification → RFC 7235](http://webconcepts.info/specs/IETF/RFC/7235)
 */
export type HttpStatusCode407 = 407;

/**
 * The 408 (Request Timeout) status code indicates that the
 * server did not receive a complete request message within the
 * time that it was prepared to wait. A server SHOULD send the
 * "close" connection option in the response, since 408 implies
 * that the server has decided to close the connection rather
 * than continue waiting. If the client has an outstanding
 * request in transit, the client MAY repeat that request on a
 * new connection.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.7](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.7)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode408 = 408;

/**
 * The 409 (Conflict) status code indicates that the request
 * could not be completed due to a conflict with the current
 * state of the target resource. This code is used in
 * situations where the user might be able to resolve the
 * conflict and resubmit the request. The server SHOULD
 * generate a payload that includes enough information for a
 * user to recognize the source of the conflict.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.8](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.8)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode409 = 409;

/**
 * The 410 (Gone) status code indicates that access to the
 * target resource is no longer available at the origin server
 * and that this condition is likely to be permanent. If the
 * origin server does not know, or has no facility to
 * determine, whether or not the condition is permanent, the
 * status code 404 (Not Found) ought to be used instead.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.9](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.9)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode410 = 410;

/**
 * The 411 (Length Required) status code indicates that the
 * server refuses to accept the request without a defined
 * Content-Length. The client MAY repeat the request if it adds
 * a valid Content-Length header field containing the length of
 * the message body in the request message.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.10](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.10)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode411 = 411;

/**
 * The 412 (Precondition Failed) status code indicates that one
 * or more conditions given in the request header fields
 * evaluated to false when tested on the server. This response
 * code allows the client to place preconditions on the current
 * resource state (its current representations and metadata)
 * and, thus, prevent the request method from being applied if
 * the target resource is in an unexpected state.
 *
 * @see [Documentation → IETF RFC 7232 §4.2](https://datatracker.ietf.org/doc/html/rfc7232#section-4.2)
 * @see [Specification → RFC 7232](http://webconcepts.info/specs/IETF/RFC/7232)
 */
export type HttpStatusCode412 = 412;

/**
 * The 413 (Payload Too Large) status code indicates that the
 * server is refusing to process a request because the request
 * payload is larger than the server is willing or able to
 * process. The server MAY close the connection to prevent the
 * client from continuing the request.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.11](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.11)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode413 = 413;

/**
 * The 414 (URI Too Long) status code indicates that the server
 * is refusing to service the request because the
 * request-target is longer than the server is willing to
 * interpret.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.12](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.12)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode414 = 414;

/**
 * The 415 (Unsupported Media Type) status code indicates that
 * the origin server is refusing to service the request because
 * the payload is in a format not supported by this method on
 * the target resource. The format problem might be due to the
 * request's indicated Content-Type or Content-Encoding, or as
 * a result of inspecting the data directly.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.13](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.13)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode415 = 415;

/**
 * The 416 (Range Not Satisfiable) status code indicates that
 * none of the ranges in the request's Range header field
 * (Section 3.1) overlap the current extent of the selected
 * resource or that the set of ranges requested has been
 * rejected due to invalid ranges or an excessive request of
 * small or overlapping ranges.
 *
 * @see [Documentation → IETF RFC 7233 §4.4](https://datatracker.ietf.org/doc/html/rfc7233#section-4.4)
 * @see [Specification → RFC 7233](http://webconcepts.info/specs/IETF/RFC/7233)
 */
export type HttpStatusCode416 = 416;

/**
 * The 417 (Expectation Failed) status code indicates that the
 * expectation given in the request's Expect header field could
 * not be met by at least one of the inbound servers.
 *
 * @see [Documentation → IETF RFC 7231 §6.5.14](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.14)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode417 = 417;

/**
 * Any attempt to brew coffee with a teapot should result in
 * the error code "418 I'm a teapot". The resulting entity body
 * MAY be short and stout.
 *
 * @see [Documentation → IETF RFC 2324 §2.3.2](https://datatracker.ietf.org/doc/html/rfc2324#section-2.3.2)
 * @see [Specification → RFC 2324](http://webconcepts.info/specs/IETF/RFC/2324)
 */
export type HttpStatusCode418 = 418;

/**
 * The 421 (Misdirected Request) status code indicates that the
 * request was directed at a server that is not able to produce
 * a response. This can be sent by a server that is not
 * configured to produce responses for the combination of
 * scheme and authority that are included in the request URI.
 *
 * @see [Documentation → IETF RFC 7540 §9.1.2](https://datatracker.ietf.org/doc/html/rfc7540#section-9.1.2)
 * @see [Specification → RFC 7540](http://webconcepts.info/specs/IETF/RFC/7540)
 */
export type HttpStatusCode421 = 421;

/**
 * The 422 (Unprocessable Entity) status code means the server
 * understands the content type of the request entity (hence a
 * 415 (Unsupported Media Type) status code is inappropriate),
 * and the syntax of the request entity is correct (thus a 400
 * (Bad Request) status code is inappropriate) but was unable
 * to process the contained instructions. For example, this
 * error condition may occur if an XML request body contains
 * well-formed (i.e., syntactically correct), but semantically
 * erroneous, XML instructions.
 *
 * @see [Documentation → IETF RFC 4918 §11.2](https://datatracker.ietf.org/doc/html/rfc4918#section-11.2)
 * @see [Specification → RFC 4918](http://webconcepts.info/specs/IETF/RFC/4918)
 */
export type HttpStatusCode422 = 422;

/**
 * The 423 (Locked) status code means the source or destination
 * resource of a method is locked. This response SHOULD contain
 * an appropriate precondition or postcondition code, such as
 * 'lock-token-submitted' or 'no-conflicting-lock'.
 *
 * @see [Documentation → IETF RFC 4918 §11.3](https://datatracker.ietf.org/doc/html/rfc4918#section-11.3)
 * @see [Specification → RFC 4918](http://webconcepts.info/specs/IETF/RFC/4918)
 */
export type HttpStatusCode423 = 423;

/**
 * The 424 (Failed Dependency) status code means that the
 * method could not be performed on the resource because the
 * requested action depended on another action and that action
 * failed. For example, if a command in a PROPPATCH method
 * fails, then, at minimum, the rest of the commands will also
 * fail with 424 (Failed Dependency).
 *
 * @see [Documentation → IETF RFC 4918 §11.4](https://datatracker.ietf.org/doc/html/rfc4918#section-11.4)
 * @see [Specification → RFC 4918](http://webconcepts.info/specs/IETF/RFC/4918)
 */
export type HttpStatusCode424 = 424;

/**
 * A 425 (Too Early) status code indicates that the server is
 * unwilling to risk processing a request that might be
 * replayed. User agents that send a request in early data are
 * expected to retry the request when receiving a 425 (Too
 * Early) response status code. A user agent SHOULD retry
 * automatically, but any retries MUST NOT be sent in early
 * data.
 *
 * @see [Documentation → IETF RFC 8470 §5.2](https://datatracker.ietf.org/doc/html/rfc8470#section-5.2)
 * @see [Specification → RFC 8470](http://webconcepts.info/specs/IETF/RFC/8470)
 */
export type HttpStatusCode425 = 425;

/**
 * The 426 (Upgrade Required) status code indicates that the
 * server refuses to perform the request using the current
 * protocol but might be willing to do so after the client
 * upgrades to a different protocol. The server MUST send an
 * Upgrade header field in a 426 response to indicate the
 * required protocol(s).
 *
 * @see [Documentation → IETF RFC 7231 §6.5.15](https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.15)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode426 = 426;

/**
 * The 428 status code indicates that the origin server
 * requires the request to be conditional.
 *
 * @see [Documentation → IETF RFC 6585 §3](https://datatracker.ietf.org/doc/html/rfc6585#section-3)
 * @see [Specification → RFC 6585](http://webconcepts.info/specs/IETF/RFC/6585)
 */
export type HttpStatusCode428 = 428;

/**
 * The 429 status code indicates that the user has sent too
 * many requests in a given amount of time ("rate limiting").
 *
 * @see [Documentation → IETF RFC 6585 §4](https://datatracker.ietf.org/doc/html/rfc6585#section-4)
 * @see [Specification → RFC 6585](http://webconcepts.info/specs/IETF/RFC/6585)
 */
export type HttpStatusCode429 = 429;

/**
 * The 431 status code indicates that the server is unwilling
 * to process the request because its header fields are too
 * large. The request MAY be resubmitted after reducing the
 * size of the request header fields.
 *
 * @see [Documentation → IETF RFC 6585 §5](https://datatracker.ietf.org/doc/html/rfc6585#section-5)
 * @see [Specification → RFC 6585](http://webconcepts.info/specs/IETF/RFC/6585)
 */
export type HttpStatusCode431 = 431;

/**
 * This status code indicates that the server is denying access
 * to the resource as a consequence of a legal demand. The
 * server in question might not be an origin server. This type
 * of legal demand typically most directly affects the
 * operations of ISPs and search engines.
 *
 * @see [Documentation → IETF RFC 7725 §3](https://datatracker.ietf.org/doc/html/rfc7725#section-3)
 * @see [Specification → RFC 7725](http://webconcepts.info/specs/IETF/RFC/7725)
 */
export type HttpStatusCode451 = 451;

/**
 * The 500 (Internal Server Error) status code indicates that
 * the server encountered an unexpected condition that
 * prevented it from fulfilling the request.
 *
 * @see [Documentation → IETF RFC 7231 §6.6.1](https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.1)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode500 = 500;

/**
 * The 501 (Not Implemented) status code indicates that the
 * server does not support the functionality required to
 * fulfill the request. This is the appropriate response when
 * the server does not recognize the request method and is not
 * capable of supporting it for any resource.
 *
 * @see [Documentation → IETF RFC 7231 §6.6.2](https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.2)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode501 = 501;

/**
 * The 502 (Bad Gateway) status code indicates that the server,
 * while acting as a gateway or proxy, received an invalid
 * response from an inbound server it accessed while attempting
 * to fulfill the request.
 *
 * @see [Documentation → IETF RFC 7231 §6.6.3](https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.3)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode502 = 502;

/**
 * The 503 (Service Unavailable) status code indicates that the
 * server is currently unable to handle the request due to a
 * temporary overload or scheduled maintenance, which will
 * likely be alleviated after some delay. The server MAY send a
 * Retry-After header field to suggest an appropriate amount of
 * time for the client to wait before retrying the request.
 *
 * @see [Documentation → IETF RFC 7231 §6.6.4](https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.4)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode503 = 503;

/**
 * The 504 (Gateway Timeout) status code indicates that the
 * server, while acting as a gateway or proxy, did not receive
 * a timely response from an upstream server it needed to
 * access in order to complete the request.
 *
 * @see [Documentation → IETF RFC 7231 §6.6.5](https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.5)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode504 = 504;

/**
 * The 505 (HTTP Version Not Supported) status code indicates
 * that the server does not support, or refuses to support, the
 * major version of HTTP that was used in the request message.
 * The server is indicating that it is unable or unwilling to
 * complete the request using the same major version as the
 * client, other than with this error message. The server
 * SHOULD generate a representation for the 505 response that
 * describes why that version is not supported and what other
 * protocols are supported by that server.
 *
 * @see [Documentation → IETF RFC 7231 §6.6.6](https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.6)
 * @see [Specification → RFC 7231](http://webconcepts.info/specs/IETF/RFC/7231)
 */
export type HttpStatusCode505 = 505;

/**
 * The 506 status code indicates that the server has an
 * internal configuration error: the chosen variant resource is
 * configured to engage in transparent content negotiation
 * itself, and is therefore not a proper end point in the
 * negotiation process.
 *
 * @see [Documentation → IETF RFC 7725 §3](https://datatracker.ietf.org/doc/html/rfc7725#section-3)
 * @see [Specification → RFC 2295](http://webconcepts.info/specs/IETF/RFC/2295)
 */
export type HttpStatusCode506 = 506;

/**
 * The 507 (Insufficient Storage) status code means the method
 * could not be performed on the resource because the server is
 * unable to store the representation needed to successfully
 * complete the request. This condition is considered to be
 * temporary. If the request that received this status code was
 * the result of a user action, the request MUST NOT be
 * repeated until it is requested by a separate user action.
 *
 * @see [Documentation → IETF RFC 4918 §11.5](https://datatracker.ietf.org/doc/html/rfc4918#section-11.5)
 * @see [Specification → RFC 4918](http://webconcepts.info/specs/IETF/RFC/4918)
 */
export type HttpStatusCode507 = 507;

/**
 * The 508 (Loop Detected) status code indicates that the
 * server terminated an operation because it encountered an
 * infinite loop while processing a request with "Depth:
 * infinity". This status indicates that the entire operation
 * failed.
 *
 * @see [Documentation → IETF RFC 5842 §7.1](https://datatracker.ietf.org/doc/html/rfc5842#section-7.1)
 * @see [Specification → RFC 5842](http://webconcepts.info/specs/IETF/RFC/5842)
 */
export type HttpStatusCode508 = 508;

/**
 * The policy for accessing the resource has not been met in
 * the request. The server should send back all the information
 * necessary for the client to issue an extended request. It is
 * outside the scope of this specification to specify how the
 * extensions inform the client.
 *
 * @see [Documentation → IETF RFC 2774 §7](https://datatracker.ietf.org/doc/html/rfc2774#section-7)
 * @see [Specification → RFC 2774](http://webconcepts.info/specs/IETF/RFC/2774)
 */
export type HttpStatusCode510 = 510;

/**
 * The 511 status code indicates that the client needs to
 * authenticate to gain network access.
 *
 * @see [Documentation → IETF RFC 6585 §6](https://datatracker.ietf.org/doc/html/rfc6585#section-6)
 * @see [Specification → RFC 6585](http://webconcepts.info/specs/IETF/RFC/6585)
 */
export type HttpStatusCode511 = 511;

export type HttpInfoStatusCode =
	| HttpStatusCode100
	| HttpStatusCode101
	| HttpStatusCode102
	| HttpStatusCode103;

export type HttpSuccessStatusCode =
	| HttpStatusCode200
	| HttpStatusCode201
	| HttpStatusCode202
	| HttpStatusCode203
	| HttpStatusCode204
	| HttpStatusCode205
	| HttpStatusCode206
	| HttpStatusCode207
	| HttpStatusCode208
	| HttpStatusCode226;

export type HttpRedirectStatusCode =
	| HttpStatusCode300
	| HttpStatusCode301
	| HttpStatusCode302
	| HttpStatusCode303
	| HttpStatusCode304
	| HttpStatusCode305
	| HttpStatusCode306
	| HttpStatusCode307
	| HttpStatusCode308;

export type HttpClientErrorStatusCode =
	| HttpStatusCode400
	| HttpStatusCode401
	| HttpStatusCode402
	| HttpStatusCode403
	| HttpStatusCode404
	| HttpStatusCode405
	| HttpStatusCode406
	| HttpStatusCode407
	| HttpStatusCode408
	| HttpStatusCode409
	| HttpStatusCode410
	| HttpStatusCode411
	| HttpStatusCode412
	| HttpStatusCode413
	| HttpStatusCode414
	| HttpStatusCode415
	| HttpStatusCode416
	| HttpStatusCode417
	| HttpStatusCode418
	| HttpStatusCode421
	| HttpStatusCode422
	| HttpStatusCode423
	| HttpStatusCode424
	| HttpStatusCode425
	| HttpStatusCode426
	| HttpStatusCode428
	| HttpStatusCode429
	| HttpStatusCode431
	| HttpStatusCode451;

export type HttpServerErrorStatusCode =
	| HttpStatusCode500
	| HttpStatusCode501
	| HttpStatusCode502
	| HttpStatusCode503
	| HttpStatusCode504
	| HttpStatusCode505
	| HttpStatusCode506
	| HttpStatusCode507
	| HttpStatusCode508
	| HttpStatusCode510
	| HttpStatusCode511;

export type HttpStatusCode =
	| HttpInfoStatusCode
	| HttpSuccessStatusCode
	| HttpRedirectStatusCode
	| HttpClientErrorStatusCode
	| HttpServerErrorStatusCode;