index - Luke-zhang-04/utils GitHub Wiki
- accumulate
- arrayToChunks
- baseGcd
- between
- capitalizeFirst
- ceil
- chain
- choice
- compress
- count
- createWrappedText
- cycle
- debounce
- dropWhile
- enumerate
- escapeRegex
- filter
- filterMap
- floor
- gcd
- getPrimesUpTo
- increment
- inlineTry
- inlineTryPromise
- isEqual
- isEqualArray
- isEqualObject
- isErrorLike
- isObject
- isPrime
- islice
- map
- objectEntries
- omit
- pick
- pickAll
- randint
- range
- reduce
- repeat
- round
- runIfDefined
- shuffle
- takeWhile
- toTitleCase
- trunc
- uniform
- zip
Renames and re-exports Status
Renames and re-exports objectEntries
Renames and re-exports filter
Renames and re-exports map
Renames and re-exports reduce
Renames and re-exports phraseStatus
Renames and re-exports status
Ƭ IsAllPartial<T>: Partial<T> extends T ? true : false
Evaluates to true if all properties in T are optional, false otherwise
| Name |
|---|
T |
Ƭ IsAllPartialNullable<T>: PartialNullable<T> extends T ? true : false
Evaluates to true if all properties in T are optional AND nullable, false otherwise
| Name |
|---|
T |
Ƭ IterableValue<T>: Exclude<ReturnType<ReturnType<T[typeof Symbol.iterator]>["next"]>, IteratorReturnResult<any>>["value"]
Extracts the value of an iterable
| Name | Type | Description |
|---|---|---|
T |
extends Iterable<any> |
Iterable to extract value frome |
Ƭ MaybePromise<T>: Promise<T> | T
Takes type param T and creates a type that's either Promise<T> or T
Example
const myVar: MaybePromise<number> = 3
const myVar: MaybePromise<number> = Promise.resolve(3)| Name |
|---|
T |
Ƭ PartialNullable<T>: { [P in keyof T]?: T[P] | null }
Make all properties in T optional and nullable
| Name |
|---|
T |
Ƭ Tuple<T, L>: L extends L ? number extends L ? T[] : TupleOf<T, L, []> : never
Tuple of type T with L values in it
Example
type MyTuple = Tuple<string, 3> // [string, string, string]| Name | Type | Description |
|---|---|---|
T |
T |
Type that the tuple will contain |
L |
extends number
|
Length of tuple |
• Const phraseStatus: Object
HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes:
- Informational responses (100–199)
- Successful responses (200–299)
- Redirects (300–399)
- Client errors (400–499)
- Server errors (500–599)
Doc comments: copyright MDN Contributors under CC-BY-SA 2.5
Documentation from the MDN
See
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
| Name | Type | Description |
|---|---|---|
100 |
"Continue" |
## 100 Continue The HTTP 100 Continue informational status response code indicates that everything so far is OK and that the client should continue with the request or ignore it if it is already finished. To have a server check the request's headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100
|
101 |
"Switching Protocols" |
## 101 Switching Protocols The HTTP 101 Switching Protocols response code indicates a protocol to which the server switches. The protocol is specified in the Upgrade request header received from a client. The server includes in this response an Upgrade response header to indicate the protocol it switched to. The process is described in the following article: Protocol upgrade mechanism. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/101
|
102 |
"Processing" |
## Processing WebDAV A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet. This prevents the client from timing out and assuming the request was lost. |
103 |
"Early Hints" |
## 103 Early Hints The HTTP 103 Early Hints information response may be sent by a server while it is still preparing a response, with hints about the sites and resources that the server is expecting the final response will link. This allows a browser to preconnect to sites or start preloading resources even before the server has prepared and sent that final response. The early hint response is primarily intended for use with the Link header, which indicates the resources to be loaded. It may also contain a Content-Security-Policy header that is enforced while processing the early hint. A server might send multiple 103 responses, for example, following a redirect. Browsers only process the first early hint response, and this response must be discarded if the request results in a cross-origin redirect. Preloaded resources from the early hint are effectively pre-pended to the Document's head element, and then followed by the resources loaded in the final response. Note: For compatibility reasons it is recommended to only send HTTP 103 Early Hints responses over HTTP/2 or later, unless the client is known to handle informational responses correctly. Most browsers limit support to HTTP/2 or later for this reason. See browser compatibility below. Despite this, the examples below use HTTP/1.1-style notation as per usual convention. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103
|
200 |
"Ok" |
## 200 OK The HTTP 200 OK success status response code indicates that the request has succeeded. A 200 response is cacheable by default. The meaning of a success depends on the HTTP request method: The successful result of a PUT or a DELETE is often not a 200 OK but a 204 No Content (or a 201 Created when the resource is uploaded for the first time). Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200
|
201 |
"Created" |
## 201 Created The HTTP 201 Created success status response code indicates that the request has succeeded and has led to the creation of a resource. The new resource, or a description and link to the new resource, is effectively created before the response is sent back and the newly created items are returned in the body of the message, located at either the URL of the request, or at the URL in the value of the Location header. The common use case of this status code is as the result of a POST request. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201
|
202 |
"Accepted" |
## 202 Accepted The HyperText Transfer Protocol (HTTP) 202 Accepted response status code indicates that the request has been accepted for processing, but the processing has not been completed; in fact, processing may not have started yet. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. 202 is non-committal, meaning that there is no way for the HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202
|
203 |
"Non-Authoritative Information" |
## 203 Non-Authoritative Information The HTTP 203 Non-Authoritative Information response status indicates that the request was successful but the enclosed payload has been modified by a transforming proxy from that of the origin server's 200 (OK) response. The 203 response is similar to the value 214, meaning Transformation Applied, of the Warning header code, which has the additional advantage of being applicable to responses with any status code. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/203
|
204 |
"No Content" |
## 204 No Content The HTTP 204 No Content success status response code indicates that a request has succeeded, but that the client doesn't need to navigate away from its current page. This might be used, for example, when implementing "save and continue editing" functionality for a wiki site. In this case a PUT request would be used to save the page, and the 204 No Content response would be sent to indicate that the editor should not be replaced by some other page. A 204 response is cacheable by default (an ETag header is included in such a response). Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204
|
205 |
"Reset Content" |
## 205 Reset Content The HTTP 205 Reset Content response status tells the client to reset the document view, so for example to clear the content of a form, reset a canvas state, or to refresh the UI. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/205
|
206 |
"Partial Content" |
## 206 Partial Content The HTTP 206 Partial Content success status response code indicates that the request has succeeded and the body contains the requested ranges of data, as described in the Range header of the request. If there is only one range, the Content-Type of the whole response is set to the type of the document, and a Content-Range is provided. If several ranges are sent back, the Content-Type is set to multipart/byteranges and each fragment covers one range, with Content-Range and Content-Type describing it. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206
|
207 |
"Multi Status" |
## Multi-Status WebDAV The message body that follows is an XML message and can contain a number of separate response codes, depending on how many sub-requests were made. |
208 |
"Already Reported" |
## Already Reported WebDAV The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again. |
226 |
"IM Used" |
## IM Used HTTP Delta encoding 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. |
300 |
"Multiple Choices" |
## 300 Multiple Choices The HTTP 300 Multiple Choices redirect status response code indicates that the request has more than one possible response. The user-agent or the user should choose one of them. As there is no standardized way of choosing one of the responses, this response code is very rarely used. If the server has a preferred choice, it should generate a Location header. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/300
|
301 |
"Moved Permanently" |
## 301 Moved Permanently The HyperText Transfer Protocol (HTTP) 301 Moved Permanently redirect status response code indicates that the requested resource has been definitively moved to the URL given by the Location headers. A browser redirects to the new URL and search engines update their links to the resource. Note: Although the specification requires the method and the body to remain unchanged when the redirection is performed, not all user-agents meet this requirement. Use the 301 code only as a response for GET or HEAD methods and use the 308 Permanent Redirect for POST methods instead, as the method change is explicitly prohibited with this status. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301
|
302 |
"Found" |
## 302 Found The HyperText Transfer Protocol (HTTP) 302 Found redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location header. A browser redirects to this page but search engines don't update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is not sent to the new URL). Even if the specification requires the method (and the body) not to be altered when the redirection is performed, not all user-agents conform here - you can still find this type of bugged software out there. It is therefore recommended to set the 302 code only as a response for GET or HEAD methods and to use 307 Temporary Redirect instead, as the method change is explicitly prohibited in that case. In the cases where you want the method used to be changed to GET, use 303 See Other instead. This is useful when you want to give a response to a PUT method that is not the uploaded resource but a confirmation message such as: 'you successfully uploaded XYZ'. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302
|
303 |
"See Other" |
## 303 See Other The HyperText Transfer Protocol (HTTP) 303 See Other redirect status response code indicates that the redirects don't link to the requested resource itself, but to another page (such as a confirmation page, a representation of a real-world object — see HTTP range-14 — or an upload-progress page). This response code is often sent back as a result of PUT or POST. The method used to display this redirected page is always GET. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/303
|
304 |
"Not Modified" |
## 304 Not Modified The HTTP 304 Not Modified client redirection response code indicates that there is no need to retransmit the requested resources. This response code is sent when the request is a conditional GET or HEAD request with an If-None-Match or an If-Modified-Since header and the condition evaluates to false. It is an implicit redirection to a cached resource that would have resulted in a 200 OK response if the condition evaluated to true. The response must not contain a body and must include the headers that would have been sent in an equivalent 200 OK response: Cache-Control, Content-Location, Date, ETag, Expires, and Vary. Note: Many developer tools' network panels of browsers create extraneous requests leading to 304 responses, so that access to the local cache is visible to developers. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304
|
305 |
"Use Proxy" |
## Use Proxy The requested resource is available only through a proxy, the address for which is provided in the response. Many HTTP clients (such as Mozilla and Internet Explorer) do not correctly handle responses with this status code, primarily for security reasons. Deprecated Due to security concerns regarding in-band configuration of a proxy Since HTTP/1.1 |
306 |
"Switch Proxy" |
## Switch Proxy Originally meant "Subsequent requests should use the specified proxy". Deprecated No longer used Since HTTP/1.1 |
307 |
"Temporary Redirect" |
## 307 Temporary Redirect HTTP 307 Temporary Redirect redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location headers. The method and the body of the original request are reused to perform the redirected request. In the cases where you want the method used to be changed to GET, use 303 See Other instead. This is useful when you want to give an answer to a PUT method that is not the uploaded resources, but a confirmation message (like "You successfully uploaded XYZ"). The only difference between 307 and 302 is that 307 guarantees that the method and the body will not be changed when the redirected request is made. With 302, some old clients were incorrectly changing the method to GET: the behavior with non-GET methods and 302 is then unpredictable on the Web, whereas the behavior with 307 is predictable. For GET requests, their behavior is identical. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307
|
308 |
"Permanent Redirect" |
## 308 Permanent Redirect The HyperText Transfer Protocol (HTTP) 308 Permanent Redirect redirect status response code indicates that the resource requested has been definitively moved to the URL given by the Location headers. A browser redirects to this page and search engines update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is sent to the new URL). The request method and the body will not be altered, whereas 301 may incorrectly sometimes be changed to a GET method. Note: Some Web applications may use the 308 Permanent Redirect in a non-standard way and for other purposes. For example, Google Drive uses a 308 Resume Incomplete response to indicate to the client when an incomplete upload stalled. (See Perform a resumable download on Google Drive documentation.) Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308
|
400 |
"Bad Request" |
## 400 Bad Request The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (for example, malformed request syntax, invalid request message framing, or deceptive request routing). Warning: The client should not repeat this request without modification. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400
|
401 |
"Unauthorized" |
## 401 Unauthorized The HyperText Transfer Protocol (HTTP) 401 Unauthorized response status code indicates that the client request has not been completed because it lacks valid authentication credentials for the requested resource. This status code is sent with an HTTP WWW-Authenticate response header that contains information on how the client can request for the resource again after prompting the user for authentication credentials. This status code is similar to the 403 Forbidden status code, except that in situations resulting in this status code, user authentication can allow access to the resource. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401
|
402 |
"Payment Required" |
## 402 Payment Required Experimental: This is an experimental technology Check the Browser compatibility table carefully before using this in production. The HTTP 402 Payment Required is a nonstandard response status code that is reserved for future use. This status code was created to enable digital cash or (micro) payment systems and would indicate that the requested content is not available until the client makes a payment. Sometimes, this status code indicates that the request cannot be processed until the client makes a payment. However, no standard use convention exists and different entities use it in different contexts. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402
|
403 |
"Forbidden" |
## 403 Forbidden The HTTP 403 Forbidden response status code indicates that the server understands the request but refuses to authorize it. This status is similar to 401, but for the 403 Forbidden status code, re-authenticating makes no difference. The access is tied to the application logic, such as insufficient rights to a resource. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403
|
404 |
"Not Found" |
## 404 Not Found The HTTP 404 Not Found response status code indicates that the server cannot find the requested resource. Links that lead to a 404 page are often called broken or dead links and can be subject to link rot. A 404 status code only indicates that the resource is missing: not whether the absence is temporary or permanent. If a resource is permanently removed, use the 410 (Gone) status instead. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404
|
405 |
"Method Not Allowed" |
## 405 Method Not Allowed The HyperText Transfer Protocol (HTTP) 405 Method Not Allowed response status code indicates that the server knows the request method, but the target resource doesn't support this method. The server must generate an Allow header field in a 405 status code response. The field must contain a list of methods that the target resource currently supports. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405
|
406 |
"Not Acceptable" |
## 406 Not Acceptable The HyperText Transfer Protocol (HTTP) 406 Not Acceptable client error response code indicates that the server cannot produce a response matching the list of acceptable values defined in the request's proactive content negotiation headers, and that the server is unwilling to supply a default representation. Proactive content negotiation headers include: In practice, this error is very rarely used. Instead of responding using this error code, which would be cryptic for the end user and difficult to fix, servers ignore the relevant header and serve an actual page to the user. It is assumed that even if the user won't be completely happy, they will prefer this to an error code. If a server returns such an error status, the body of the message should contain the list of the available representations of the resources, allowing the user to choose among them. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406
|
407 |
"Proxy Authentication Required" |
## 407 Proxy Authentication Required The HTTP 407 Proxy Authentication Required client error status response code indicates that the request has not been applied because it lacks valid authentication credentials for a proxy server that is between the browser and the server that can access the requested resource. This status is sent with a Proxy-Authenticate header that contains information on how to authorize correctly. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407
|
408 |
"Request Timeout" |
## 408 Request Timeout The HyperText Transfer Protocol (HTTP) 408 Request Timeout response status code means that the server would like to shut down this unused connection. It is sent on an idle connection by some servers, even without any previous request by the client. A server should send the "close" Connection header field in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. This response is used much more since some browsers, like Chrome, Firefox 27+, and IE9, use HTTP pre-connection mechanisms to speed up surfing. Note: some servers merely shut down the connection without sending this message. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/408
|
409 |
"Conflict" |
## 409 Conflict The HTTP 409 Conflict response status code indicates a request conflict with the current state of the target resource. Conflicts are most likely to occur in response to a PUT request. For example, 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409
|
410 |
"Gone" |
## 410 Gone The HyperText Transfer Protocol (HTTP) 410 Gone client error response 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 you don't know whether this condition is temporary or permanent, a 404 status code should be used instead. Note: A 410 response is cacheable by default. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/410
|
411 |
"Length Required" |
## 411 Length Required The HyperText Transfer Protocol (HTTP) 411 Length Required client error response code indicates that the server refuses to accept the request without a defined Content-Length header. Note: by specification, when sending data in a series of chunks, the Content-Length header is omitted and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format. See Transfer-Encoding for more details. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/411
|
412 |
"Precondition Failed" |
## 412 Precondition Failed The HyperText Transfer Protocol (HTTP) 412 Precondition Failed client error response code indicates that access to the target resource has been denied. This happens with conditional requests on methods other than GET or HEAD when the condition defined by the If-Unmodified-Since or If-None-Match headers is not fulfilled. In that case, the request, usually an upload or a modification of a resource, cannot be made and this error response is sent back. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412
|
413 |
"Content Too Large" |
## 413 Content Too Large The HTTP 413 Content Too Large response status code indicates that the request entity is larger than limits defined by server; the server might close the connection or return a Retry-After header field. Prior to RFC 9110 the response phrase for the status was Payload Too Large. That name is still widely used. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413
|
414 |
"URI Too Long" |
## 414 URI Too Long The HTTP 414 URI Too Long response status code indicates that the URI requested by the client is longer than the server is willing to interpret. There are a few rare conditions when this might occur: Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/414
|
415 |
"Unsupported Media Type" |
## 415 Unsupported Media Type The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format. 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415
|
416 |
"Range Not Satisfiable" |
## 416 Range Not Satisfiable The HyperText Transfer Protocol (HTTP) 416 Range Not Satisfiable error response code indicates that a server cannot serve the requested ranges. The most likely reason is that the document doesn't contain such ranges, or that the Range header value, though syntactically correct, doesn't make sense. The 416 response message contains a 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 Faced with this error, browsers usually either abort the operation (for example, a download will be considered as non-resumable) or ask for the whole document again. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416
|
417 |
"Expectation Failed" |
## 417 Expectation Failed The HTTP 417 Expectation Failed client error response code indicates that the expectation given in the request's Expect header could not be met. See the Expect header for more details. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/417
|
418 |
"I'm A Teapot" |
## 418 I'm a teapot The HTTP 418 I'm a teapot client error response code indicates that the server refuses to brew coffee because it is, permanently, a teapot. A combined coffee/tea pot that is temporarily out of coffee should instead return 503. This error is a reference to Hyper Text Coffee Pot Control Protocol defined in April Fools' jokes in 1998 and 2014. Some websites use this response for requests they do not wish to handle, such as automated queries. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418
|
421 |
"Misdirected Request" |
## Misdirected Request 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. |
422 |
"Unprocessable Content" |
## 422 Unprocessable Content The HyperText Transfer Protocol (HTTP) 422 Unprocessable Content response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions. Warning: The client should not repeat this request without modification. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422
|
423 |
"Locked" |
## Locked WebDAV The resource that is being accessed is locked. |
424 |
"Failed Dependency" |
## Failed Dependency WebDAV The request failed due to failure of a previous request. |
426 |
"Upgrade Required" |
## 426 Upgrade Required The HTTP 426 Upgrade Required client error response 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 sends an Upgrade header with this response to indicate the required protocol(s). Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/426
|
428 |
"Precondition Required" |
## 428 Precondition Required The HTTP 428 Precondition Required response status code indicates that the server requires the request to be conditional. Typically, this means that a required precondition header, such as If-Match, is missing. When a precondition header is not matching the server side state, the response should be 412 Precondition Failed. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/428
|
429 |
"Too Many Requests" |
## 429 Too Many Requests The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time ("rate limiting"). A Retry-After header might be included to this response indicating how long to wait before making a new request. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429
|
431 |
"Request Header Fields Too Large" |
## 431 Request Header Fields Too Large The HTTP 431 Request Header Fields Too Large response status code indicates that the server refuses to process the request because the request's HTTP headers are too long. The request may be resubmitted after reducing the size of the request headers. 431 can be used when the total size of request headers is too large, or when a single header field is too large. To help those running into this error, indicate which of the two is the problem in the response body — ideally, also include which headers are too large. This lets users attempt to fix the problem, such as by clearing their cookies. Servers will often produce this status if: Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431
|
451 |
"Unavailable For Legal Reasons" |
## 451 Unavailable For Legal Reasons The HyperText Transfer Protocol (HTTP) 451 Unavailable For Legal Reasons client error response 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/451
|
500 |
"Internal Server Error" |
## 500 Internal Server Error The HyperText Transfer Protocol (HTTP) 500 Internal Server Error server error response code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. This error response is a generic "catch-all" response. Usually, this indicates the server cannot find a better 5xx error code to response. Sometimes, server administrators log error responses like the 500 status code with more details about the request to prevent the error from happening again in the future. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/500
|
501 |
"Not Implemented" |
## 501 Not Implemented The HyperText Transfer Protocol (HTTP) 501 Not Implemented server error response code means that the server does not support the functionality required to fulfill the request. This status can also send a Retry-After header, telling the requester when to check back to see if the functionality is supported by then. 501 is the appropriate response when the server does not recognize the request method and is incapable of supporting it for any resource. The only methods that servers are required to support (and therefore that must not return 501) are GET and HEAD. If the server does recognize the method, but intentionally does not support it, the appropriate response is 405 Method Not Allowed. Note: Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/501
|
502 |
"Bad Gateway" |
## 502 Bad Gateway The HyperText Transfer Protocol (HTTP) 502 Bad Gateway server error response code indicates that the server, while acting as a gateway or proxy, received an invalid response from the upstream server. Note: A Gateway might refer to different things in networking and a 502 error is usually not something you can fix, but requires a fix by the web server or the proxies you are trying to get access through. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/502
|
503 |
"Service Unavailable" |
## 503 Service Unavailable The HyperText Transfer Protocol (HTTP) 503 Service Unavailable server error response code indicates that the server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. This response should be used for temporary conditions and the Retry-After HTTP header should, if possible, contain the estimated time for the recovery of the service. Note: together with this response, a user-friendly page explaining the problem should be sent. Caching-related headers that are sent along with this response should be taken care of, as a 503 status is often a temporary condition and responses shouldn't usually be cached. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503
|
504 |
"Gateway Timeout" |
## 504 Gateway Timeout The HyperText Transfer Protocol (HTTP) 504 Gateway Timeout server error response code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server that it needed in order to complete the request. Note: A Gateway might refer to different things in networking and a 504 error is usually not something you can fix, but requires a fix by the web server or the proxies you are trying to get access through. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/504
|
505 |
"HTTP Version Not Supported" |
## 505 HTTP Version Not Supported The HyperText Transfer Protocol (HTTP) 505 HTTP Version Not Supported response status code indicates that the HTTP version used in the request is not supported by the server. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/505
|
506 |
"Variant Also Negotiates" |
## 506 Variant Also Negotiates The HyperText Transfer Protocol (HTTP) 506 Variant Also Negotiates response status code may be given in the context of Transparent Content Negotiation (see RFC 2295). This protocol enables a client to retrieve the best variant of a given resource, where the server supports multiple variants. The Variant Also Negotiates status code indicates an internal server configuration error in which the chosen variant is itself configured to engage in content negotiation, so is not a proper negotiation endpoint. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/506
|
507 |
"Insufficient Storage" |
## 507 Insufficient Storage The HyperText Transfer Protocol (HTTP) 507 Insufficient Storage response status code may be given in the context of the Web Distributed Authoring and Versioning (WebDAV) protocol (see RFC 4918). It indicates that a method could not be performed because the server cannot store the representation needed to successfully complete the request. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/507
|
508 |
"Loop Detected" |
## 508 Loop Detected The HyperText Transfer Protocol (HTTP) 508 Loop Detected response status code may be given in the context of the Web Distributed Authoring and Versioning (WebDAV) protocol. It 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/508
|
510 |
"Not Extended" |
## 510 Not Extended The HyperText Transfer Protocol (HTTP) 510 Not Extended response status code is sent in the context of the HTTP Extension Framework, defined in RFC 2774. In that specification a client may send a request that contains an extension declaration, that describes the extension to be used. If the server receives such a request, but any described extensions are not supported for the request, then the server responds with the 510 status code. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/510
|
511 |
"Network Authentication Required" |
## 511 Network Authentication Required The HTTP 511 Network Authentication Required response status code indicates that the client needs to authenticate to gain network access. This status is not generated by origin servers, but by intercepting proxies that control access to the network. 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). They often identify clients who have not done so using their Media Access Control (MAC) addresses. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/511
|
• Const status: Object
HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes:
- Informational responses (100–199)
- Successful responses (200–299)
- Redirects (300–399)
- Client errors (400–499)
- Server errors (500–599)
Doc comments: copyright MDN Contributors under CC-BY-SA 2.5
Documentation from the MDN
See
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
| Name | Type | Description |
|---|---|---|
100 |
"continue" |
## 100 Continue The HTTP 100 Continue informational status response code indicates that everything so far is OK and that the client should continue with the request or ignore it if it is already finished. To have a server check the request's headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100
|
101 |
"switchingProtocols" |
## 101 Switching Protocols The HTTP 101 Switching Protocols response code indicates a protocol to which the server switches. The protocol is specified in the Upgrade request header received from a client. The server includes in this response an Upgrade response header to indicate the protocol it switched to. The process is described in the following article: Protocol upgrade mechanism. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/101
|
102 |
"processing" |
## Processing WebDAV A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet. This prevents the client from timing out and assuming the request was lost. |
103 |
"earlyHints" |
## 103 Early Hints The HTTP 103 Early Hints information response may be sent by a server while it is still preparing a response, with hints about the sites and resources that the server is expecting the final response will link. This allows a browser to preconnect to sites or start preloading resources even before the server has prepared and sent that final response. The early hint response is primarily intended for use with the Link header, which indicates the resources to be loaded. It may also contain a Content-Security-Policy header that is enforced while processing the early hint. A server might send multiple 103 responses, for example, following a redirect. Browsers only process the first early hint response, and this response must be discarded if the request results in a cross-origin redirect. Preloaded resources from the early hint are effectively pre-pended to the Document's head element, and then followed by the resources loaded in the final response. Note: For compatibility reasons it is recommended to only send HTTP 103 Early Hints responses over HTTP/2 or later, unless the client is known to handle informational responses correctly. Most browsers limit support to HTTP/2 or later for this reason. See browser compatibility below. Despite this, the examples below use HTTP/1.1-style notation as per usual convention. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103
|
200 |
"ok" |
## 200 OK The HTTP 200 OK success status response code indicates that the request has succeeded. A 200 response is cacheable by default. The meaning of a success depends on the HTTP request method: The successful result of a PUT or a DELETE is often not a 200 OK but a 204 No Content (or a 201 Created when the resource is uploaded for the first time). Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200
|
201 |
"created" |
## 201 Created The HTTP 201 Created success status response code indicates that the request has succeeded and has led to the creation of a resource. The new resource, or a description and link to the new resource, is effectively created before the response is sent back and the newly created items are returned in the body of the message, located at either the URL of the request, or at the URL in the value of the Location header. The common use case of this status code is as the result of a POST request. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201
|
202 |
"accepted" |
## 202 Accepted The HyperText Transfer Protocol (HTTP) 202 Accepted response status code indicates that the request has been accepted for processing, but the processing has not been completed; in fact, processing may not have started yet. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. 202 is non-committal, meaning that there is no way for the HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202
|
203 |
"nonAuthoritativeInformation" |
## 203 Non-Authoritative Information The HTTP 203 Non-Authoritative Information response status indicates that the request was successful but the enclosed payload has been modified by a transforming proxy from that of the origin server's 200 (OK) response. The 203 response is similar to the value 214, meaning Transformation Applied, of the Warning header code, which has the additional advantage of being applicable to responses with any status code. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/203
|
204 |
"noContent" |
## 204 No Content The HTTP 204 No Content success status response code indicates that a request has succeeded, but that the client doesn't need to navigate away from its current page. This might be used, for example, when implementing "save and continue editing" functionality for a wiki site. In this case a PUT request would be used to save the page, and the 204 No Content response would be sent to indicate that the editor should not be replaced by some other page. A 204 response is cacheable by default (an ETag header is included in such a response). Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204
|
205 |
"resetContent" |
## 205 Reset Content The HTTP 205 Reset Content response status tells the client to reset the document view, so for example to clear the content of a form, reset a canvas state, or to refresh the UI. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/205
|
206 |
"partialContent" |
## 206 Partial Content The HTTP 206 Partial Content success status response code indicates that the request has succeeded and the body contains the requested ranges of data, as described in the Range header of the request. If there is only one range, the Content-Type of the whole response is set to the type of the document, and a Content-Range is provided. If several ranges are sent back, the Content-Type is set to multipart/byteranges and each fragment covers one range, with Content-Range and Content-Type describing it. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206
|
207 |
"multiStatus" |
## Multi-Status WebDAV The message body that follows is an XML message and can contain a number of separate response codes, depending on how many sub-requests were made. |
208 |
"alreadyReported" |
## Already Reported WebDAV The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again. |
226 |
"imUsed" |
## IM Used HTTP Delta encoding 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. |
300 |
"multipleChoices" |
## 300 Multiple Choices The HTTP 300 Multiple Choices redirect status response code indicates that the request has more than one possible response. The user-agent or the user should choose one of them. As there is no standardized way of choosing one of the responses, this response code is very rarely used. If the server has a preferred choice, it should generate a Location header. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/300
|
301 |
"movedPermanently" |
## 301 Moved Permanently The HyperText Transfer Protocol (HTTP) 301 Moved Permanently redirect status response code indicates that the requested resource has been definitively moved to the URL given by the Location headers. A browser redirects to the new URL and search engines update their links to the resource. Note: Although the specification requires the method and the body to remain unchanged when the redirection is performed, not all user-agents meet this requirement. Use the 301 code only as a response for GET or HEAD methods and use the 308 Permanent Redirect for POST methods instead, as the method change is explicitly prohibited with this status. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301
|
302 |
"found" |
## 302 Found The HyperText Transfer Protocol (HTTP) 302 Found redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location header. A browser redirects to this page but search engines don't update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is not sent to the new URL). Even if the specification requires the method (and the body) not to be altered when the redirection is performed, not all user-agents conform here - you can still find this type of bugged software out there. It is therefore recommended to set the 302 code only as a response for GET or HEAD methods and to use 307 Temporary Redirect instead, as the method change is explicitly prohibited in that case. In the cases where you want the method used to be changed to GET, use 303 See Other instead. This is useful when you want to give a response to a PUT method that is not the uploaded resource but a confirmation message such as: 'you successfully uploaded XYZ'. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302
|
303 |
"seeOther" |
## 303 See Other The HyperText Transfer Protocol (HTTP) 303 See Other redirect status response code indicates that the redirects don't link to the requested resource itself, but to another page (such as a confirmation page, a representation of a real-world object — see HTTP range-14 — or an upload-progress page). This response code is often sent back as a result of PUT or POST. The method used to display this redirected page is always GET. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/303
|
304 |
"notModified" |
## 304 Not Modified The HTTP 304 Not Modified client redirection response code indicates that there is no need to retransmit the requested resources. This response code is sent when the request is a conditional GET or HEAD request with an If-None-Match or an If-Modified-Since header and the condition evaluates to false. It is an implicit redirection to a cached resource that would have resulted in a 200 OK response if the condition evaluated to true. The response must not contain a body and must include the headers that would have been sent in an equivalent 200 OK response: Cache-Control, Content-Location, Date, ETag, Expires, and Vary. Note: Many developer tools' network panels of browsers create extraneous requests leading to 304 responses, so that access to the local cache is visible to developers. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304
|
305 |
"useProxy" |
## Use Proxy The requested resource is available only through a proxy, the address for which is provided in the response. Many HTTP clients (such as Mozilla and Internet Explorer) do not correctly handle responses with this status code, primarily for security reasons. Deprecated Due to security concerns regarding in-band configuration of a proxy Since HTTP/1.1 |
306 |
"switchProxy" |
## Switch Proxy Originally meant "Subsequent requests should use the specified proxy". Deprecated No longer used Since HTTP/1.1 |
307 |
"temporaryRedirect" |
## 307 Temporary Redirect HTTP 307 Temporary Redirect redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location headers. The method and the body of the original request are reused to perform the redirected request. In the cases where you want the method used to be changed to GET, use 303 See Other instead. This is useful when you want to give an answer to a PUT method that is not the uploaded resources, but a confirmation message (like "You successfully uploaded XYZ"). The only difference between 307 and 302 is that 307 guarantees that the method and the body will not be changed when the redirected request is made. With 302, some old clients were incorrectly changing the method to GET: the behavior with non-GET methods and 302 is then unpredictable on the Web, whereas the behavior with 307 is predictable. For GET requests, their behavior is identical. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307
|
308 |
"permanentRedirect" |
## 308 Permanent Redirect The HyperText Transfer Protocol (HTTP) 308 Permanent Redirect redirect status response code indicates that the resource requested has been definitively moved to the URL given by the Location headers. A browser redirects to this page and search engines update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is sent to the new URL). The request method and the body will not be altered, whereas 301 may incorrectly sometimes be changed to a GET method. Note: Some Web applications may use the 308 Permanent Redirect in a non-standard way and for other purposes. For example, Google Drive uses a 308 Resume Incomplete response to indicate to the client when an incomplete upload stalled. (See Perform a resumable download on Google Drive documentation.) Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308
|
400 |
"badRequest" |
## 400 Bad Request The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (for example, malformed request syntax, invalid request message framing, or deceptive request routing). Warning: The client should not repeat this request without modification. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400
|
401 |
"unauthorized" |
## 401 Unauthorized The HyperText Transfer Protocol (HTTP) 401 Unauthorized response status code indicates that the client request has not been completed because it lacks valid authentication credentials for the requested resource. This status code is sent with an HTTP WWW-Authenticate response header that contains information on how the client can request for the resource again after prompting the user for authentication credentials. This status code is similar to the 403 Forbidden status code, except that in situations resulting in this status code, user authentication can allow access to the resource. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401
|
402 |
"paymentRequired" |
## 402 Payment Required Experimental: This is an experimental technology Check the Browser compatibility table carefully before using this in production. The HTTP 402 Payment Required is a nonstandard response status code that is reserved for future use. This status code was created to enable digital cash or (micro) payment systems and would indicate that the requested content is not available until the client makes a payment. Sometimes, this status code indicates that the request cannot be processed until the client makes a payment. However, no standard use convention exists and different entities use it in different contexts. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402
|
403 |
"forbidden" |
## 403 Forbidden The HTTP 403 Forbidden response status code indicates that the server understands the request but refuses to authorize it. This status is similar to 401, but for the 403 Forbidden status code, re-authenticating makes no difference. The access is tied to the application logic, such as insufficient rights to a resource. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403
|
404 |
"notFound" |
## 404 Not Found The HTTP 404 Not Found response status code indicates that the server cannot find the requested resource. Links that lead to a 404 page are often called broken or dead links and can be subject to link rot. A 404 status code only indicates that the resource is missing: not whether the absence is temporary or permanent. If a resource is permanently removed, use the 410 (Gone) status instead. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404
|
405 |
"methodNotAllowed" |
## 405 Method Not Allowed The HyperText Transfer Protocol (HTTP) 405 Method Not Allowed response status code indicates that the server knows the request method, but the target resource doesn't support this method. The server must generate an Allow header field in a 405 status code response. The field must contain a list of methods that the target resource currently supports. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405
|
406 |
"notAcceptable" |
## 406 Not Acceptable The HyperText Transfer Protocol (HTTP) 406 Not Acceptable client error response code indicates that the server cannot produce a response matching the list of acceptable values defined in the request's proactive content negotiation headers, and that the server is unwilling to supply a default representation. Proactive content negotiation headers include: In practice, this error is very rarely used. Instead of responding using this error code, which would be cryptic for the end user and difficult to fix, servers ignore the relevant header and serve an actual page to the user. It is assumed that even if the user won't be completely happy, they will prefer this to an error code. If a server returns such an error status, the body of the message should contain the list of the available representations of the resources, allowing the user to choose among them. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406
|
407 |
"proxyAuthenticationRequired" |
## 407 Proxy Authentication Required The HTTP 407 Proxy Authentication Required client error status response code indicates that the request has not been applied because it lacks valid authentication credentials for a proxy server that is between the browser and the server that can access the requested resource. This status is sent with a Proxy-Authenticate header that contains information on how to authorize correctly. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407
|
408 |
"requestTimeout" |
## 408 Request Timeout The HyperText Transfer Protocol (HTTP) 408 Request Timeout response status code means that the server would like to shut down this unused connection. It is sent on an idle connection by some servers, even without any previous request by the client. A server should send the "close" Connection header field in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. This response is used much more since some browsers, like Chrome, Firefox 27+, and IE9, use HTTP pre-connection mechanisms to speed up surfing. Note: some servers merely shut down the connection without sending this message. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/408
|
409 |
"conflict" |
## 409 Conflict The HTTP 409 Conflict response status code indicates a request conflict with the current state of the target resource. Conflicts are most likely to occur in response to a PUT request. For example, 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409
|
410 |
"gone" |
## 410 Gone The HyperText Transfer Protocol (HTTP) 410 Gone client error response 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 you don't know whether this condition is temporary or permanent, a 404 status code should be used instead. Note: A 410 response is cacheable by default. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/410
|
411 |
"lengthRequired" |
## 411 Length Required The HyperText Transfer Protocol (HTTP) 411 Length Required client error response code indicates that the server refuses to accept the request without a defined Content-Length header. Note: by specification, when sending data in a series of chunks, the Content-Length header is omitted and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format. See Transfer-Encoding for more details. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/411
|
412 |
"preconditionFailed" |
## 412 Precondition Failed The HyperText Transfer Protocol (HTTP) 412 Precondition Failed client error response code indicates that access to the target resource has been denied. This happens with conditional requests on methods other than GET or HEAD when the condition defined by the If-Unmodified-Since or If-None-Match headers is not fulfilled. In that case, the request, usually an upload or a modification of a resource, cannot be made and this error response is sent back. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412
|
413 |
"contentTooLarge" |
## 413 Content Too Large The HTTP 413 Content Too Large response status code indicates that the request entity is larger than limits defined by server; the server might close the connection or return a Retry-After header field. Prior to RFC 9110 the response phrase for the status was Payload Too Large. That name is still widely used. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413
|
414 |
"uriTooLong" |
## 414 URI Too Long The HTTP 414 URI Too Long response status code indicates that the URI requested by the client is longer than the server is willing to interpret. There are a few rare conditions when this might occur: Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/414
|
415 |
"unsupportedMediaType" |
## 415 Unsupported Media Type The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format. 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415
|
416 |
"rangeNotSatisfiable" |
## 416 Range Not Satisfiable The HyperText Transfer Protocol (HTTP) 416 Range Not Satisfiable error response code indicates that a server cannot serve the requested ranges. The most likely reason is that the document doesn't contain such ranges, or that the Range header value, though syntactically correct, doesn't make sense. The 416 response message contains a 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 Faced with this error, browsers usually either abort the operation (for example, a download will be considered as non-resumable) or ask for the whole document again. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416
|
417 |
"expectationFailed" |
## 417 Expectation Failed The HTTP 417 Expectation Failed client error response code indicates that the expectation given in the request's Expect header could not be met. See the Expect header for more details. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/417
|
418 |
"imATeapot" |
## 418 I'm a teapot The HTTP 418 I'm a teapot client error response code indicates that the server refuses to brew coffee because it is, permanently, a teapot. A combined coffee/tea pot that is temporarily out of coffee should instead return 503. This error is a reference to Hyper Text Coffee Pot Control Protocol defined in April Fools' jokes in 1998 and 2014. Some websites use this response for requests they do not wish to handle, such as automated queries. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418
|
421 |
"misdirectedRequest" |
## Misdirected Request 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. |
422 |
"unprocessableContent" |
## 422 Unprocessable Content The HyperText Transfer Protocol (HTTP) 422 Unprocessable Content response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions. Warning: The client should not repeat this request without modification. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422
|
423 |
"locked" |
## Locked WebDAV The resource that is being accessed is locked. |
424 |
"failedDependency" |
## Failed Dependency WebDAV The request failed due to failure of a previous request. |
426 |
"upgradeRequired" |
## 426 Upgrade Required The HTTP 426 Upgrade Required client error response 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 sends an Upgrade header with this response to indicate the required protocol(s). Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/426
|
428 |
"preconditionRequired" |
## 428 Precondition Required The HTTP 428 Precondition Required response status code indicates that the server requires the request to be conditional. Typically, this means that a required precondition header, such as If-Match, is missing. When a precondition header is not matching the server side state, the response should be 412 Precondition Failed. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/428
|
429 |
"tooManyRequests" |
## 429 Too Many Requests The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time ("rate limiting"). A Retry-After header might be included to this response indicating how long to wait before making a new request. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429
|
431 |
"requestHeaderFieldsTooLarge" |
## 431 Request Header Fields Too Large The HTTP 431 Request Header Fields Too Large response status code indicates that the server refuses to process the request because the request's HTTP headers are too long. The request may be resubmitted after reducing the size of the request headers. 431 can be used when the total size of request headers is too large, or when a single header field is too large. To help those running into this error, indicate which of the two is the problem in the response body — ideally, also include which headers are too large. This lets users attempt to fix the problem, such as by clearing their cookies. Servers will often produce this status if: Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431
|
451 |
"unavailableForLegalReasons" |
## 451 Unavailable For Legal Reasons The HyperText Transfer Protocol (HTTP) 451 Unavailable For Legal Reasons client error response 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/451
|
500 |
"internalServerError" |
## 500 Internal Server Error The HyperText Transfer Protocol (HTTP) 500 Internal Server Error server error response code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. This error response is a generic "catch-all" response. Usually, this indicates the server cannot find a better 5xx error code to response. Sometimes, server administrators log error responses like the 500 status code with more details about the request to prevent the error from happening again in the future. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/500
|
501 |
"notImplemented" |
## 501 Not Implemented The HyperText Transfer Protocol (HTTP) 501 Not Implemented server error response code means that the server does not support the functionality required to fulfill the request. This status can also send a Retry-After header, telling the requester when to check back to see if the functionality is supported by then. 501 is the appropriate response when the server does not recognize the request method and is incapable of supporting it for any resource. The only methods that servers are required to support (and therefore that must not return 501) are GET and HEAD. If the server does recognize the method, but intentionally does not support it, the appropriate response is 405 Method Not Allowed. Note: Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/501
|
502 |
"badGateway" |
## 502 Bad Gateway The HyperText Transfer Protocol (HTTP) 502 Bad Gateway server error response code indicates that the server, while acting as a gateway or proxy, received an invalid response from the upstream server. Note: A Gateway might refer to different things in networking and a 502 error is usually not something you can fix, but requires a fix by the web server or the proxies you are trying to get access through. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/502
|
503 |
"serviceUnavailable" |
## 503 Service Unavailable The HyperText Transfer Protocol (HTTP) 503 Service Unavailable server error response code indicates that the server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. This response should be used for temporary conditions and the Retry-After HTTP header should, if possible, contain the estimated time for the recovery of the service. Note: together with this response, a user-friendly page explaining the problem should be sent. Caching-related headers that are sent along with this response should be taken care of, as a 503 status is often a temporary condition and responses shouldn't usually be cached. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503
|
504 |
"gatewayTimeout" |
## 504 Gateway Timeout The HyperText Transfer Protocol (HTTP) 504 Gateway Timeout server error response code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server that it needed in order to complete the request. Note: A Gateway might refer to different things in networking and a 504 error is usually not something you can fix, but requires a fix by the web server or the proxies you are trying to get access through. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/504
|
505 |
"httpVersionNotSupported" |
## 505 HTTP Version Not Supported The HyperText Transfer Protocol (HTTP) 505 HTTP Version Not Supported response status code indicates that the HTTP version used in the request is not supported by the server. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/505
|
506 |
"variantAlsoNegotiates" |
## 506 Variant Also Negotiates The HyperText Transfer Protocol (HTTP) 506 Variant Also Negotiates response status code may be given in the context of Transparent Content Negotiation (see RFC 2295). This protocol enables a client to retrieve the best variant of a given resource, where the server supports multiple variants. The Variant Also Negotiates status code indicates an internal server configuration error in which the chosen variant is itself configured to engage in content negotiation, so is not a proper negotiation endpoint. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/506
|
507 |
"insufficientStorage" |
## 507 Insufficient Storage The HyperText Transfer Protocol (HTTP) 507 Insufficient Storage response status code may be given in the context of the Web Distributed Authoring and Versioning (WebDAV) protocol (see RFC 4918). It indicates that a method could not be performed because the server cannot store the representation needed to successfully complete the request. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/507
|
508 |
"loopDetected" |
## 508 Loop Detected The HyperText Transfer Protocol (HTTP) 508 Loop Detected response status code may be given in the context of the Web Distributed Authoring and Versioning (WebDAV) protocol. It 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/508
|
510 |
"notExtended" |
## 510 Not Extended The HyperText Transfer Protocol (HTTP) 510 Not Extended response status code is sent in the context of the HTTP Extension Framework, defined in RFC 2774. In that specification a client may send a request that contains an extension declaration, that describes the extension to be used. If the server receives such a request, but any described extensions are not supported for the request, then the server responds with the 510 status code. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/510
|
511 |
"networkAuthenticationRequired" |
## 511 Network Authentication Required The HTTP 511 Network Authentication Required response status code indicates that the client needs to authenticate to gain network access. This status is not generated by origin servers, but by intercepting proxies that control access to the network. 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). They often identify clients who have not done so using their Media Access Control (MAC) addresses. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/511
|
accepted |
202 |
## 202 Accepted The HyperText Transfer Protocol (HTTP) 202 Accepted response status code indicates that the request has been accepted for processing, but the processing has not been completed; in fact, processing may not have started yet. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. 202 is non-committal, meaning that there is no way for the HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202
|
alreadyReported |
208 |
## Already Reported WebDAV The members of a DAV binding have already been enumerated in a preceding part of the (multistatus) response, and are not being included again. |
badGateway |
502 |
## 502 Bad Gateway The HyperText Transfer Protocol (HTTP) 502 Bad Gateway server error response code indicates that the server, while acting as a gateway or proxy, received an invalid response from the upstream server. Note: A Gateway might refer to different things in networking and a 502 error is usually not something you can fix, but requires a fix by the web server or the proxies you are trying to get access through. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/502
|
badRequest |
400 |
## 400 Bad Request The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (for example, malformed request syntax, invalid request message framing, or deceptive request routing). Warning: The client should not repeat this request without modification. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400
|
conflict |
409 |
## 409 Conflict The HTTP 409 Conflict response status code indicates a request conflict with the current state of the target resource. Conflicts are most likely to occur in response to a PUT request. For example, 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409
|
contentTooLarge |
413 |
## 413 Content Too Large The HTTP 413 Content Too Large response status code indicates that the request entity is larger than limits defined by server; the server might close the connection or return a Retry-After header field. Prior to RFC 9110 the response phrase for the status was Payload Too Large. That name is still widely used. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413
|
continue |
100 |
## 100 Continue The HTTP 100 Continue informational status response code indicates that everything so far is OK and that the client should continue with the request or ignore it if it is already finished. To have a server check the request's headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100
|
created |
201 |
## 201 Created The HTTP 201 Created success status response code indicates that the request has succeeded and has led to the creation of a resource. The new resource, or a description and link to the new resource, is effectively created before the response is sent back and the newly created items are returned in the body of the message, located at either the URL of the request, or at the URL in the value of the Location header. The common use case of this status code is as the result of a POST request. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201
|
earlyHints |
103 |
## 103 Early Hints The HTTP 103 Early Hints information response may be sent by a server while it is still preparing a response, with hints about the sites and resources that the server is expecting the final response will link. This allows a browser to preconnect to sites or start preloading resources even before the server has prepared and sent that final response. The early hint response is primarily intended for use with the Link header, which indicates the resources to be loaded. It may also contain a Content-Security-Policy header that is enforced while processing the early hint. A server might send multiple 103 responses, for example, following a redirect. Browsers only process the first early hint response, and this response must be discarded if the request results in a cross-origin redirect. Preloaded resources from the early hint are effectively pre-pended to the Document's head element, and then followed by the resources loaded in the final response. Note: For compatibility reasons it is recommended to only send HTTP 103 Early Hints responses over HTTP/2 or later, unless the client is known to handle informational responses correctly. Most browsers limit support to HTTP/2 or later for this reason. See browser compatibility below. Despite this, the examples below use HTTP/1.1-style notation as per usual convention. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103
|
expectationFailed |
417 |
## 417 Expectation Failed The HTTP 417 Expectation Failed client error response code indicates that the expectation given in the request's Expect header could not be met. See the Expect header for more details. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/417
|
failedDependency |
424 |
## Failed Dependency WebDAV The request failed due to failure of a previous request. |
forbidden |
403 |
## 403 Forbidden The HTTP 403 Forbidden response status code indicates that the server understands the request but refuses to authorize it. This status is similar to 401, but for the 403 Forbidden status code, re-authenticating makes no difference. The access is tied to the application logic, such as insufficient rights to a resource. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403
|
found |
302 |
## 302 Found The HyperText Transfer Protocol (HTTP) 302 Found redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location header. A browser redirects to this page but search engines don't update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is not sent to the new URL). Even if the specification requires the method (and the body) not to be altered when the redirection is performed, not all user-agents conform here - you can still find this type of bugged software out there. It is therefore recommended to set the 302 code only as a response for GET or HEAD methods and to use 307 Temporary Redirect instead, as the method change is explicitly prohibited in that case. In the cases where you want the method used to be changed to GET, use 303 See Other instead. This is useful when you want to give a response to a PUT method that is not the uploaded resource but a confirmation message such as: 'you successfully uploaded XYZ'. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302
|
gatewayTimeout |
504 |
## 504 Gateway Timeout The HyperText Transfer Protocol (HTTP) 504 Gateway Timeout server error response code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server that it needed in order to complete the request. Note: A Gateway might refer to different things in networking and a 504 error is usually not something you can fix, but requires a fix by the web server or the proxies you are trying to get access through. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/504
|
gone |
410 |
## 410 Gone The HyperText Transfer Protocol (HTTP) 410 Gone client error response 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 you don't know whether this condition is temporary or permanent, a 404 status code should be used instead. Note: A 410 response is cacheable by default. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/410
|
httpVersionNotSupported |
505 |
## 505 HTTP Version Not Supported The HyperText Transfer Protocol (HTTP) 505 HTTP Version Not Supported response status code indicates that the HTTP version used in the request is not supported by the server. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/505
|
imATeapot |
418 |
## 418 I'm a teapot The HTTP 418 I'm a teapot client error response code indicates that the server refuses to brew coffee because it is, permanently, a teapot. A combined coffee/tea pot that is temporarily out of coffee should instead return 503. This error is a reference to Hyper Text Coffee Pot Control Protocol defined in April Fools' jokes in 1998 and 2014. Some websites use this response for requests they do not wish to handle, such as automated queries. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418
|
imUsed |
226 |
## IM Used HTTP Delta encoding 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. |
insufficientStorage |
507 |
## 507 Insufficient Storage The HyperText Transfer Protocol (HTTP) 507 Insufficient Storage response status code may be given in the context of the Web Distributed Authoring and Versioning (WebDAV) protocol (see RFC 4918). It indicates that a method could not be performed because the server cannot store the representation needed to successfully complete the request. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/507
|
internalError |
500 |
## 500 Internal Server Error The HyperText Transfer Protocol (HTTP) 500 Internal Server Error server error response code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. This error response is a generic "catch-all" response. Usually, this indicates the server cannot find a better 5xx error code to response. Sometimes, server administrators log error responses like the 500 status code with more details about the request to prevent the error from happening again in the future. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/500
|
internalServerError |
500 |
## 500 Internal Server Error The HyperText Transfer Protocol (HTTP) 500 Internal Server Error server error response code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. This error response is a generic "catch-all" response. Usually, this indicates the server cannot find a better 5xx error code to response. Sometimes, server administrators log error responses like the 500 status code with more details about the request to prevent the error from happening again in the future. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/500
|
lengthRequired |
411 |
## 411 Length Required The HyperText Transfer Protocol (HTTP) 411 Length Required client error response code indicates that the server refuses to accept the request without a defined Content-Length header. Note: by specification, when sending data in a series of chunks, the Content-Length header is omitted and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format. See Transfer-Encoding for more details. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/411
|
locked |
423 |
## Locked WebDAV The resource that is being accessed is locked. |
loopDetected |
508 |
## 508 Loop Detected The HyperText Transfer Protocol (HTTP) 508 Loop Detected response status code may be given in the context of the Web Distributed Authoring and Versioning (WebDAV) protocol. It 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/508
|
methodNotAllowed |
405 |
## 405 Method Not Allowed The HyperText Transfer Protocol (HTTP) 405 Method Not Allowed response status code indicates that the server knows the request method, but the target resource doesn't support this method. The server must generate an Allow header field in a 405 status code response. The field must contain a list of methods that the target resource currently supports. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405
|
misdirectedRequest |
421 |
## Misdirected Request 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. |
movedPermanently |
301 |
## 301 Moved Permanently The HyperText Transfer Protocol (HTTP) 301 Moved Permanently redirect status response code indicates that the requested resource has been definitively moved to the URL given by the Location headers. A browser redirects to the new URL and search engines update their links to the resource. Note: Although the specification requires the method and the body to remain unchanged when the redirection is performed, not all user-agents meet this requirement. Use the 301 code only as a response for GET or HEAD methods and use the 308 Permanent Redirect for POST methods instead, as the method change is explicitly prohibited with this status. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301
|
multiStatus |
207 |
## Multi-Status WebDAV The message body that follows is an XML message and can contain a number of separate response codes, depending on how many sub-requests were made. |
multipleChoices |
300 |
## 300 Multiple Choices The HTTP 300 Multiple Choices redirect status response code indicates that the request has more than one possible response. The user-agent or the user should choose one of them. As there is no standardized way of choosing one of the responses, this response code is very rarely used. If the server has a preferred choice, it should generate a Location header. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/300
|
networkAuthenticationRequired |
511 |
## 511 Network Authentication Required The HTTP 511 Network Authentication Required response status code indicates that the client needs to authenticate to gain network access. This status is not generated by origin servers, but by intercepting proxies that control access to the network. 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). They often identify clients who have not done so using their Media Access Control (MAC) addresses. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/511
|
noContent |
204 |
## 204 No Content The HTTP 204 No Content success status response code indicates that a request has succeeded, but that the client doesn't need to navigate away from its current page. This might be used, for example, when implementing "save and continue editing" functionality for a wiki site. In this case a PUT request would be used to save the page, and the 204 No Content response would be sent to indicate that the editor should not be replaced by some other page. A 204 response is cacheable by default (an ETag header is included in such a response). Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204
|
nonAuthoritativeInformation |
203 |
## 203 Non-Authoritative Information The HTTP 203 Non-Authoritative Information response status indicates that the request was successful but the enclosed payload has been modified by a transforming proxy from that of the origin server's 200 (OK) response. The 203 response is similar to the value 214, meaning Transformation Applied, of the Warning header code, which has the additional advantage of being applicable to responses with any status code. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/203
|
notAcceptable |
406 |
## 406 Not Acceptable The HyperText Transfer Protocol (HTTP) 406 Not Acceptable client error response code indicates that the server cannot produce a response matching the list of acceptable values defined in the request's proactive content negotiation headers, and that the server is unwilling to supply a default representation. Proactive content negotiation headers include: In practice, this error is very rarely used. Instead of responding using this error code, which would be cryptic for the end user and difficult to fix, servers ignore the relevant header and serve an actual page to the user. It is assumed that even if the user won't be completely happy, they will prefer this to an error code. If a server returns such an error status, the body of the message should contain the list of the available representations of the resources, allowing the user to choose among them. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406
|
notExtended |
510 |
## 510 Not Extended The HyperText Transfer Protocol (HTTP) 510 Not Extended response status code is sent in the context of the HTTP Extension Framework, defined in RFC 2774. In that specification a client may send a request that contains an extension declaration, that describes the extension to be used. If the server receives such a request, but any described extensions are not supported for the request, then the server responds with the 510 status code. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/510
|
notFound |
404 |
## 404 Not Found The HTTP 404 Not Found response status code indicates that the server cannot find the requested resource. Links that lead to a 404 page are often called broken or dead links and can be subject to link rot. A 404 status code only indicates that the resource is missing: not whether the absence is temporary or permanent. If a resource is permanently removed, use the 410 (Gone) status instead. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404
|
notImplemented |
501 |
## 501 Not Implemented The HyperText Transfer Protocol (HTTP) 501 Not Implemented server error response code means that the server does not support the functionality required to fulfill the request. This status can also send a Retry-After header, telling the requester when to check back to see if the functionality is supported by then. 501 is the appropriate response when the server does not recognize the request method and is incapable of supporting it for any resource. The only methods that servers are required to support (and therefore that must not return 501) are GET and HEAD. If the server does recognize the method, but intentionally does not support it, the appropriate response is 405 Method Not Allowed. Note: Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/501
|
notModified |
304 |
## 304 Not Modified The HTTP 304 Not Modified client redirection response code indicates that there is no need to retransmit the requested resources. This response code is sent when the request is a conditional GET or HEAD request with an If-None-Match or an If-Modified-Since header and the condition evaluates to false. It is an implicit redirection to a cached resource that would have resulted in a 200 OK response if the condition evaluated to true. The response must not contain a body and must include the headers that would have been sent in an equivalent 200 OK response: Cache-Control, Content-Location, Date, ETag, Expires, and Vary. Note: Many developer tools' network panels of browsers create extraneous requests leading to 304 responses, so that access to the local cache is visible to developers. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304
|
ok |
200 |
## 200 OK The HTTP 200 OK success status response code indicates that the request has succeeded. A 200 response is cacheable by default. The meaning of a success depends on the HTTP request method: The successful result of a PUT or a DELETE is often not a 200 OK but a 204 No Content (or a 201 Created when the resource is uploaded for the first time). Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200
|
partialContent |
206 |
## 206 Partial Content The HTTP 206 Partial Content success status response code indicates that the request has succeeded and the body contains the requested ranges of data, as described in the Range header of the request. If there is only one range, the Content-Type of the whole response is set to the type of the document, and a Content-Range is provided. If several ranges are sent back, the Content-Type is set to multipart/byteranges and each fragment covers one range, with Content-Range and Content-Type describing it. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206
|
paymentRequired |
402 |
## 402 Payment Required Experimental: This is an experimental technology Check the Browser compatibility table carefully before using this in production. The HTTP 402 Payment Required is a nonstandard response status code that is reserved for future use. This status code was created to enable digital cash or (micro) payment systems and would indicate that the requested content is not available until the client makes a payment. Sometimes, this status code indicates that the request cannot be processed until the client makes a payment. However, no standard use convention exists and different entities use it in different contexts. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402
|
permanentRedirect |
308 |
## 308 Permanent Redirect The HyperText Transfer Protocol (HTTP) 308 Permanent Redirect redirect status response code indicates that the resource requested has been definitively moved to the URL given by the Location headers. A browser redirects to this page and search engines update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is sent to the new URL). The request method and the body will not be altered, whereas 301 may incorrectly sometimes be changed to a GET method. Note: Some Web applications may use the 308 Permanent Redirect in a non-standard way and for other purposes. For example, Google Drive uses a 308 Resume Incomplete response to indicate to the client when an incomplete upload stalled. (See Perform a resumable download on Google Drive documentation.) Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308
|
preconditionFailed |
412 |
## 412 Precondition Failed The HyperText Transfer Protocol (HTTP) 412 Precondition Failed client error response code indicates that access to the target resource has been denied. This happens with conditional requests on methods other than GET or HEAD when the condition defined by the If-Unmodified-Since or If-None-Match headers is not fulfilled. In that case, the request, usually an upload or a modification of a resource, cannot be made and this error response is sent back. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412
|
preconditionRequired |
428 |
## 428 Precondition Required The HTTP 428 Precondition Required response status code indicates that the server requires the request to be conditional. Typically, this means that a required precondition header, such as If-Match, is missing. When a precondition header is not matching the server side state, the response should be 412 Precondition Failed. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/428
|
processing |
102 |
## Processing WebDAV A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet. This prevents the client from timing out and assuming the request was lost. |
proxyAuthenticationRequired |
407 |
## 407 Proxy Authentication Required The HTTP 407 Proxy Authentication Required client error status response code indicates that the request has not been applied because it lacks valid authentication credentials for a proxy server that is between the browser and the server that can access the requested resource. This status is sent with a Proxy-Authenticate header that contains information on how to authorize correctly. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/407
|
rangeNotSatisfiable |
416 |
## 416 Range Not Satisfiable The HyperText Transfer Protocol (HTTP) 416 Range Not Satisfiable error response code indicates that a server cannot serve the requested ranges. The most likely reason is that the document doesn't contain such ranges, or that the Range header value, though syntactically correct, doesn't make sense. The 416 response message contains a 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 Faced with this error, browsers usually either abort the operation (for example, a download will be considered as non-resumable) or ask for the whole document again. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416
|
requestHeaderFieldsTooLarge |
431 |
## 431 Request Header Fields Too Large The HTTP 431 Request Header Fields Too Large response status code indicates that the server refuses to process the request because the request's HTTP headers are too long. The request may be resubmitted after reducing the size of the request headers. 431 can be used when the total size of request headers is too large, or when a single header field is too large. To help those running into this error, indicate which of the two is the problem in the response body — ideally, also include which headers are too large. This lets users attempt to fix the problem, such as by clearing their cookies. Servers will often produce this status if: Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431
|
requestTimeout |
408 |
## 408 Request Timeout The HyperText Transfer Protocol (HTTP) 408 Request Timeout response status code means that the server would like to shut down this unused connection. It is sent on an idle connection by some servers, even without any previous request by the client. A server should send the "close" Connection header field in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. This response is used much more since some browsers, like Chrome, Firefox 27+, and IE9, use HTTP pre-connection mechanisms to speed up surfing. Note: some servers merely shut down the connection without sending this message. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/408
|
resetContent |
205 |
## 205 Reset Content The HTTP 205 Reset Content response status tells the client to reset the document view, so for example to clear the content of a form, reset a canvas state, or to refresh the UI. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/205
|
seeOther |
303 |
## 303 See Other The HyperText Transfer Protocol (HTTP) 303 See Other redirect status response code indicates that the redirects don't link to the requested resource itself, but to another page (such as a confirmation page, a representation of a real-world object — see HTTP range-14 — or an upload-progress page). This response code is often sent back as a result of PUT or POST. The method used to display this redirected page is always GET. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/303
|
serviceUnavailable |
503 |
## 503 Service Unavailable The HyperText Transfer Protocol (HTTP) 503 Service Unavailable server error response code indicates that the server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. This response should be used for temporary conditions and the Retry-After HTTP header should, if possible, contain the estimated time for the recovery of the service. Note: together with this response, a user-friendly page explaining the problem should be sent. Caching-related headers that are sent along with this response should be taken care of, as a 503 status is often a temporary condition and responses shouldn't usually be cached. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503
|
switchProxy |
306 |
## Switch Proxy Originally meant "Subsequent requests should use the specified proxy". Deprecated No longer used Since HTTP/1.1 |
switchingProtocols |
101 |
## 101 Switching Protocols The HTTP 101 Switching Protocols response code indicates a protocol to which the server switches. The protocol is specified in the Upgrade request header received from a client. The server includes in this response an Upgrade response header to indicate the protocol it switched to. The process is described in the following article: Protocol upgrade mechanism. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/101
|
temporaryRedirect |
307 |
## 307 Temporary Redirect HTTP 307 Temporary Redirect redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location headers. The method and the body of the original request are reused to perform the redirected request. In the cases where you want the method used to be changed to GET, use 303 See Other instead. This is useful when you want to give an answer to a PUT method that is not the uploaded resources, but a confirmation message (like "You successfully uploaded XYZ"). The only difference between 307 and 302 is that 307 guarantees that the method and the body will not be changed when the redirected request is made. With 302, some old clients were incorrectly changing the method to GET: the behavior with non-GET methods and 302 is then unpredictable on the Web, whereas the behavior with 307 is predictable. For GET requests, their behavior is identical. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307
|
tooManyRequests |
429 |
## 429 Too Many Requests The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time ("rate limiting"). A Retry-After header might be included to this response indicating how long to wait before making a new request. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429
|
unauthorized |
401 |
## 401 Unauthorized The HyperText Transfer Protocol (HTTP) 401 Unauthorized response status code indicates that the client request has not been completed because it lacks valid authentication credentials for the requested resource. This status code is sent with an HTTP WWW-Authenticate response header that contains information on how the client can request for the resource again after prompting the user for authentication credentials. This status code is similar to the 403 Forbidden status code, except that in situations resulting in this status code, user authentication can allow access to the resource. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401
|
unavailableForLegalReasons |
451 |
## 451 Unavailable For Legal Reasons The HyperText Transfer Protocol (HTTP) 451 Unavailable For Legal Reasons client error response 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/451
|
unprocessableContent |
422 |
## 422 Unprocessable Content The HyperText Transfer Protocol (HTTP) 422 Unprocessable Content response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions. Warning: The client should not repeat this request without modification. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422
|
unsupportedMediaType |
415 |
## 415 Unsupported Media Type The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format. 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. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415
|
upgradeRequired |
426 |
## 426 Upgrade Required The HTTP 426 Upgrade Required client error response 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 sends an Upgrade header with this response to indicate the required protocol(s). Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/426
|
uriTooLong |
414 |
## 414 URI Too Long The HTTP 414 URI Too Long response status code indicates that the URI requested by the client is longer than the server is willing to interpret. There are a few rare conditions when this might occur: Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/414
|
useProxy |
305 |
## Use Proxy The requested resource is available only through a proxy, the address for which is provided in the response. Many HTTP clients (such as Mozilla and Internet Explorer) do not correctly handle responses with this status code, primarily for security reasons. Deprecated Due to security concerns regarding in-band configuration of a proxy Since HTTP/1.1 |
variantAlsoNegotiates |
506 |
## 506 Variant Also Negotiates The HyperText Transfer Protocol (HTTP) 506 Variant Also Negotiates response status code may be given in the context of Transparent Content Negotiation (see RFC 2295). This protocol enables a client to retrieve the best variant of a given resource, where the server supports multiple variants. The Variant Also Negotiates status code indicates an internal server configuration error in which the chosen variant is itself configured to engage in content negotiation, so is not a proper negotiation endpoint. Documentation: copyright MDN Contributors under CC-BY-SA 2.5 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/506
|
▸ accumulate<K>(iterable, operator?, initial?): Generator<number, void, void>
Make an iterator that returns accumulated sums, or accumulated results of other binary functions (specified via the optional func argument).
Based on Python's itertools.accumulate
function
| Name | Type |
|---|---|
K |
extends Iterable<number> = Iterable<number> |
| Name | Type | Default value | Description |
|---|---|---|---|
iterable |
K |
undefined |
Iterable to accumulate values of |
operator |
Operators |
"+" |
Optional function that specifies the way items should be accumulated, or an arithmetic operator in string form to apply |
initial? |
number |
undefined |
Initial value to accumulate from, which is yielded once at the beginning if defined |
Generator<number, void, void>
- Generator of each item of
iterable, each item accumulated from the previous values
Example
Array.from(accumulate([1, 2, 3, 4, 5])) // [1, 3, 6, 10, 15]
Array.from(accumulate([1, 2, 3, 4, 5], undefined, 100)) // [100, 101, 103, 106, 110, 115]
Array.from(accumulate([1, 2, 3, 4, 5], (prev, current) => prev * current)) // [1, 2, 6, 24, 120]
Array.from(accumulate([1, 2, 3, 4, 5], "*") // [1, 2, 6, 24, 120]▸ arrayToChunks<T>(array, chunkSize?): T[][]
Splits an array into chunks
| Name | Description |
|---|---|
T |
Type of items in the array |
| Name | Type | Default value | Description |
|---|---|---|---|
array |
T[] |
undefined |
Array to split |
chunkSize |
number |
3 |
Size of array chunks |
T[][]
Array of each chunk in the form of arrays
Example
arrayToChunks([1, 2, 3, 4, 5, 5]) // [[1, 2, 3], [4, 5, 6]]
arrayToChunks([1, 2, 3, 4, 5, 5], 2) // [[1, 2], [3, 4], [5, 6]]▸ baseGcd(first, second): number
Recursive implementation of Euclid's GCD algorithm
| Name | Type | Description |
|---|---|---|
first |
number |
First number to get GCD for |
second |
number |
Second number to get GCD for |
number
Gcd of first and second
Example
baseGcd(10, 100) // 10
baseGcd(128, 64) // 64▸ between(lower, value, upper): number
Keeps a number between an upper and lower bound
| Name | Type | Description |
|---|---|---|
lower |
number |
Lower bound (inclusive) |
value |
number |
Value to bound |
upper |
number |
Upper bound (inclusive) |
number
Bound number
Example
const num = 5
between(0, num, 10) // 5
between(-1, num, 3) // 3
between(10, num, 30) // 10▸ capitalizeFirst(str): string
Capitalizes the first letter of a string
| Name | Type | Description |
|---|---|---|
str |
string |
String to apply capitalization to |
string
String with first letter capitalized
Example
capitalizeFirst("hello") // "Hello"
capitalizeFist("WORLD") // "WORLD"
capitalizeFirst("hello world!") // "Hello world!"▸ ceil(num, precision?): number
Ceils num to n decimal place
| Name | Type | Default value | Description |
|---|---|---|---|
num |
number |
undefined |
Number to ceil |
precision |
number |
0 |
Decimal place to ceil to |
number
Ceiled number
Example
ceil(123.456, 2) // 123.46
ceil(123.456, 1) // 123.5
ceil(123.456, -2) // 100▸ chain<T, K>(...iterables): Generator<IterableValue<IterableValue<K>>, void, void>
Chains iterables together into one iterable, from the first iterable until it is exhausted,
then proceeds to the next iterable, until all of the iterables are exhausted.
| Name | Type |
|---|---|
T |
T |
K |
extends Iterable<T>[] = Iterable<T>[] |
| Name | Type | Description |
|---|---|---|
...iterables |
K |
Array of iterables to chain together |
Generator<IterableValue<IterableValue<K>>, void, void>
Generator of the chained iterables
Remarks
Used for treating consecutive sequences as a single sequence.
Based on Python's itertools.chain
function
Example
function* generator1(): Generator<string> {
yield "a"
yield "b"
}
function* generator2(): Generator<number> {
yield 1
yield 2
yield 3
}
Array.from(chain(generator1(), generator2())) // ["a", "b", 1, 2, 3]
Array.from(chain(generator1(), generator2(), [4, 5, 6])) // ["a", "b", 1, 2, 3, 4, 5, 6]▸ choice<T>(arr): T
Return a random element from the non-empty array arr
| Name |
|---|
T |
| Name | Type | Description |
|---|---|---|
arr |
T[] |
Array to pick items from |
T
Random item chosen from arr
▸ compress<T>(data, selectors): Generator<T, void, void>
Make an iterator that filters elements from data returning only those that have a
corresponding element in selectors that is truthy. Stops when either the data or selectors
iterables has been exhausted.
Based on Pythons itertools.compress
function
| Name |
|---|
T |
| Name | Type | Description |
|---|---|---|
data |
Iterable<T> |
Iterable data to "compress" |
selectors |
Iterable<unknown> |
Selectors which dictate if a value of data should be included |
Generator<T, void, void>
Example
Array.from(compress("abcdef", [1, 0, 1, 0, 1, 1])) // ["a", "c", "e", "f"]
Array.from(compress([1, 2, 3, 4, 5, 6], [true, false, true, false])) // [1, 3]▸ count<T>(array, predicate, max?): number
Counts items in array that match the predicate
| Name | Description |
|---|---|
T |
Type of value in the array |
| Name | Type | Description |
|---|---|---|
array |
T[] |
Array to count items from |
predicate |
(value: T) => unknown
|
- |
max? |
number |
Max number of items to count |
number
Number of counted items
Example
const array = [true, true, true, false, false, false, false]
count(array, (val) => val) // 3
count(array, (val) => !val) // 4
count(array, (val) => !val, 2) // 2▸ createWrappedText(text, lengthThreshold, hyphenThreshold?, delimiter?): string[]
Splits text by maximum line length
| Name | Type | Default value | Description |
|---|---|---|---|
text |
string |
undefined |
Text to split |
lengthThreshold |
number |
undefined |
Max line length, non-strict (string length will be up to and including the value of threshold) |
hyphenThreshold |
number |
defaultHyphenThreshold |
Percentage of line filled before a word should not be hyphenated. This allows long words to be hyphenated when neccesary, while shorter words will create a new line. A value of 0 will always prefer creating a new line instead of hyphenating, unless a word is longer than the set threshold (then it will be hyphenated as many times as needed). A value of 1 will always hyphenate words if they do not fit perfectly. A value between (1, +infty) will be interpreted as a length, rather than percentage. I should probably write a more detailed spec as to how this thing behaves. |
delimiter |
string | RegExp
|
" " |
String or Regex for splitting text |
string[]
Array of lines wrapped to threshold
▸ cycle<T, K>(iterable): Generator<IterableValue<K>, void, void>
Make an iterator returning elements from the iterable and saving a copy of each. When the iterable is exhausted, return elements from the saved copy. Repeats indefinitely.
Based on Python's itertools.cycle
function
| Name | Type |
|---|---|
T |
T |
K |
extends Iterable<T> = Iterable<T> |
| Name | Type | Description |
|---|---|---|
iterable |
K |
Iterable to cycle through |
Generator<IterableValue<K>, void, void>
Generator of the elements of iterable
Example
Array.from(zip([1, 2, 3], cycle("abc"))) // [[1, "a"], [2, "b"], [3, "c"]]
Array.from(cycle([1, 2, 3])) // [1, 2, 3, 1, 2, 3, 1, 2, 3 ...(forever)]▸ debounce<Args>(func, ms): (...args: Args) => void
Delay the execution of a function, and reset said delay if the function is called again within the delay window.
| Name | Type |
|---|---|
Args |
extends unknown[] |
| Name | Type | Description |
|---|---|---|
func |
(...args: Args) => void
|
Function to debounce |
ms |
number |
Time to wait |
fn
Debounced function
▸ (...args): void
| Name | Type |
|---|---|
...args |
Args |
void
Example
window.addEventListener(
"resize",
debounce((event) => console.log(event), 100),
)▸ dropWhile<T>(iterable, predicate): Generator<T>
Make an iterator that drops elements from iterable as long as the predicate is true;
afterwards, returns every element
Based on Python's itertools.dropwhile
function
| Name |
|---|
T |
| Name | Type | Description |
|---|---|---|
iterable |
Iterable<T> |
Iterable to get and drop items from |
predicate |
(val: T) => boolean
|
Function that determines from which values to include |
Generator<T>
Generator of each item after the predicate is fulfulled
Remarks
The iterator does not produce any output until the predicate first becomes false, so it may have a lengthy start-up time.
Example
Array.from(dropWhile([1, 4, 6, 4, 1], (val) => val < 5)) // [6, 4, 1]
Array.from(dropWhile("abcdefg", (val) => val !== "d")) // ["d", "e", "f", "g"]▸ enumerate<T>(iterable, start?): Iterable<[index: number, value: T]>
Array.entries equivalent with support for iterables
Based on Python's enumerate
| Name | Description |
|---|---|
T |
Type of the iterable's items |
| Name | Type | Default value | Description |
|---|---|---|---|
iterable |
Iterable<T> |
undefined |
Iterable to enumerate |
start |
number |
0 |
- |
Iterable<[index: number, value: T]>
Iterable with a tuple containing the index and value of the iterable item
Example
const seasons = ["Spring", "Summer", "Fall", "Winter"]
Array.from(enumerate(seasons)) // [[0, 'Spring'], [1, 'Summer'], [2, 'Fall'], [3, 'Winter']]
Array.from(enumerate(seasons, 1)) // [[1, 'Spring'], [2, 'Summer'], [3, 'Fall'], [4, 'Winter']]▸ escapeRegex(str): string
Escapes string for use in regular expressions
| Name | Type | Description |
|---|---|---|
str |
string |
String to escape regex characters |
string
String with values escaped for regex
Example
const string = "**string**"
new RegExp(string) // Uncaught SyntaxError: Invalid regular expression: /**string**/: Nothing to repeat
new RegExp(escapeRegex(string)) // OK▸ filter<T>(iterable, predicate, maxSize?): Generator<T, void, void>
Array.filter equivalent with size limit and support for iterables
| Name | Description |
|---|---|
T |
Type of the iterable's items |
| Name | Type | Default value | Description |
|---|---|---|---|
iterable |
Iterable<T> |
undefined |
Iterable to filter |
predicate |
(value: T, index: number) => unknown
|
undefined |
Function to determine if item is filtered out or not |
maxSize |
number |
Infinity |
Max number of items in filter; stop after this number is reached |
Generator<T, void, void>
Generator of each item that isn't filtered and within the limit
Example
const array = [true, true, true, false, false, false, false]
Array.from(filter(array, (val) => val)) // [true, true, true]
Array.from(filter(array, (val) => val, 2)) // [true, true]
Array.from(filter("abcdefg", (val) => val !== "a", 3)) // ["b", "c", "d"]▸ filterMap<T, K>(array, callbackFn): K[]
Map and filter in one loop
| Name | Description |
|---|---|
T |
Type of original values in the array |
K |
Typeof the new, filtered and mapped values |
| Name | Type | Description |
|---|---|---|
array |
T[] |
Array to filter and map |
callbackFn |
FilterMapCallback<T, K> |
Callback to call on every item, which should return an object that indicates whether or not the value should be shouldIncluded, and what the new value is |
K[]
Array of each item that goes through callbackFn
Example
const array = [true, true, true, false, false, false, false]
filterMap(array, (val, index) => ({
shouldInclude: val,
value: index,
})) // [0, 1, 2]
filterMap(array, (val, index) => ({
shouldInclude: !val,
value: index,
})) // [3, 4, 5, 6]▸ floor(num, precision?): number
Floors num to n decimal place
| Name | Type | Default value | Description |
|---|---|---|---|
num |
number |
undefined |
Number to floor |
precision |
number |
0 |
Decimal place to floor to |
number
Floored number
Example
floor(123.456, 2) // 123.45
floor(123.456, 1) // 123.4
floor(123.456, -2) // 100▸ gcd(...numbers): number
Computes the GCD using array reduce and Euclid's GCD algorithm
| Name | Type | Description |
|---|---|---|
...numbers |
[number, number, ...number[]] |
All the numbers to get the GCD for - must include at least 2 numbers |
number
The gcd of all the numbers
Example
gcd(10, 20, 30) // 10
gcd(13924, 1249, 123, 3) // 1▸ getPrimesUpTo(max): Generator<number>
Generates all prime numbers up to max using the Sieve of Eratosthenes
| Name | Type | Description |
|---|---|---|
max |
number |
Prime number to go up to |
Generator<number>
Generator of each prime number
Example
Array.from(getPrimesUpTo(30)) // [2, 3, 5, 7, 11, 13, 17, 19, 23, 29]
Array.from(getPrimseUpTo(10)) // [2, 3, 5, 7]
Array.from(getPrimseUpTo(7)) // [2, 3, 5]▸ increment(start?, step?): Generator<number, void, void>
Make an iterator that returns evenly spaced values step apart starting with number start
Based on Python's itertools.count
function
| Name | Type | Default value | Description |
|---|---|---|---|
start |
number |
0 |
Start number |
step |
number |
1 |
Amount to increment |
Generator<number, void, void>
Generator of evenly spaced values step apart starting with number start
Example
Array.from(zip([1, 2, 3], increment())) // [[1, 1], [2, 2], [3, 3]]
Array.from(increment()) // [0, 1, 2, 3, 4, ...(forever)]
Array.from(increment(10, 2)) // [10, 12, 14, 16, ...(forever)]▸ inlineTry<T>(func, shouldKeepError): undefined | T
Tries to execute func and returns or discards any error that occurs
| Name | Description |
|---|---|
T |
Type of data that will be returned by the callback |
| Name | Type | Description |
|---|---|---|
func |
() => T
|
Callback function |
shouldKeepError |
false |
If error should be returned |
undefined | T
Return value of func. If an error is thrown, return it if shouldKeepError is true,
else discard it
Example
inlineTry(() => {
throw new Error("Error!")
}) // Error: Error!
inlineTry(() => {
throw new Error("Error!")
}, false) // undefined
inlineTry(() => 1, true) // 1
inlineTry(() => 1, false) // 1▸ inlineTry<T>(func, shouldKeepError?): Error | T
Tries to execute func and returns or discards any error that occurs
| Name | Description |
|---|---|
T |
Type of data that will be returned by the callback |
| Name | Type | Description |
|---|---|---|
func |
() => T
|
Callback function |
shouldKeepError? |
true |
If error should be returned |
Error | T
Return value of func. If an error is thrown, return it if shouldKeepError is true,
else discard it
Example
inlineTry(() => {
throw new Error("Error!")
}) // Error: Error!
inlineTry(() => {
throw new Error("Error!")
}, false) // undefined
inlineTry(() => 1, true) // 1
inlineTry(() => 1, false) // 1▸ inlineTryPromise<T>(func, shouldKeepError): Promise<undefined | T>
Tries to execute and await func and returns or discards any error that occurs
| Name | Description |
|---|---|
T |
Type of data that will be returned by the callback |
| Name | Type | Description |
|---|---|---|
func |
() => Promise<T> |
Callback function |
shouldKeepError |
false |
If error should be returned |
Promise<undefined | T>
Return value of func. If an error is thrown, return it if shouldKeepError is true,
else discard it
Example
await inlineTryPromise(async () => {
await Promise.resolve()
throw new Error("Error!")
}, true) // Error: Error!
await inlineTryPromise(async () => {
await Promise.resolve()
throw new Error("Error!")
}, false) // undefined
await inlineTryPromise(async () => await Promise.resolve(1), false) // 1
await inlineTryPromise(async () => await Promise.resolve(1), true) // 1▸ inlineTryPromise<T>(func, shouldKeepError?): Promise<Error | T>
Tries to execute and await func and returns or discards any error that occurs
| Name | Description |
|---|---|
T |
Type of data that will be returned by the callback |
| Name | Type | Description |
|---|---|---|
func |
() => Promise<T> |
Callback function |
shouldKeepError? |
true |
If error should be returned |
Promise<Error | T>
Return value of func. If an error is thrown, return it if shouldKeepError is true,
else discard it
Example
await inlineTryPromise(async () => {
await Promise.resolve()
throw new Error("Error!")
}, true) // Error: Error!
await inlineTryPromise(async () => {
await Promise.resolve()
throw new Error("Error!")
}, false) // undefined
await inlineTryPromise(async () => await Promise.resolve(1), false) // 1
await inlineTryPromise(async () => await Promise.resolve(1), true) // 1▸ isEqual(val1, val2, maxDepth?, maxLength?): boolean
Checks if val1 and val2 are equal. Works like lodash isEqual, and is just as fast.
| Name | Type | Description |
|---|---|---|
val1 |
unknown |
Value to check for equality |
val2 |
unknown |
Value to compare against val1 |
maxDepth? |
number |
Max recursion depth to crawl an object. After max depth is reached, the two values are simply compared with ===. If undefined, it will be treated as Infinity. It may be a good idea to set this value to prevent a catastrophe. |
maxLength? |
number |
Max length of an array to crawl. If max length is reached, two arrays will simply be compared with ===. If undefined, it will be treated as Infinity. It may be a good idea to set this value to prevent a catastrophe. |
boolean
If val1 is deeply equal to val2
Remarks
BEFORE YOU USE THIS: think to yourself, "Do I need this?" If there's another way, it's problably faster. Deep equality checking is a very costly operation and should be used sparingly
▸ isEqualArray(obj1, obj2, maxDepth?, maxLength?): boolean
Checks if arr1 and arr2 are equal, given that they are both arrays
| Name | Type | Description |
|---|---|---|
obj1 |
unknown[] |
- |
obj2 |
unknown[] |
- |
maxDepth? |
number |
Max recursion depth to crawl an object. After max depth is reached, the two values are simply compared with ===. If undefined, it will be treated as Infinity. It may be a good idea to set this value to prevent a catastrophe. |
maxLength? |
number |
Max length of an array to crawl. If max length is reached, two arrays will simply be compared with ===. If undefined, it will be treated as Infinity. It may be a good idea to set this value to prevent a catastrophe. |
boolean
If arr1 is deeply equal to arr2
▸ isEqualObject(obj1, obj2, maxDepth?, maxLength?): boolean
Checks if obj1 and obj2 are equal, given that they are both arrays
| Name | Type | Description |
|---|---|---|
obj1 |
object |
Object to check for equality |
obj2 |
object |
Object to compare against val1 |
maxDepth? |
number |
Max recursion depth to crawl an object. After max depth is reached, the two values are simply compared with ===. If undefined, it will be treated as Infinity. It may be a good idea to set this value to prevent a catastrophe. |
maxLength? |
number |
Max length of an array to crawl. If max length is reached, two arrays will simply be compared with ===. If undefined, it will be treated as Infinity. It may be a good idea to set this value to prevent a catastrophe. |
boolean
If obj1 is deeply equal to obj2
▸ isErrorLike(obj): obj is Object
Check if error like (i.e has the name and message properties, both of which are strings)
| Name | Type | Description |
|---|---|---|
obj |
unknown |
Object to check |
obj is Object
If object is error-like
Example
isErrorLike(new Error()) // True
isErrorLike({name: "Error!", message: "This is an error", other: 0}) // True
isErrorLike({}) // False
isErrorLike({name: "Error", message: null}) // False
// Works as a typguard
const something = {name: "Error", message: "This is an error"} as unknown
if (isErrorLike(something)) {
console.log(something.name) // No Typescript error
}▸ isObject(obj): obj is Object
Check if object like (typeof object and not null)
| Name | Type | Description |
|---|---|---|
obj |
unknown |
Object to check |
obj is Object
If object is error-like
Example
isErrorLike({}) // True
isErrorLike(/regex/) // True
isErrorLike(new Date()) // True
isErrorLike("string") // False
// Works as a typguard
const something = {} as unknown
if (isObject(something)) {
// No Typescript error
console.log(something.property)
}
if (typeof something === "object" && something !== null) {
// Property 'property' does not exist on type 'object'. ts(2339)
console.log(something.property)
}▸ isPrime(num): boolean
Checks if a number is prime
| Name | Type | Description |
|---|---|---|
num |
number |
Number to check |
boolean
If num is prime or not
Example
isPrime(2) // true
isPrime(10) // false
isPrime(31) // true▸ islice<T>(iterable): Generator<T, void, void>
Make an iterator that returns all the elements from iterable consecutively
Based on Python's itertools.islice
function
| Name | Description |
|---|---|
T |
Type of the iterable's items |
| Name | Type | Description |
|---|---|---|
iterable |
Iterable<T> |
Iterable to get elements from |
Generator<T, void, void>
Generator of each element of iterable
Example
Array.from(islice("abcdefg")) // ["a", "b", "c", "d", "e", "f", "g"]▸ islice<T>(iterable, end): Generator<T, void, void>
Make an iterator that returns the elements from iterable consecutively, from 0 - end
| Name | Description |
|---|---|
T |
Type of the iterable's items |
| Name | Type | Description |
|---|---|---|
iterable |
Iterable<T> |
Iterable to get elements from |
end |
number |
The index at which to stop slicing the iterable, non-inclusive |
Generator<T, void, void>
Generator of the elements from iterable sliced from 0 to end
Remarks
Sliced iterable is non-inclusive of end, where end is a non-negative number
Based on Python's itertools.islice
function
Example
Array.from(islice("abcdefg", 2)) // ["a", "b"]▸ islice<T>(iterable, start, end): Generator<T, void, void>
Make an iterator that returns the elements from iterable consecutively, from start - end,
| Name | Description |
|---|---|
T |
Type of the iterable's items |
| Name | Type | Description |
|---|---|---|
iterable |
Iterable<T> |
Iterable to get elements from |
start |
number |
The index at which to start slicing the iterable |
end |
null | number
|
The index at which to stop slicing the iterable, non-inclusive |
Generator<T, void, void>
Generator of the elements from iterable sliced from 0 to end
Remarks
Slice is non-inclusive of end, where start and end are non-negative numbers. If end is
null, slice from start to the end of the iterator
Based on Python's itertools.islice
function
Example
Array.from(islice("abcdefg", 2, 4)) // ["c", "d"]
Array.from(islice("abcdefg", 2, null)) // ["c", "d", "e", "f", "g"]▸ islice<T>(iterable, start, end, step): Generator<T, void, void>
Make an iterator that returns the elements from iterable for every stepth element, from
start - end
| Name | Description |
|---|---|
T |
Type of the iterable's items |
| Name | Type | Description |
|---|---|---|
iterable |
Iterable<T> |
Iterable to get elements from |
start |
number |
The index at which to start slicing the iterable |
end |
null | number
|
The index at which to stop slicing the iterable, non-inclusive |
step |
number |
The increment at which to slice items |
Generator<T, void, void>
Generator of the elements from iterable sliced from 0 to end
Remarks
Slice is non-inclusive of end, where start, end, and step are non-negative numbers. If
end is null, slice from start to the end of the iterator
Based on Python's itertools.islice
function
Example
Array.from(islice("abcdefg", 0, null, 2)) // ["a", "c", "e", "g"]
Array.from(islice("abcdefg", 0, 4, 2)) // ["a", "c"]▸ map<T, K>(iterable, transformer): Generator<K, void, void>
Array.map equivalent with support for iterables
| Name | Description |
|---|---|
T |
Type of the iterable's items |
K |
Type of the transformer function's return |
| Name | Type | Description |
|---|---|---|
iterable |
Iterable<T> |
Iterable with items to map |
transformer |
(val: T, index: number) => K
|
Function to transform each item in iterable |
Generator<K, void, void>
Generator of each item, passed through the transformer function
Example
const array = [1, 2, 3, 4, 5, 6]
Array.from(map(array, (val) => val % 2 === 0)) // [false, true, false, true, false, true]
Array.from(map(array, (val) => val - 1)) // [0, 1, 2, 3, 4, 5]
Array.from(map("abc", (val: string) => val + "a")) // ["aa", "ba", "ca"]▸ objectEntries<T>(obj): Generator<{ [K in keyof T]: [K, T[K]] }[keyof T], void, void>
Better Object.entries, which is faster, returns an iterator instead of an array (more memory
efficient), and is typed better
| Name | Type |
|---|---|
T |
extends Object
|
| Name | Type | Description |
|---|---|---|
obj |
T |
Object to get entries for |
Generator<{ [K in keyof T]: [K, T[K]] }[keyof T], void, void>
Generator producing the key and value of each item
Example
Array.from(objectEntries({a: 1, b: 2})) // [["a", 1], ["b", 2]]▸ omit<T, K>(obj, ...keys): Omit<T, K[number]>
Omits values from an object and creates a new object
| Name | Type | Description |
|---|---|---|
T |
extends Object
|
Type of the object to omit items from |
K |
extends keyof T[] |
Type of the keys used to omit items |
| Name | Type | Description |
|---|---|---|
obj |
T |
Object to omit keys from |
...keys |
K |
Keys to omit |
Omit<T, K[number]>
Object from omitted values
Example
omit({a: 1, b: 2, c: 3}, "a", "b") // {c: 3}▸ pick<T, K>(obj, ...keys): Pick<T, K[number]>
Picks values from an object and creates a new object
| Name | Type | Description |
|---|---|---|
T |
extends Object
|
Type of the object to pick items from |
K |
extends keyof T[] |
Type of the keys used to pick out items |
| Name | Type | Description |
|---|---|---|
obj |
T |
Object to pick keys from |
...keys |
K |
Keys to pick |
Pick<T, K[number]>
Object from picked values
Example
pick({a: 1, b: 2, c: 3}, "a", "b") // {a: 1, b: 2}▸ pickAll<T, K>(obj, ...keys): Pick<T, K[number]>
Picks values from an object and creates a new object, and picks undefined properties as well
| Name | Type | Description |
|---|---|---|
T |
extends Object
|
Type of the object to pick items from |
K |
extends keyof T[] |
Type of the keys used to pick out items |
| Name | Type | Description |
|---|---|---|
obj |
T |
Object to pick keys from |
...keys |
K |
Keys to pick |
Pick<T, K[number]>
Object from picked values
Example
pick({a: 1, b: 2, c: 3}, "a", "b") // {a: 1, b: 2, d: undefined}▸ randint(min, max): number
Generates a pseudo-random integer N, such that min <= N < max
| Name | Type | Description |
|---|---|---|
min |
number |
Smallest random integer possible |
max |
number |
Largest random integer possible, non-inclusive |
number
Random integer between min and max
▸ range(stop): Generator<number, void, void>
Make an iterator that generates numbers by increments by 1 from [0, stop)
Based on Python's range class
| Name | Type | Description |
|---|---|---|
stop |
number |
End of range |
Generator<number, void, void>
Generator of evenly spaced values from 0 (inclusive) to stop (non-inclusive) by
increments of 1
Example
Array.from(range(10)) // [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Array.from(range(1, 11)) // [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
Array.from(range(0, 30, 5)) // [0, 5, 10, 15, 20, 25]
Array.from(range(0, 10, 3)) // [0, 3, 6, 9]
Array.from(range(0, -10, -1)) // [0, -1, -2, -3, -4, -5, -6, -7, -8, -9]
Array.from(range(0)) // []
Array.from(range(1, 0)) // []▸ range(start, stop, step?): Generator<number, void, void>
Make an iterator that generates numbers by increments by step from [start, stop)
Based on Python's range class
| Name | Type | Description |
|---|---|---|
start |
number |
Start of range |
stop |
number |
End of range |
step? |
number |
Increment step, 1 by default |
Generator<number, void, void>
Generator of evenly spaced values from 0 (inclusive) to end (non-inclusive) by
increments of 1
Example
Array.from(range(10)) // [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Array.from(range(1, 11)) // [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
Array.from(range(0, 30, 5)) // [0, 5, 10, 15, 20, 25]
Array.from(range(0, 10, 3)) // [0, 3, 6, 9]
Array.from(range(0, -10, -1)) // [0, -1, -2, -3, -4, -5, -6, -7, -8, -9]
Array.from(range(0)) // []
Array.from(range(1, 0)) // []▸ reduce<T>(iterable, reducer, defaultValue?): T
Array.reduce equivalent with support for iterables
| Name | Description |
|---|---|
T |
Type of the iterable's items |
| Name | Type | Description |
|---|---|---|
iterable |
Iterable<T> |
Iterable with items to map |
reducer |
(accumulated: T, currentValue: T, index: number) => T
|
- |
defaultValue? |
T |
- |
T
Generator of each item, passed through the transformer function
Example
const array = [1, 2, 3, 4, 5, 6]
reduce([], (val: number) => val + 1) // Uncaught TypeError: Reduce of empty array with no initial value
reduce(array, (prev, current) => prev + current) // 15
reduce(array, (prev, current) => prev + current, 10) // 25
reduce("abcdef", (prev, current) => (current === "c" ? prev : prev + current)) // "abdef"Throws
TypeError - if an empty array is given with no initial value
▸ repeat<T>(item, times?): Generator<T, void, void>
Make an iterator that yields item over and over again. Runs indefinitely unless the times
argument is specified.
Based on Pythons itertools.repeat
function
| Name |
|---|
T |
| Name | Type | Description |
|---|---|---|
item |
T |
Item to repeat |
times? |
number |
Number of times to repeat item, or undefined for indefinite repeat |
Generator<T, void, void>
Generator of item until times is reached
Example
Array.from(repeat(10, 3)) // [10, 10, 10]
Array.from(zip([1, 2, 3], repeat(10))) // [[1, 10], [2, 10], [3, 10]]▸ round(num, precision?): number
Round num to n decimal place
| Name | Type | Default value | Description |
|---|---|---|---|
num |
number |
undefined |
Number to round |
precision |
number |
0 |
Decimal place to round to |
number
Rounded number
Example
round(123.456, 2) // 123.46
round(123.456, 1) // 123.5
round(123.456, -2) // 100▸ runIfDefined<T, R>(value, func): undefined | R
Passes value into func if defined, otherwise skips it
| Name | Description |
|---|---|
T |
Parameter type |
R |
Function return type |
| Name | Type | Description |
|---|---|---|
value |
undefined | T
|
Value to pass into function |
func |
(param: T) => R
|
Function to call if value is defined |
undefined | R
Undefined if value is undefined, else function result
Deprecated
Use optional chaining instead
Example
let myValue: string | undefined = undefined
runIfDefined(myValue, myFunc) // No-op
// Same as
// myValue === undefined ? undefined : myFunc(myValue)
myValue = "string"
runIfDefined(myValue, myFunc) // Runs myFunc with myValue▸ shuffle<T>(array, cycles?): T[]
Shuffles an array in-place and returns the array
| Name |
|---|
T |
| Name | Type | Default value | Description |
|---|---|---|---|
array |
T[] |
undefined |
Array to shuffle |
cycles |
number |
1 |
Number of shuffle cycles to go through |
T[]
Reference to array
▸ takeWhile<T>(iterable, predicate): Generator<T>
Make an iterator that returns elements from iterable as long as the predicate is true, and
stops after it returns false
Based on Python's itertools.takewhile
function
| Name |
|---|
T |
| Name | Type | Description |
|---|---|---|
iterable |
Iterable<T> |
Iterable to get and take items from |
predicate |
(val: T) => boolean
|
Function that determines from which values to include |
Generator<T>
Generator of each item until predicate returns false
Example
Array.from(takeWhile([1, 4, 6, 4, 1], (val) => val < 5)) // [1, 4]
Array.from(takeWhile("abcdefg", (val) => val !== "d")) // ["a", "b", "c"]▸ toTitleCase(str): string
Converts a string to title case, i.e the first letter of each "word" is capitalized, and the rest converted to lowercase
| Name | Type | Description |
|---|---|---|
str |
string |
String to apply capitalizations to |
string
String in title case
Example
toTitleCase("hello world!") // "Hello World"
toTitleCase("This is a Title") // "This Is A Title"▸ trunc(num, precision?): number
Truncate num to n decimal place
| Name | Type | Default value | Description |
|---|---|---|---|
num |
number |
undefined |
Number to truncate |
precision |
number |
0 |
Decimal place to truncate to |
number
Truncated number
Example
trunc(123.456, 2) // 123.46
trunc(123.456, 1) // 123.5
trunc(123.456, -2) // 100▸ uniform(min, max): number
Generates a pseudo-random floating point number N, such that min <= N < max
| Name | Type | Description |
|---|---|---|
min |
number |
Smallest random integer possible |
max |
number |
Largest random integer possible, non-inclusive |
number
Random floating point number between min and max
▸ zip<T>(...iterables): Generator<GetIteratorTupleValues<T>, void, void>
Creates a generator of the n'th element of each iterable, such that n < length of smallest iterable
Based on Python's zip function
| Name | Type |
|---|---|
T |
extends Iterable<unknown>[] = Iterable<unknown>[] |
| Name | Type | Description |
|---|---|---|
...iterables |
T |
Array of iterables to zip together |
Generator<GetIteratorTupleValues<T>, void, void>
Generator of the n'th element of each iterable, such that n < length of smallest iterable
Example
function* generator1(): Generator<string> {
yield "a"
yield "b"
}
function* generator2(): Generator<number> {
yield 1
yield 2
yield 3
}
Array.from(zip(generator1(), generator2())) // [["a", 1], ["b", 2]]
Array.from(zip(["a", "b"], [1, 2, 3])) // [["a", 1], ["b", 2]]