@forklaunch/core 0.1.3 → 0.1.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (55) hide show
  1. package/dist/cache/redisTtlCache.d.ts +1 -0
  2. package/dist/cache/redisTtlCache.js +1 -0
  3. package/dist/cache/redisTtlCache.js.map +1 -1
  4. package/dist/entityMapper/interfaces/entityMapper.interface.d.ts +1 -0
  5. package/dist/entityMapper/models/baseEntityMapper.model.d.ts +7 -7
  6. package/dist/entityMapper/models/baseEntityMapper.model.js +7 -7
  7. package/dist/entityMapper/models/baseEntityMapper.model.js.map +1 -1
  8. package/dist/entityMapper/models/requestEntityMapper.model.d.ts +13 -9
  9. package/dist/entityMapper/models/requestEntityMapper.model.js +13 -9
  10. package/dist/entityMapper/models/requestEntityMapper.model.js.map +1 -1
  11. package/dist/entityMapper/models/responseEntityMapper.model.d.ts +14 -7
  12. package/dist/entityMapper/models/responseEntityMapper.model.js +12 -6
  13. package/dist/entityMapper/models/responseEntityMapper.model.js.map +1 -1
  14. package/dist/entityMapper/types/entityMapper.types.d.ts +2 -2
  15. package/dist/http/httpStatusCodes.d.ts +74 -0
  16. package/dist/http/httpStatusCodes.js +1050 -0
  17. package/dist/http/httpStatusCodes.js.map +1 -0
  18. package/dist/http/index.d.ts +4 -1
  19. package/dist/http/index.js +4 -1
  20. package/dist/http/index.js.map +1 -1
  21. package/dist/http/middleware/index.js.map +1 -0
  22. package/dist/http/middleware/request.middleware.d.ts +95 -0
  23. package/dist/http/{middlewares → middleware}/request.middleware.js +105 -2
  24. package/dist/http/middleware/request.middleware.js.map +1 -0
  25. package/dist/http/middleware/response.middleware.d.ts +14 -0
  26. package/dist/http/middleware/response.middleware.js +53 -0
  27. package/dist/http/middleware/response.middleware.js.map +1 -0
  28. package/dist/http/openApiV3Generator.d.ts +13 -0
  29. package/dist/http/openApiV3Generator.js +177 -0
  30. package/dist/http/openApiV3Generator.js.map +1 -0
  31. package/dist/http/regex.d.ts +8 -0
  32. package/dist/http/regex.js +115 -0
  33. package/dist/http/regex.js.map +1 -0
  34. package/dist/http/types/api.types.d.ts +71 -0
  35. package/dist/http/types/forklaunch.types.d.ts +30 -0
  36. package/dist/http/types/forklaunch.types.js +3 -0
  37. package/dist/http/types/forklaunch.types.js.map +1 -0
  38. package/dist/http/types/index.d.ts +1 -0
  39. package/dist/http/types/index.js +1 -0
  40. package/dist/http/types/index.js.map +1 -1
  41. package/dist/http/types/primitive.types.d.ts +73 -0
  42. package/dist/tests/http.middleware.test.js +1 -1
  43. package/dist/tests/http.middleware.test.js.map +1 -1
  44. package/dist/tests/openApiV3Generator.test.d.ts +1 -0
  45. package/dist/tests/openApiV3Generator.test.js +71 -0
  46. package/dist/tests/openApiV3Generator.test.js.map +1 -0
  47. package/package.json +3 -2
  48. package/dist/http/middlewares/index.js.map +0 -1
  49. package/dist/http/middlewares/request.middleware.d.ts +0 -11
  50. package/dist/http/middlewares/request.middleware.js.map +0 -1
  51. package/dist/http/middlewares/response.middleware.d.ts +0 -3
  52. package/dist/http/middlewares/response.middleware.js +0 -33
  53. package/dist/http/middlewares/response.middleware.js.map +0 -1
  54. /package/dist/http/{middlewares → middleware}/index.d.ts +0 -0
  55. /package/dist/http/{middlewares → middleware}/index.js +0 -0
@@ -0,0 +1,1050 @@
1
+ "use strict";
2
+ Object.defineProperty(exports, "__esModule", { value: true });
3
+ exports.getCodeForStatus = exports.isServerError = exports.isClientError = exports.isRedirection = exports.isSuccessful = exports.isInformational = exports.isValidStatusCode = exports.HTTPStatuses = void 0;
4
+ /**
5
+ * Object-map of the HTTP Status Codes. Maps from the status code, to the
6
+ * textual name. The key is the HTTP Status Code number, and the resulting
7
+ * value will be the textual name for that Status Code.
8
+ *
9
+ * The comments for each item are taken from httpstatuses.com and the RFC-7231
10
+ * document.
11
+ *
12
+ * @see https://httpstatuses.com
13
+ * @see https://datatracker.ietf.org/doc/html/rfc7231
14
+ */
15
+ exports.HTTPStatuses = {
16
+ /**
17
+ * The initial part of a request has been received and has not yet been
18
+ * rejected by the server. The server intends to send a final response after
19
+ * the request has been fully received and acted upon.
20
+ *
21
+ * When the request contains an Expect header field that includes a
22
+ * 100-continue expectation, the 100 response indicates that the server
23
+ * wishes to receive the request payload body. The client ought to continue
24
+ * sending the request and discard the 100 response.
25
+ *
26
+ * If the request did not contain an Expect header field containing the
27
+ * 100-continue expectation, the client can simply discard this interim
28
+ * response.
29
+ */
30
+ 100: 'Continue',
31
+ /**
32
+ * The server understands and is willing to comply with the client's request,
33
+ * via the Upgrade header field, for a change in the application protocol
34
+ * being used on this connection.
35
+ *
36
+ * The server MUST generate an Upgrade header field in the response that
37
+ * indicates which protocol(s) will be switched to immediately after the
38
+ * empty line that terminates the 101 response.
39
+ *
40
+ * It is assumed that the server will only agree to switch protocols when it
41
+ * is advantageous to do so. For example, switching to a newer version of
42
+ * HTTP might be advantageous over older versions, and switching to a
43
+ * real-time, synchronous protocol might be advantageous when delivering
44
+ * resources that use such features.
45
+ */
46
+ 101: 'Switching Protocols',
47
+ /**
48
+ * An interim response used to inform the client that the server has accepted
49
+ * the complete request, but has not yet completed it.
50
+ *
51
+ * This status code SHOULD only be sent when the server has a reasonable
52
+ * expectation that the request will take significant time to complete. As
53
+ * guidance, if a method is taking longer than 20 seconds (a reasonable, but
54
+ * arbitrary value) to process the server SHOULD return a 102 (Processing)
55
+ * response. The server MUST send a final response after the request has been
56
+ * completed.
57
+ *
58
+ * Methods can potentially take a long period of time to process, especially
59
+ * methods that support the Depth header. In such cases the client may
60
+ * time-out the connection while waiting for a response. To prevent this the
61
+ * server may return a 102 Processing status code to indicate to the client
62
+ * that the server is still processing the method.
63
+ */
64
+ 102: 'Processing',
65
+ /**
66
+ * The request has succeeded.
67
+ *
68
+ * Aside from responses to CONNECT, a 200 response always has a payload,
69
+ * though an origin server MAY generate a payload body of zero length. If no
70
+ * payload is desired, an origin server ought to send 204 No Content instead.
71
+ * For CONNECT, no payload is allowed because the successful result is a
72
+ * tunnel, which begins immediately after the 200 response header section.
73
+ *
74
+ * A 200 response is cacheable by default; i.e., unless otherwise indicated
75
+ * by the method definition or explicit cache controls.
76
+ */
77
+ 200: 'OK',
78
+ /**
79
+ * The request has been fulfilled and has resulted in one or more new
80
+ * resources being created.
81
+ *
82
+ * The primary resource created by the request is identified by either a
83
+ * Location header field in the response or, if no Location field is
84
+ * received, by the effective request URI.
85
+ *
86
+ * The 201 response payload typically describes and links to the resource(s)
87
+ * created. See Section 7.2 of RFC7231 for a discussion of the meaning and
88
+ * purpose of validator header fields, such as ETag and Last-Modified, in a
89
+ * 201 response.
90
+ */
91
+ 201: 'Created',
92
+ /**
93
+ * The request has been accepted for processing, but the processing has not
94
+ * been completed. The request might or might not eventually be acted upon,
95
+ * as it might be disallowed when processing actually takes place.
96
+ *
97
+ * There is no facility in HTTP for re-sending a status code from an
98
+ * asynchronous operation.
99
+ *
100
+ * The 202 response is intentionally noncommittal. Its purpose is to allow a
101
+ * server to accept a request for some other process (perhaps a
102
+ * batch-oriented process that is only run once per day) without requiring
103
+ * that the user agent's connection to the server persist until the process
104
+ * is completed. The representation sent with this response ought to describe
105
+ * the request's current status and point to (or embed) a status monitor that
106
+ * can provide the user with an estimate of when the request will be
107
+ * fulfilled.
108
+ */
109
+ 202: 'Accepted',
110
+ /**
111
+ * The request was successful but the enclosed payload has been modified from
112
+ * that of the origin server's 200 OK response by a transforming proxy.
113
+ *
114
+ * This status code allows the proxy to notify recipients when a
115
+ * transformation has been applied, since that knowledge might impact later
116
+ * decisions regarding the content. For example, future cache validation
117
+ * requests for the content might only be applicable along the same request
118
+ * path (through the same proxies).
119
+ *
120
+ * The 203 response is similar to the Warning code of 214 Transformation
121
+ * Applied, which has the advantage of being applicable to responses with any
122
+ * status code.
123
+ *
124
+ * A 203 response is cacheable by default; i.e., unless otherwise indicated
125
+ * by the method definition or explicit cache controls.
126
+ */
127
+ 203: 'Non-authoritative Information',
128
+ /**
129
+ * The server has successfully fulfilled the request and that there is no
130
+ * additional content to send in the response payload body.
131
+ *
132
+ * Metadata in the response header fields refer to the target resource and
133
+ * its selected representation after the requested action was applied.
134
+ *
135
+ * A 204 response is terminated by the first empty line after the header
136
+ * fields because it cannot contain a message body.
137
+ *
138
+ * A 204 response is cacheable by default; i.e., unless otherwise indicated
139
+ * by the method definition or explicit cache controls.
140
+ */
141
+ 204: 'No Content',
142
+ /**
143
+ * He server has fulfilled the request and desires that the user agent reset
144
+ * the "document view", which caused the request to be sent, to its original
145
+ * state as received from the origin server.
146
+ *
147
+ * This response is intended to support a common data entry use case where
148
+ * the user receives content that supports data entry (a form, notepad,
149
+ * canvas, etc.), enters or manipulates data in that space, causes the
150
+ * entered data to be submitted in a request, and then the data entry
151
+ * mechanism is reset for the next entry so that the user can easily
152
+ * initiate another input action.
153
+ *
154
+ * Since the 205 status code implies that no additional content will be
155
+ * provided, a server MUST NOT generate a payload in a 205 response. In
156
+ * other words, a server MUST do one of the following for a 205 response: a)
157
+ * indicate a zero-length body for the response by including a
158
+ * Content-Length header field with a value of 0; b) indicate a zero-length
159
+ * payload for the response by including a Transfer-Encoding header field
160
+ * with a value of chunked and a message body consisting of a single chunk
161
+ * of zero-length; or, c) close the connection immediately after sending the
162
+ * blank line terminating the header section.
163
+ */
164
+ 205: 'Reset Content',
165
+ /**
166
+ * The server is successfully fulfilling a range request for the target
167
+ * resource by transferring one or more parts of the selected representation
168
+ * that correspond to the satisfiable ranges found in the request's Range
169
+ * header field.
170
+ *
171
+ * If a single part is being transferred, the server generating the 206
172
+ * response MUST generate a Content-Range header field, describing what range
173
+ * of the selected representation is enclosed, and a payload consisting of
174
+ * the range.
175
+ *
176
+ * If multiple parts are being transferred, the server generating the 206
177
+ * response MUST generate a "multipart/byteranges" payload2, and a
178
+ * Content-Type header field containing the multipart/byteranges media type
179
+ * and its required boundary parameter. To avoid confusion with single-part
180
+ * responses, a server MUST NOT generate a Content-Range header field in the
181
+ * HTTP header section of a multiple part response (this field will be sent
182
+ * in each part instead).
183
+ *
184
+ * Within the header area of each body part in the multipart payload, the
185
+ * server MUST generate a Content-Range header field corresponding to the
186
+ * range being enclosed in that body part. If the selected representation
187
+ * would have had a Content-Type header field in a 200 OK response, the
188
+ * server SHOULD generate that same Content-Type field in the header area of
189
+ * each body part.
190
+ *
191
+ * When multiple ranges are requested, a server MAY coalesce any of the
192
+ * ranges that overlap, or that are separated by a gap that is smaller than
193
+ * the overhead of sending multiple parts, regardless of the order in which
194
+ * the corresponding byte-range-spec appeared in the received Range header
195
+ * field. Since the typical overhead between parts of a multipart/byteranges
196
+ * payload is around 80 bytes, depending on the selected representation's
197
+ * media type and the chosen boundary parameter length, it can be less
198
+ * efficient to transfer many small disjoint parts than it is to transfer the
199
+ * entire selected representation.
200
+ *
201
+ * A server MUST NOT generate a multipart response to a request for a single
202
+ * range, since a client that does not request multiple parts might not
203
+ * support multipart responses. However, a server MAY generate a
204
+ * multipart/byteranges payload with only a single body part if multiple
205
+ * ranges were requested and only one range was found to be satisfiable or
206
+ * only one range remained after coalescing. A client that cannot process a
207
+ * multipart/byteranges response MUST NOT generate a request that asks for
208
+ * multiple ranges.
209
+ *
210
+ * When a multipart response payload is generated, the server SHOULD send the
211
+ * parts in the same order that the corresponding byte-range-spec appeared in
212
+ * the received Range header field, excluding those ranges that were deemed
213
+ * unsatisfiable or that were coalesced into other ranges. A client that
214
+ * receives a multipart response MUST inspect the Content-Range header field
215
+ * present in each body part in order to determine which range is contained
216
+ * in that body part; a client cannot rely on receiving the same ranges that
217
+ * it requested, nor the same order that it requested.
218
+ *
219
+ * When a 206 response is generated, the server MUST generate the following
220
+ * header fields, in addition to those required above, if the field would
221
+ * have been sent in a 200 OK response to the same request: Date,
222
+ * Cache-Control, ETag, Expires, Content-Location, and Vary.
223
+ *
224
+ * If a 206 is generated in response to a request with an If-Range header
225
+ * field, the sender SHOULD NOT generate other representation header fields
226
+ * beyond those required above, because the client is understood to already
227
+ * have a prior response containing those header fields. Otherwise, the
228
+ * sender MUST generate all of the representation header fields that would
229
+ * have been sent in a 200 OK response to the same request.
230
+ *
231
+ * A 206 response is cacheable by default; i.e., unless otherwise indicated
232
+ * by explicit cache controls.
233
+ */
234
+ 206: 'Partial Content',
235
+ /**
236
+ * A Multi-Status response conveys information about multiple resources in
237
+ * situations where multiple status codes might be appropriate.
238
+ *
239
+ * The default Multi-Status response body is a text/xml or application/xml
240
+ * HTTP entity with a 'multistatus' root element. Further elements contain
241
+ * 200, 300, 400, and 500 series status codes generated during the method
242
+ * invocation. 100 series status codes SHOULD NOT be recorded in a 'response'
243
+ * XML element.
244
+ *
245
+ * Although '207' is used as the overall response status code, the recipient
246
+ * needs to consult the contents of the multistatus response body for further
247
+ * information about the success or failure of the method execution. The
248
+ * response MAY be used in success, partial success and also in failure
249
+ * situations.
250
+ *
251
+ * The 'multistatus' root element holds zero or more 'response' elements in
252
+ * any order, each with information about an individual resource. Each
253
+ * 'response' element MUST have an 'href' element to identify the resource.
254
+ *
255
+ * A Multi-Status response uses one out of two distinct formats for
256
+ * representing the status:
257
+ *
258
+ * 1. A 'status' element as child of the 'response' element indicates the
259
+ * status of the message execution for the identified resource as a whole.
260
+ * Some method definitions provide information about specific status codes
261
+ * clients should be prepared to see in a response. However, clients MUST be
262
+ * able to handle other status codes, using the generic rules defined in
263
+ * RFC2616 Section 10.
264
+ *
265
+ * 2. For PROPFIND and PROPPATCH, the format has been extended using the
266
+ * 'propstat' element instead of 'status', providing information about
267
+ * individual properties of a resource. This format is specific to PROPFIND
268
+ * and PROPPATCH, and is described in detail in RFC4918 Section 9.1 and
269
+ * RFC4918 Section 9.2.
270
+ */
271
+ 207: 'Multi-Status',
272
+ /**
273
+ * Used inside a DAV: propstat response element to avoid enumerating the
274
+ * internal members of multiple bindings to the same collection repeatedly.
275
+ *
276
+ * For each binding to a collection inside the request's scope, only one will
277
+ * be reported with a 200 status, while subsequent DAV:response elements for
278
+ * all other bindings will use the 208 status, and no DAV:response elements
279
+ * for their descendants are included.
280
+ *
281
+ * Note that the 208 status will only occur for "Depth: infinity" requests,
282
+ * and that it is of particular importance when the multiple collection
283
+ * bindings cause a bind loop.
284
+ *
285
+ * A client can request the DAV:resource-id property in a PROPFIND request to
286
+ * guarantee that they can accurately reconstruct the binding structure of a
287
+ * collection with multiple bindings to a single resource.
288
+ *
289
+ * For backward compatibility with clients not aware of the 208 status code
290
+ * appearing in multistatus response bodies, it SHOULD NOT be used unless the
291
+ * client has signaled support for this specification using the "DAV" request
292
+ * header. Instead, a 508 Loop Detected status should be returned when a
293
+ * binding loop is discovered. This allows the server to return the 508 as
294
+ * the top-level return status, if it discovers it before it started the
295
+ * response, or in the middle of a multistatus, if it discovers it in the
296
+ * middle of streaming out a multistatus response.
297
+ */
298
+ 208: 'Already Reported',
299
+ /**
300
+ * The server has fulfilled a GET request for the resource, and the response
301
+ * is a representation of the result of one or more instance-manipulations
302
+ * applied to the current instance.
303
+ *
304
+ * The actual current instance might not be available except by combining
305
+ * this response with other previous or future responses, as appropriate for
306
+ * the specific instance-manipulation(s). If so, the headers of the resulting
307
+ * instance are the result of combining the headers from the 226 response and
308
+ * the other instances, following the rules in section 13.5.3 of the HTTP/1.1
309
+ * specification.
310
+ *
311
+ * The request MUST have included an A-IM header field listing at least one
312
+ * instance-manipulation. The response MUST include an Etag header field
313
+ * giving the entity tag of the current instance.
314
+ *
315
+ * A response received with a status code of 226 MAY be stored by a cache and
316
+ * used in reply to a subsequent request, subject to the HTTP expiration
317
+ * mechanism and any Cache-Control headers, and to the requirements in
318
+ * section 10.6.
319
+ *
320
+ * A response received with a status code of 226 MAY be used by a cache, in
321
+ * conjunction with a cache entry for the base instance, to create a cache
322
+ * entry for the current instance.
323
+ */
324
+ 226: 'IM Used',
325
+ /**
326
+ * The target resource has more than one representation, each with its own
327
+ * more specific identifier, and information about the alternatives is being
328
+ * provided so that the user (or user agent) can select a preferred
329
+ * representation by redirecting its request to one or more of those
330
+ * identifiers.
331
+ *
332
+ * In other words, the server desires that the user agent engage in reactive
333
+ * negotiation to select the most appropriate representation(s) for its
334
+ * needs.
335
+ *
336
+ * If the server has a preferred choice, the server SHOULD generate a
337
+ * Location header field containing a preferred choice's URI reference. The
338
+ * user agent MAY use the Location field value for automatic redirection.
339
+ *
340
+ * For request methods other than HEAD, the server SHOULD generate a payload
341
+ * in the 300 response containing a list of representation metadata and URI
342
+ * reference(s) from which the user or user agent can choose the one most
343
+ * preferred. The user agent MAY make a selection from that list
344
+ * automatically if it understands the provided media type. A specific format
345
+ * for automatic selection is not defined by this specification because HTTP
346
+ * tries to remain orthogonal to the definition of its payloads. In practice,
347
+ * the representation is provided in some easily parsed format believed to be
348
+ * acceptable to the user agent, as determined by shared design or content
349
+ * negotiation, or in some commonly accepted hypertext format.
350
+ *
351
+ * A 300 response is cacheable by default; i.e., unless otherwise indicated
352
+ * by the method definition or explicit cache controls.
353
+ *
354
+ * Note: The original proposal for the 300 status code defined the URI header
355
+ * field as providing a list of alternative representations, such that it
356
+ * would be usable for 200, 300, and 406 responses and be transferred in
357
+ * responses to the HEAD method. However, lack of deployment and disagreement
358
+ * over syntax led to both URI and Alternates (a subsequent proposal) being
359
+ * dropped from this specification. It is possible to communicate the list
360
+ * using a set of Link header fields3, each with a relationship of
361
+ * "alternate", though deployment is a chicken-and-egg problem.
362
+ */
363
+ 300: 'Multiple Choices',
364
+ /**
365
+ * The target resource has been assigned a new permanent URI and any future
366
+ * references to this resource ought to use one of the enclosed URIs.
367
+ *
368
+ * Clients with link-editing capabilities ought to automatically re-link
369
+ * references to the effective request URI to one or more of the new
370
+ * references sent by the server, where possible.
371
+ *
372
+ * The server SHOULD generate a Location header field in the response
373
+ * containing a preferred URI reference for the new permanent URI. The user
374
+ * agent MAY use the Location field value for automatic redirection. The
375
+ * server's response payload usually contains a short hypertext note with a
376
+ * hyperlink to the new URI(s).
377
+ *
378
+ * Note: For historical reasons, a user agent MAY change the request method
379
+ * from POST to GET for the subsequent request. If this behavior is
380
+ * undesired, the 307 Temporary Redirect status code can be used instead.
381
+ *
382
+ * A 301 response is cacheable by default; i.e., unless otherwise indicated
383
+ * by the method definition or explicit cache controls.
384
+ */
385
+ 301: 'Moved Permanently',
386
+ /**
387
+ * The target resource resides temporarily under a different URI. Since the
388
+ * redirection might be altered on occasion, the client ought to continue to
389
+ * use the effective request URI for future requests.
390
+ *
391
+ * The server SHOULD generate a Location header field in the response
392
+ * containing a URI reference for the different URI. The user agent MAY use
393
+ * the Location field value for automatic redirection. The server's response
394
+ * payload usually contains a short hypertext note with a hyperlink to the
395
+ * different URI(s).
396
+ *
397
+ * Note: For historical reasons, a user agent MAY change the request method
398
+ * from POST to GET for the subsequent request. If this behavior is
399
+ * undesired, the 307 Temporary Redirect status code can be used instead.
400
+ */
401
+ 302: 'Found',
402
+ /**
403
+ * The server is redirecting the user agent to a different resource, as
404
+ * indicated by a URI in the Location header field, which is intended to
405
+ * provide an indirect response to the original request.
406
+ *
407
+ * A user agent can perform a retrieval request targeting that URI (a GET or
408
+ * HEAD request if using HTTP), which might also be redirected, and present
409
+ * the eventual result as an answer to the original request. Note that the
410
+ * new URI in the Location header field is not considered equivalent to the
411
+ * effective request URI.
412
+ *
413
+ * This status code is applicable to any HTTP method. It is primarily used
414
+ * to allow the output of a POST action to redirect the user agent to a
415
+ * selected resource, since doing so provides the information corresponding
416
+ * to the POST response in a form that can be separately identified,
417
+ * bookmarked, and cached, independent of the original request.
418
+ *
419
+ * A 303 response to a GET request indicates that the origin server does not
420
+ * have a representation of the target resource that can be transferred by
421
+ * the server over HTTP. However, the Location field value refers to a
422
+ * resource that is descriptive of the target resource, such that making a
423
+ * retrieval request on that other resource might result in a representation
424
+ * that is useful to recipients without implying that it represents the
425
+ * original target resource. Note that answers to the questions of what can
426
+ * be represented, what representations are adequate, and what might be a
427
+ * useful description are outside the scope of HTTP.
428
+ *
429
+ * Except for responses to a HEAD request, the representation of a 303
430
+ * response ought to contain a short hypertext note with a hyperlink to the
431
+ * same URI reference provided in the Location header field.
432
+ */
433
+ 303: 'See Other',
434
+ /**
435
+ * A conditional GET or HEAD request has been received and would have
436
+ * resulted in a 200 OK response if it were not for the fact that the
437
+ * condition evaluated to false.
438
+ *
439
+ * In other words, there is no need for the server to transfer a
440
+ * representation of the target resource because the request indicates that
441
+ * the client, which made the request conditional, already has a valid
442
+ * representation; the server is therefore redirecting the client to make
443
+ * use of that stored representation as if it were the payload of a 200 OK
444
+ * response.
445
+ *
446
+ * The server generating a 304 response MUST generate any of the following
447
+ * header fields that would have been sent in a 200 OK response to the same
448
+ * request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.
449
+ *
450
+ * Since the goal of a 304 response is to minimize information transfer when
451
+ * the recipient already has one or more cached representations, a sender
452
+ * SHOULD NOT generate representation metadata other than the above listed
453
+ * fields unless said metadata exists for the purpose of guiding cache
454
+ * updates (e.g., Last-Modified might be useful if the response does not have
455
+ * an ETag field).
456
+ *
457
+ * Requirements on a cache that receives a 304 response are defined in
458
+ * Section 4.3.4 of RFC7234. If the conditional request originated with an
459
+ * outbound client, such as a user agent with its own cache sending a
460
+ * conditional GET to a shared proxy, then the proxy SHOULD forward the
461
+ * 304 response to that client.
462
+ *
463
+ * A 304 response cannot contain a message-body; it is always terminated by
464
+ * the first empty line after the header fields.
465
+ */
466
+ 304: 'Not Modified',
467
+ /**
468
+ * Defined in a previous version of this specification and is now deprecated,
469
+ * due to security concerns regarding in-band configuration of a proxy.
470
+ */
471
+ 305: 'Use Proxy',
472
+ /**
473
+ * The target resource resides temporarily under a different URI and the user
474
+ * agent MUST NOT change the request method if it performs an automatic
475
+ * redirection to that URI.
476
+ *
477
+ * Since the redirection can change over time, the client ought to continue
478
+ * using the original effective request URI for future requests.
479
+ *
480
+ * The server SHOULD generate a Location header field in the response
481
+ * containing a URI reference for the different URI. The user agent MAY use
482
+ * the Location field value for automatic redirection. The server's response
483
+ * payload usually contains a short hypertext note with a hyperlink to the
484
+ * different URI(s).
485
+ *
486
+ * Note: This status code is similar to 302 Found, except that it does not
487
+ * allow changing the request method from POST to GET. This specification
488
+ * defines no equivalent counterpart for 301 Moved Permanently (RFC7238,
489
+ * however, proposes defining the status code 308 Permanent Redirect for
490
+ * this purpose).
491
+ */
492
+ 307: 'Temporary Redirect',
493
+ /**
494
+ * The target resource has been assigned a new permanent URI and any future
495
+ * references to this resource ought to use one of the enclosed URIs.
496
+ *
497
+ * Clients with link editing capabilities ought to automatically re-link
498
+ * references to the effective request URI to one or more of the new
499
+ * references sent by the server, where possible.
500
+ *
501
+ * The server SHOULD generate a Location header field in the response
502
+ * containing a preferred URI reference for the new permanent URI. The user
503
+ * agent MAY use the Location field value for automatic redirection. The
504
+ * server's response payload usually contains a short hypertext note with a
505
+ * hyperlink to the new URI(s).
506
+ *
507
+ * A 308 response is cacheable by default; i.e., unless otherwise indicated
508
+ * by the method definition or explicit cache controls.
509
+ *
510
+ * Note: This status code is similar to 301 Moved Permanently, except that it
511
+ * does not allow changing the request method from POST to GET.
512
+ */
513
+ 308: 'Permanent Redirect',
514
+ /**
515
+ * The 400 (Bad Request) status code indicates that the server cannot or
516
+ * will not process the request due to something that is perceived to be
517
+ * a client error (e.g., malformed request syntax, invalid request
518
+ * message framing, or deceptive request routing).
519
+ */
520
+ 400: 'Bad Request',
521
+ /**
522
+ * The request has not been applied because it lacks valid authentication
523
+ * credentials for the target resource.
524
+ *
525
+ * The server generating a 401 response MUST send a WWW-Authenticate header
526
+ * field containing at least one challenge applicable to the target resource.
527
+ *
528
+ * If the request included authentication credentials, then the 401 response
529
+ * indicates that authorization has been refused for those credentials. The
530
+ * user agent MAY repeat the request with a new or replaced Authorization
531
+ * header field. If the 401 response contains the same challenge as the
532
+ * prior response, and the user agent has already attempted authentication at
533
+ * least once, then the user agent SHOULD present the enclosed representation
534
+ * to the user, since it usually contains relevant diagnostic information.
535
+ */
536
+ 401: 'Unauthorized',
537
+ /**
538
+ * The 402 (Payment Required) status code is reserved for future use.
539
+ */
540
+ 402: 'Payment Required',
541
+ /**
542
+ * The 403 (Forbidden) status code indicates that the server understood
543
+ * the request but refuses to authorize it. A server that wishes to
544
+ * make public why the request has been forbidden can describe that
545
+ * reason in the response payload (if any).
546
+ *
547
+ * If authentication credentials were provided in the request, the
548
+ * server considers them insufficient to grant access. The client
549
+ * SHOULD NOT automatically repeat the request with the same
550
+ * credentials. The client MAY repeat the request with new or different
551
+ * credentials. However, a request might be forbidden for reasons
552
+ * unrelated to the credentials.
553
+ *
554
+ * An origin server that wishes to "hide" the current existence of a
555
+ * forbidden target resource MAY instead respond with a status code of
556
+ * 404 (Not Found).
557
+ */
558
+ 403: 'Forbidden',
559
+ /**
560
+ * The 404 (Not Found) status code indicates that the origin server did
561
+ * not find a current representation for the target resource or is not
562
+ * willing to disclose that one exists. A 404 status code does not
563
+ * indicate whether this lack of representation is temporary or
564
+ * permanent; the 410 (Gone) status code is preferred over 404 if the
565
+ * origin server knows, presumably through some configurable means, that
566
+ * the condition is likely to be permanent.
567
+ *
568
+ * A 404 response is cacheable by default; i.e., unless otherwise
569
+ * indicated by the method definition or explicit cache controls (see
570
+ * Section 4.2.2 of [RFC7234]).
571
+ */
572
+ 404: 'Not Found',
573
+ /**
574
+ * The 405 (Method Not Allowed) status code indicates that the method
575
+ * received in the request-line is known by the origin server but not
576
+ * supported by the target resource. The origin server MUST generate an
577
+ * Allow header field in a 405 response containing a list of the target
578
+ * resource's currently supported methods.
579
+ *
580
+ * A 405 response is cacheable by default; i.e., unless otherwise
581
+ * indicated by the method definition or explicit cache controls (see
582
+ * Section 4.2.2 of [RFC7234]).
583
+ */
584
+ 405: 'Method Not Allowed',
585
+ /**
586
+ * The 406 (Not Acceptable) status code indicates that the target
587
+ * resource does not have a current representation that would be
588
+ * acceptable to the user agent, according to the proactive negotiation
589
+ * header fields received in the request (Section 5.3), and the server
590
+ * is unwilling to supply a default representation.
591
+ *
592
+ * The server SHOULD generate a payload containing a list of available
593
+ * representation characteristics and corresponding resource identifiers
594
+ * from which the user or user agent can choose the one most
595
+ * appropriate. A user agent MAY automatically select the most
596
+ * appropriate choice from that list. However, this specification does
597
+ * not define any standard for such automatic selection, as described in
598
+ * Section 6.4.1 of [RFC7231]
599
+ */
600
+ 406: 'Not Acceptable',
601
+ /**
602
+ * Similar to 401 Unauthorized, but it indicates that the client needs to
603
+ * authenticate itself in order to use a proxy.
604
+ *
605
+ * The proxy MUST send a Proxy-Authenticate header field containing a
606
+ * challenge applicable to that proxy for the target resource. The client MAY
607
+ * repeat the request with a new or replaced Proxy-Authorization header field.
608
+ */
609
+ 407: 'Proxy Authentication Required',
610
+ /**
611
+ * The 408 (Request Timeout) status code indicates that the server did
612
+ * not receive a complete request message within the time that it was
613
+ * prepared to wait. A server SHOULD send the "close" connection option
614
+ * (Section 6.1 of [RFC7230]) in the response, since 408 implies that
615
+ * the server has decided to close the connection rather than continue
616
+ * waiting. If the client has an outstanding request in transit, the
617
+ * client MAY repeat that request on a new connection.
618
+ */
619
+ 408: 'Request Timeout',
620
+ /**
621
+ * The 409 (Conflict) status code indicates that the request could not
622
+ * be completed due to a conflict with the current state of the target
623
+ * resource. This code is used in situations where the user might be
624
+ * able to resolve the conflict and resubmit the request. The server
625
+ * SHOULD generate a payload that includes enough information for a user
626
+ * to recognize the source of the conflict.
627
+ *
628
+ * Conflicts are most likely to occur in response to a PUT request. For
629
+ * example, if versioning were being used and the representation being
630
+ * PUT included changes to a resource that conflict with those made by
631
+ * an earlier (third-party) request, the origin server might use a 409
632
+ * response to indicate that it can't complete the request. In this
633
+ * case, the response representation would likely contain information
634
+ * useful for merging the differences based on the revision history.
635
+ */
636
+ 409: 'Conflict',
637
+ /**
638
+ * The 410 (Gone) status code indicates that access to the target
639
+ * resource is no longer available at the origin server and that this
640
+ * condition is likely to be permanent. If the origin server does not
641
+ * know, or has no facility to determine, whether or not the condition
642
+ * is permanent, the status code 404 (Not Found) ought to be used
643
+ * instead.
644
+ *
645
+ * The 410 response is primarily intended to assist the task of web
646
+ * maintenance by notifying the recipient that the resource is
647
+ * intentionally unavailable and that the server owners desire that
648
+ * remote links to that resource be removed. Such an event is common
649
+ * for limited-time, promotional services and for resources belonging to
650
+ * individuals no longer associated with the origin server's site. It
651
+ * is not necessary to mark all permanently unavailable resources as
652
+ * "gone" or to keep the mark for any length of time -- that is left to
653
+ * the discretion of the server owner.
654
+ *
655
+ * A 410 response is cacheable by default; i.e., unless otherwise
656
+ * indicated by the method definition or explicit cache controls (see
657
+ * Section 4.2.2 of [RFC7234]).
658
+ */
659
+ 410: 'Gone',
660
+ /**
661
+ * The 411 (Length Required) status code indicates that the server
662
+ * refuses to accept the request without a defined Content-Length
663
+ * (Section 3.3.2 of [RFC7230]). The client MAY repeat the request if
664
+ * it adds a valid Content-Length header field containing the length of
665
+ * the message body in the request message.
666
+ */
667
+ 411: 'Length Required',
668
+ /**
669
+ * One or more conditions given in the request header fields evaluated to
670
+ * false when tested on the server.
671
+ *
672
+ * This response code allows the client to place preconditions on the current
673
+ * resource state (its current representations and metadata) and, thus,
674
+ * prevent the request method from being applied if the target resource is in
675
+ * an unexpected state.
676
+ */
677
+ 412: 'Precondition Failed',
678
+ /**
679
+ * The 413 (Payload Too Large) status code indicates that the server is
680
+ * refusing to process a request because the request payload is larger
681
+ * than the server is willing or able to process. The server MAY close
682
+ * the connection to prevent the client from continuing the request.
683
+ *
684
+ * If the condition is temporary, the server SHOULD generate a
685
+ * Retry-After header field to indicate that it is temporary and after
686
+ * what time the client MAY try again.
687
+ */
688
+ 413: 'Payload Too Large',
689
+ /**
690
+ * The 414 (URI Too Long) status code indicates that the server is
691
+ * refusing to service the request because the request-target (Section
692
+ * 5.3 of [RFC7230]) is longer than the server is willing to interpret.
693
+ * This rare condition is only likely to occur when a client has
694
+ * improperly converted a POST request to a GET request with long query
695
+ * information, when the client has descended into a "black hole" of
696
+ * redirection (e.g., a redirected URI prefix that points to a suffix of
697
+ * itself) or when the server is under attack by a client attempting to
698
+ * exploit potential security holes.
699
+ *
700
+ * A 414 response is cacheable by default; i.e., unless otherwise
701
+ * indicated by the method definition or explicit cache controls (see
702
+ * Section 4.2.2 of [RFC7234]).
703
+ */
704
+ 414: 'Request-URI Too Long',
705
+ /**
706
+ * The 415 (Unsupported Media Type) status code indicates that the
707
+ * origin server is refusing to service the request because the payload
708
+ * is in a format not supported by this method on the target resource.
709
+ * The format problem might be due to the request's indicated
710
+ * Content-Type or Content-Encoding, or as a result of inspecting the
711
+ * data directly.
712
+ */
713
+ 415: 'Unsupported Media Type',
714
+ /**
715
+ * None of the ranges in the request's Range header field overlap the
716
+ * current extent of the selected resource or that the set of ranges
717
+ * requested has been rejected due to invalid ranges or an excessive request
718
+ * of small or overlapping ranges.
719
+ *
720
+ * For byte ranges, failing to overlap the current extent means that the
721
+ * first-byte-pos of all of the byte-range-spec values were greater than the
722
+ * current length of the selected representation. When this status code is
723
+ * generated in response to a byte-range request, the sender SHOULD generate
724
+ * a Content-Range header field specifying the current length of the selected
725
+ * representation
726
+ */
727
+ 416: 'Requested Range Not Satisfiable',
728
+ /**
729
+ * The 417 (Expectation Failed) status code indicates that the
730
+ * expectation given in the request's Expect header field
731
+ * (Section 5.1.1 of [RFC7231]) could not be met by at least one of the
732
+ * inbound servers.
733
+ */
734
+ 417: 'Expectation Failed',
735
+ /**
736
+ * Any attempt to brew coffee with a teapot should result in the error code
737
+ * "418 I'm a teapot". The resulting entity body MAY be short and stout.
738
+ */
739
+ 418: "I'm a Teapot",
740
+ /**
741
+ * The request was directed at a server that is not able to produce a
742
+ * response. This can be sent by a server that is not configured to produce
743
+ * responses for the combination of scheme and authority that are included
744
+ * in the request URI.
745
+ *
746
+ * Clients receiving a 421 Misdirected Request response from a server MAY
747
+ * retry the request -- whether the request method is idempotent or
748
+ * not -- over a different connection. This is possible if a connection is
749
+ * reused or if an alternative service is selected ALT-SVC.
750
+ *
751
+ * This status code MUST NOT be generated by proxies.
752
+ *
753
+ * A 421 response is cacheable by default, i.e., unless otherwise indicated by
754
+ * the method definition or explicit cache controls
755
+ */
756
+ 421: 'Misdirected Request',
757
+ /**
758
+ * The server understands the content type of the request entity (hence a
759
+ * 415 Unsupported Media Type status code is inappropriate), and the syntax
760
+ * of the request entity is correct (thus a 400 Bad Request status code is
761
+ * inappropriate) but was unable to process the contained instructions.
762
+ *
763
+ * For example, this error condition may occur if an XML request body contains
764
+ * well-formed (i.e., syntactically correct), but semantically erroneous, XML
765
+ * instructions.
766
+ */
767
+ 422: 'Unprocessable Entity',
768
+ /**
769
+ * The source or destination resource of a method is locked.
770
+ *
771
+ * This response SHOULD contain an appropriate precondition or postcondition
772
+ * code, such as 'lock-token-submitted' or 'no-conflicting-lock'.
773
+ */
774
+ 423: 'Locked',
775
+ /**
776
+ * The method could not be performed on the resource because the requested
777
+ * action depended on another action and that action failed.
778
+ *
779
+ * For example, if a command in a PROPPATCH method fails, then, at minimum,
780
+ * the rest of the commands will also fail with 424 Failed Dependency.
781
+ */
782
+ 424: 'Failed Dependency',
783
+ /**
784
+ * The 426 (Upgrade Required) status code indicates that the server
785
+ * refuses to perform the request using the current protocol but might
786
+ * be willing to do so after the client upgrades to a different
787
+ * protocol. The server MUST send an Upgrade header field in a 426
788
+ * response to indicate the required protocol(s) (Section 6.7 of
789
+ * [RFC7230]).
790
+ */
791
+ 426: 'Upgrade Required',
792
+ /**
793
+ * The origin server requires the request to be conditional.
794
+ *
795
+ * Its typical use is to avoid the "lost update" problem, where a client GETs
796
+ * a resource's state, modifies it, and PUTs it back to the server, when
797
+ * meanwhile a third party has modified the state on the server, leading
798
+ * to a conflict. By requiring requests to be conditional, the server can
799
+ * assure that clients are working with the correct copies.
800
+ *
801
+ * Responses using this status code SHOULD explain how to resubmit the request
802
+ * successfully.
803
+ *
804
+ * Responses with the 428 status code MUST NOT be stored by a cache.
805
+ */
806
+ 428: 'Precondition Required',
807
+ /**
808
+ * The user has sent too many requests in a given amount of time
809
+ * ("rate limiting").
810
+ *
811
+ * The response representations SHOULD include details explaining the
812
+ * condition, and MAY include a Retry-After header indicating how long to
813
+ * wait before making a new request.
814
+ *
815
+ * Responses with the 429 status code MUST NOT be stored by a cache.
816
+ */
817
+ 429: 'Too Many Requests',
818
+ /**
819
+ * The server is unwilling to process the request because its header fields
820
+ * are too large. The request MAY be resubmitted after reducing the size of
821
+ * the request header fields.
822
+ *
823
+ * It can be used both when the set of request header fields in total is too
824
+ * large, and when a single header field is at fault. In the latter case, the
825
+ * response representation SHOULD specify which header field was too large.
826
+ */
827
+ 431: 'Request Header Fields Too Large',
828
+ /**
829
+ * A non-standard status code used to instruct nginx to close the connection
830
+ * without sending a response to the client, most commonly used to deny
831
+ * malicious or malformed requests.
832
+ *
833
+ * This status code is not seen by the client, it only appears in nginx log
834
+ * files.
835
+ */
836
+ 444: 'Connection Closed Without Response',
837
+ /**
838
+ * The server is denying access to the resource as a consequence of a legal
839
+ * demand.
840
+ *
841
+ * The server in question might not be an origin server. This type of legal
842
+ * demand typically most directly affects the operations of ISPs and search
843
+ * engines.
844
+ *
845
+ * Responses using this status code SHOULD include an explanation, in the
846
+ * response body, of the details of the legal demand: the party making it,
847
+ * the applicable legislation or regulation, and what classes of person and
848
+ * resource it applies to.
849
+ *
850
+ * The use of the 451 status code implies neither the existence nor
851
+ * non-existence of the resource named in the request. That is to say, it is
852
+ * possible that if the legal demands were removed, a request for the
853
+ * resource still might not succeed.
854
+ *
855
+ * Note that in many cases clients can still access the denied resource by
856
+ * using technical countermeasures such as a VPN or the Tor network.
857
+ *
858
+ * A 451 response is cacheable by default; i.e., unless otherwise indicated
859
+ * by the method definition or explicit cache controls; see RFC7234.
860
+ */
861
+ 451: 'Unavailable For Legal Reasons',
862
+ /**
863
+ * A non-standard status code introduced by nginx for the case when a client
864
+ * closes the connection while nginx is processing the request.
865
+ */
866
+ 499: 'Client Closed Request',
867
+ /**
868
+ * The 500 (Internal Server Error) status code indicates that the server
869
+ * encountered an unexpected condition that prevented it from fulfilling
870
+ * the request.
871
+ */
872
+ 500: 'Internal Server Error',
873
+ /**
874
+ * The 501 (Not Implemented) status code indicates that the server does
875
+ * not support the functionality required to fulfill the request. This
876
+ * is the appropriate response when the server does not recognize the
877
+ * request method and is not capable of supporting it for any resource.
878
+ *
879
+ * A 501 response is cacheable by default; i.e., unless otherwise
880
+ * indicated by the method definition or explicit cache controls (see
881
+ * Section 4.2.2 of [RFC7234]).
882
+ */
883
+ 501: 'Not Implemented',
884
+ /**
885
+ * The 502 (Bad Gateway) status code indicates that the server, while
886
+ * acting as a gateway or proxy, received an invalid response from an
887
+ * inbound server it accessed while attempting to fulfill the request.
888
+ */
889
+ 502: 'Bad Gateway',
890
+ /**
891
+ * The 503 (Service Unavailable) status code indicates that the server
892
+ * is currently unable to handle the request due to a temporary overload
893
+ * or scheduled maintenance, which will likely be alleviated after some
894
+ * delay. The server MAY send a Retry-After header field
895
+ * (Section 7.1.3 of [RFC7231]) to suggest an appropriate amount of time for
896
+ * the client to wait before retrying the request.
897
+ */
898
+ 503: 'Service Unavailable',
899
+ /**
900
+ * The 504 (Gateway Timeout) status code indicates that the server,
901
+ *while acting as a gateway or proxy, did not receive a timely response
902
+ *from an upstream server it needed to access in order to complete the
903
+ *request.
904
+ */
905
+ 504: 'Gateway Timeout',
906
+ /**
907
+ * The 505 (HTTP Version Not Supported) status code indicates that the
908
+ *server does not support, or refuses to support, the major version of
909
+ *HTTP that was used in the request message. The server is indicating
910
+ *that it is unable or unwilling to complete the request using the same
911
+ *major version as the client, as described in Section 2.6 of
912
+ *[RFC7230], other than with this error message. The server SHOULD
913
+ *generate a representation for the 505 response that describes why
914
+ *that version is not supported and what other protocols are supported
915
+ *by that server.
916
+ */
917
+ 505: 'HTTP Version Not Supported',
918
+ /**
919
+ * The server has an internal configuration error: the chosen variant
920
+ * resource is configured to engage in transparent content negotiation
921
+ * itself, and is therefore not a proper end point in the negotiation
922
+ * process.
923
+ */
924
+ 506: 'Variant Also Negotiates',
925
+ /**
926
+ * The method could not be performed on the resource because the server is
927
+ * unable to store the representation needed to successfully complete the
928
+ * request.
929
+ *
930
+ * This condition is considered to be temporary. If the request that received
931
+ * this status code was the result of a user action, the request MUST NOT be
932
+ * repeated until it is requested by a separate user action.
933
+ */
934
+ 507: 'Insufficient Storage',
935
+ /**
936
+ * The server terminated an operation because it encountered an infinite loop
937
+ * while processing a request with "Depth: infinity". This status indicates
938
+ * that the entire operation failed.
939
+ */
940
+ 508: 'Loop Detected',
941
+ /**
942
+ * The policy for accessing the resource has not been met in the request. The
943
+ * server should send back all the information necessary for the client to
944
+ * issue an extended request.
945
+ *
946
+ * It is outside the scope of this specification to specify how the
947
+ * extensions inform the client.
948
+ *
949
+ * If the 510 response contains information about extensions that were not
950
+ * present in the initial request then the client MAY repeat the request if
951
+ * it has reason to believe it can fulfill the extension policy by modifying
952
+ * the request according to the information provided in the 510 response.
953
+ * Otherwise the client MAY present any entity included in the 510 response
954
+ * to the user, since that entity may include relevant diagnostic information.
955
+ */
956
+ 510: 'Not Extended',
957
+ /**
958
+ * The client needs to authenticate to gain network access.
959
+ *
960
+ * The response representation SHOULD contain a link to a resource that
961
+ * allows the user to submit credentials (e.g., with an HTML form).
962
+ *
963
+ * Note that the 511 response SHOULD NOT contain a challenge or the login
964
+ * interface itself, because browsers would show the login interface as being
965
+ * associated with the originally requested URL, which may cause confusion.
966
+ *
967
+ * The 511 status SHOULD NOT be generated by origin servers; it is intended
968
+ * for use by intercepting proxies that are interposed as a means of
969
+ * controlling access to the network.
970
+ *
971
+ * Responses with the 511 status code MUST NOT be stored by a cache.
972
+ */
973
+ 511: 'Network Authentication Required',
974
+ /**
975
+ * This status code is not specified in any RFCs, but is used by some HTTP
976
+ * proxies to signal a network connect timeout behind the proxy to a client
977
+ * in front of the proxy.
978
+ */
979
+ 599: 'Network Connect Timeout Error'
980
+ };
981
+ /**
982
+ * Checks if the given numerical status code is in the known HTTP status codes
983
+ * list.
984
+ *
985
+ * @param code HTTP Status code
986
+ * @returns True if the code is a valid HTTP status code
987
+ */
988
+ const isValidStatusCode = (code) => !!exports.HTTPStatuses[code];
989
+ exports.isValidStatusCode = isValidStatusCode;
990
+ /**
991
+ * Checks if the given status code is in the informational range (1XX).
992
+ *
993
+ * @param code HTTP Status code
994
+ * @returns True if the code is in the "informational" range.
995
+ */
996
+ const isInformational = (code) => code >= 100 && code < 200;
997
+ exports.isInformational = isInformational;
998
+ /**
999
+ * Checks if the given status code is in the successful range (2XX).
1000
+ *
1001
+ * @param code HTTP Status code
1002
+ * @returns True if the code is in the "success" range.
1003
+ */
1004
+ const isSuccessful = (code) => code >= 200 && code < 300;
1005
+ exports.isSuccessful = isSuccessful;
1006
+ /**
1007
+ * Checks if the given status code is in the redirection range (3XX).
1008
+ *
1009
+ * @param code HTTP Status code
1010
+ * @returns True if the code is in the "redirection" range.
1011
+ */
1012
+ const isRedirection = (code) => code >= 300 && code < 400;
1013
+ exports.isRedirection = isRedirection;
1014
+ /**
1015
+ * Checks if the given status code is in the client error range (4XX).
1016
+ *
1017
+ * @param code HTTP Status code
1018
+ * @returns True if the code is in the "client error" range.
1019
+ */
1020
+ const isClientError = (code) => code >= 400 && code < 500;
1021
+ exports.isClientError = isClientError;
1022
+ /**
1023
+ * Checks if the given status code is in the server error range (5XX).
1024
+ *
1025
+ * @param code HTTP Status code
1026
+ * @returns True if the code is in the "server error" range.
1027
+ */
1028
+ const isServerError = (code) => code >= 500;
1029
+ exports.isServerError = isServerError;
1030
+ /**
1031
+ * Searches the list of HTTP statuses for a matching textual name to the one
1032
+ * provided. If a match is found, then the numerical status code is returned,
1033
+ * otherwise `null`.
1034
+ *
1035
+ * Internally, the parameter and the status names are normalized by lower-casing
1036
+ * the strings and trimming space.
1037
+ *
1038
+ * @param status HTTP Status textual name
1039
+ * @returns The numerical status code, or null if not found
1040
+ */
1041
+ const getCodeForStatus = (status) => {
1042
+ const clnStr = status.toLocaleLowerCase().trim();
1043
+ const entry = Object.entries(exports.HTTPStatuses).find((ent) => ent[1].toLowerCase() === clnStr);
1044
+ if (entry)
1045
+ return parseInt(entry[0]);
1046
+ return null;
1047
+ };
1048
+ exports.getCodeForStatus = getCodeForStatus;
1049
+ exports.default = exports.HTTPStatuses;
1050
+ //# sourceMappingURL=httpStatusCodes.js.map