@d1g1tal/transportr 2.0.0 → 2.1.1

package/dist/methods.d.ts

@@ -0,0 +1,274 @@
+/**
+ * Defining a constant object with the name HttpRequestMethod.
+ */
+declare const HttpRequestMethod: {
+    /**
+     * The OPTIONS method represents a request for information about the communication options available on the
+     * request/response chain identified by the Request-URI. This method allows the client to determine the options and/or
+     * requirements associated with a resource, or the capabilities of a server, without implying a resource action or
+     * initiating a resource retrieval.
+     *
+     * Responses to this method are not cacheable.
+     *
+     * If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or
+     * Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does
+     * not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed
+     * queries on the server. A server that does not support such an extension MAY discard the request body.
+     *
+     * If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather
+     * than to a specific resource. Since a server's communication options typically depend on the resource, the "*"
+     * request is only useful as a "ping" or "no-op" type of method, it does nothing beyond allowing the client to test the
+     * capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).
+     *
+     * If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when
+     * communicating with that resource.
+     *
+     * A 200 response SHOULD include any header fields that indicate optional features implemented by the server and
+     * applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The
+     * response body, if any, SHOULD also include information about the communication options. The format for such a body
+     * is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be
+     * used to select the appropriate response format. If no response body is included, the response MUST include a
+     * Content-Length field with a field-value of "0".
+     *
+     * The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy
+     * receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a
+     * Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward the message, instead,
+     * the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater
+     * than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is
+     * present in the request, then the forwarded request MUST NOT include a Max-Forwards field.
+     */
+    readonly OPTIONS: "OPTIONS";
+    /**
+     * The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If
+     * the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in
+     * the response and not the source text of the process, unless that text happens to be the output of the process.
+     *
+     * The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since;
+     * If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the
+     * entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET
+     * method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring
+     * multiple requests or transferring data already held by the client.
+     *
+     * The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A
+     * partial GET requests that only part of the entity be transferred, as described in section 14.35. The partial GET
+     * method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed
+     * without transferring data already held by the client.
+     *
+     * The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in
+     * section 13.
+     *
+     * See section 15.1.3 for security considerations when used for forms.
+     */
+    readonly GET: "GET";
+    /**
+     * The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The
+     * meta information contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information
+     * sent in response to a GET request. This method can be used for obtaining meta information about the entity implied by
+     * the request without transferring the entity-body itself. This method is often used for testing hypertext links for
+     * validity, accessibility, and recent modification.
+     *
+     * The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be
+     * used to update a previously cached entity from that resource. If the new field values indicate that the cached
+     * entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or
+     * Last-Modified), then the cache MUST treat the cache entry as stale.
+     */
+    readonly HEAD: "HEAD";
+    /**
+     * The POST method is used to request that the origin server accept the entity enclosed in the request as a new
+     * subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform
+     * method to cover the following functions:
+     * <ul>
+     *     <li>Annotation of existing resources,</li>
+     *     <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles,</li>
+     *     <li>Providing a block of data, such as the result of submitting a form, to a data-handling process,</li>
+     *     <li>Extending a database through an append operation.</li>
+     * </ul>
+     *
+     * The actual function performed by the POST method is determined by the server and is usually dependent on the
+     * Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory
+     * containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a
+     * database.
+     *
+     * The action performed by the POST method might not result in a resource that can be identified by a URI. In this
+     * case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the
+     * response includes an entity that describes the result.
+     *
+     * If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity
+     * which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).
+     *
+     * Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header
+     * fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.
+     *
+     * POST requests MUST obey the message transmission requirements set out in section 8.2.
+     *
+     * See section 15.1.3 for security considerations.
+     */
+    readonly POST: "POST";
+    /**
+     * The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers
+     * to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing
+     * on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being
+     * defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If
+     * a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an
+     * existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate
+     * successful completion of the request. If the resource could not be created or modified with the Request-URI, an
+     * appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST
+     * \NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a
+     * 501 (Not Implemented) response in such cases.
+     *
+     * If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those
+     * entries SHOULD be treated as stale. Responses to this method are not cacheable.
+     *
+     * The fundamental difference between the POST and PUT requests is reflected in the different meaning of the
+     * Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource
+     * might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations.
+     * In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what
+     * URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires
+     * that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response, the user agent MAY
+     * then make its own decision regarding whether or not to redirect the request.
+     *
+     * A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying
+     * "the current version" which is separate from the URI identifying each particular version. In this case, a PUT
+     * request on a general URI might result in several other URIs being defined by the origin server.
+     *
+     * HTTP/1.1 does not define how a PUT method affects the state of an origin server.
+     *
+     * PUT requests MUST obey the message transmission requirements set out in section 8.2.
+     *
+     * Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied
+     * to the resource created or modified by the PUT.
+     */
+    readonly PUT: "PUT";
+    /**
+     * The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY
+     * be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the
+     * operation has been carried out, even if the status code returned from the origin server indicates that the action
+     * has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response
+     * is given, it intends to delete the resource or move it to an inaccessible location.
+     *
+     * A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if
+     * the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not
+     * include an entity.
+     *
+     * If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those
+     * entries SHOULD be treated as stale. Responses to this method are not cacheable.
+     */
+    readonly DELETE: "DELETE";
+    /**
+     * The TRACE method is used to invoke a remote, application-layer loop- back of the request message. The final
+     * recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK)
+     * response. The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards
+     * value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity.
+     *
+     * TRACE allows the client to see what is being received at the other end of the request chain and use that data for
+     * testing or diagnostic information. The value of the Via header field (section 14.45) is of particular interest,
+     * since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the
+     * length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.
+     *
+     * If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a
+     * Content-Type of "message/http". Responses to this method MUST NOT be cached.
+     */
+    readonly TRACE: "TRACE";
+    /**
+     * This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a
+     * tunnel (e.g. SSL tunneling [44]).
+     */
+    readonly CONNECT: "CONNECT";
+    /**
+     * The PATCH method requests that a set of changes described in the
+     * request entity be applied to the resource identified by the Request-
+     * URI.  The set of changes is represented in a format called a "patch
+     * document" identified by a media type.  If the Request-URI does not
+     * point to an existing resource, the server MAY create a new resource,
+     * depending on the patch document type (whether it can logically modify
+     * a null resource) and permissions, etc.
+     *
+     * The difference between the PUT and PATCH requests is reflected in the
+     * way the server processes the enclosed entity to modify the resource
+     * identified by the Request-URI.  In a PUT request, the enclosed entity
+     * is considered to be a modified version of the resource stored on the
+     * origin server, and the client is requesting that the stored version
+     * be replaced.  With PATCH, however, the enclosed entity contains a set
+     * of instructions describing how a resource currently residing on the
+     * origin server should be modified to produce a new version.  The PATCH
+     * method affects the resource identified by the Request-URI, and it
+     * also MAY have side effects on other resources; i.e., new resources
+     * may be created, or existing ones modified, by the application of a
+     * PATCH.
+     *
+     * PATCH is neither safe nor idempotent as defined by [RFC2616], Section
+     * 9.1.
+     *
+     * A PATCH request can be issued in such a way as to be idempotent,
+     * which also helps prevent bad outcomes from collisions between two
+     * PATCH requests on the same resource in a similar time frame.
+     * Collisions from multiple PATCH requests may be more dangerous than
+     * PUT collisions because some patch formats need to operate from a
+     * known base-point or else they will corrupt the resource.  Clients
+     * using this kind of patch application SHOULD use a conditional request
+     * such that the request will fail if the resource has been updated
+     * since the client last accessed the resource.  For example, the client
+     * can use a strong ETag [RFC2616] in an If-Match header on the PATCH
+     * request.
+     *
+     * There are also cases where patch formats do not need to operate from
+     * a known base-point (e.g., appending text lines to log files, or non-
+     * colliding rows to database tables), in which case the same care in
+     * client requests is not needed.
+     *
+     * The server MUST apply the entire set of changes atomically and never
+     * provide (e.g., in response to a GET during this operation) a
+     * partially modified representation.  If the entire patch document
+     * cannot be successfully applied, then the server MUST NOT apply any of
+     * the changes.  The determination of what constitutes a successful
+     * PATCH can vary depending on the patch document and the type of
+     * resource(s) being modified.  For example, the common 'diff' utility
+     * can generate a patch document that applies to multiple files in a
+     * directory hierarchy.  The atomicity requirement holds for all
+     * directly affected files.  See "Error Handling", Section 2.2, for
+     * details on status codes and possible error conditions.
+     *
+     * If the request passes through a cache and the Request-URI identifies
+     * one or more currently cached entities, those entries SHOULD be
+     * treated as stale.  A response to this method is only cacheable if it
+     * contains explicit freshness information (such as an Expires header or
+     * "Cache-Control: max-age" directive) as well as the Content-Location
+     * header matching the Request-URI, indicating that the PATCH response
+     * body is a resource representation.  A cached PATCH response can only
+     * be used to respond to subsequent GET and HEAD requests; it MUST NOT
+     * be used to respond to other methods (in particular, PATCH).
+     *
+     * Note that entity-headers contained in the request apply only to the
+     * contained patch document and MUST NOT be applied to the resource
+     * being modified.  Thus, a Content-Language header could be present on
+     * the request, but it would only mean (for whatever that's worth) that
+     * the patch document had a language.  Servers SHOULD NOT store such
+     * headers except as trace information, and SHOULD NOT use such header
+     * values the same way they might be used on PUT requests.  Therefore,
+     * this document does not specify a way to modify a document's Content-
+     * Type or Content-Language value through headers, though a mechanism
+     * could well be designed to achieve this goal through a patch document.
+     *
+     * There is no guarantee that a resource can be modified with PATCH.
+     * Further, it is expected that different patch document formats will be
+     * appropriate for different types of resources and that no single
+     * format will be appropriate for all types of resources.  Therefore,
+     * there is no single default patch document format that implementations
+     * are required to support.  Servers MUST ensure that a received patch
+     * document is appropriate for the type of resource identified by the
+     * Request-URI.
+     *
+     * Clients need to choose when to use PATCH rather than PUT.  For
+     * example, if the patch document size is larger than the size of the
+     * new resource data that would be used in a PUT, then it might make
+     * sense to use PUT instead of PATCH.  A comparison to POST is even more
+     * difficult, because POST is used in widely varying ways and can
+     * encompass PUT and PATCH-like operations if the server chooses.  If
+     * the operation does not modify the resource identified by the Request-
+     * URI in a predictable way, POST should be considered instead of PATCH
+     * or PUT.
+     */
+    readonly PATCH: "PATCH";
+};
+
+export { HttpRequestMethod };

package/dist/methods.js

@@ -0,0 +1,2 @@
+var T={OPTIONS:"OPTIONS",GET:"GET",HEAD:"HEAD",POST:"POST",PUT:"PUT",DELETE:"DELETE",TRACE:"TRACE",CONNECT:"CONNECT",PATCH:"PATCH"};export{T as HttpRequestMethod};
+//# sourceMappingURL=methods.js.map

package/dist/methods.js.map

@@ -0,0 +1,7 @@
+{
+  "version": 3,
+  "sources": ["../src/http-request-methods.ts"],
+  "sourcesContent": ["/**\n * Defining a constant object with the name HttpRequestMethod.\n */\nconst HttpRequestMethod = {\n\t/**\n\t * The OPTIONS method represents a request for information about the communication options available on the\n\t * request/response chain identified by the Request-URI. This method allows the client to determine the options and/or\n\t * requirements associated with a resource, or the capabilities of a server, without implying a resource action or\n\t * initiating a resource retrieval.\n\t *\n\t * Responses to this method are not cacheable.\n\t *\n\t * If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or\n\t * Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does\n\t * not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed\n\t * queries on the server. A server that does not support such an extension MAY discard the request body.\n\t *\n\t * If the Request-URI is an asterisk (\"*\"), the OPTIONS request is intended to apply to the server in general rather\n\t * than to a specific resource. Since a server's communication options typically depend on the resource, the \"*\"\n\t * request is only useful as a \"ping\" or \"no-op\" type of method, it does nothing beyond allowing the client to test the\n\t * capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).\n\t *\n\t * If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when\n\t * communicating with that resource.\n\t *\n\t * A 200 response SHOULD include any header fields that indicate optional features implemented by the server and\n\t * applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The\n\t * response body, if any, SHOULD also include information about the communication options. The format for such a body\n\t * is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be\n\t * used to select the appropriate response format. If no response body is included, the response MUST include a\n\t * Content-Length field with a field-value of \"0\".\n\t *\n\t * The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy\n\t * receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a\n\t * Max-Forwards field. If the Max-Forwards field-value is zero (\"0\"), the proxy MUST NOT forward the message, instead,\n\t * the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater\n\t * than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is\n\t * present in the request, then the forwarded request MUST NOT include a Max-Forwards field.\n\t */\n\tOPTIONS: 'OPTIONS',\n\t/**\n\t * The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If\n\t * the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in\n\t * the response and not the source text of the process, unless that text happens to be the output of the process.\n\t *\n\t * The semantics of the GET method change to a \"conditional GET\" if the request message includes an If-Modified-Since;\n\t * If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the\n\t * entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET\n\t * method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring\n\t * multiple requests or transferring data already held by the client.\n\t *\n\t * The semantics of the GET method change to a \"partial GET\" if the request message includes a Range header field. A\n\t * partial GET requests that only part of the entity be transferred, as described in section 14.35. The partial GET\n\t * method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed\n\t * without transferring data already held by the client.\n\t *\n\t * The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in\n\t * section 13.\n\t *\n\t * See section 15.1.3 for security considerations when used for forms.\n\t */\n\tGET: 'GET',\n\t/**\n\t * The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The\n\t * meta information contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information\n\t * sent in response to a GET request. This method can be used for obtaining meta information about the entity implied by\n\t * the request without transferring the entity-body itself. This method is often used for testing hypertext links for\n\t * validity, accessibility, and recent modification.\n\t *\n\t * The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be\n\t * used to update a previously cached entity from that resource. If the new field values indicate that the cached\n\t * entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or\n\t * Last-Modified), then the cache MUST treat the cache entry as stale.\n\t */\n\tHEAD: 'HEAD',\n\t/**\n\t * The POST method is used to request that the origin server accept the entity enclosed in the request as a new\n\t * subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform\n\t * method to cover the following functions:\n\t * <ul>\n\t *     <li>Annotation of existing resources,</li>\n\t *     <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles,</li>\n\t *     <li>Providing a block of data, such as the result of submitting a form, to a data-handling process,</li>\n\t *     <li>Extending a database through an append operation.</li>\n\t * </ul>\n\t *\n\t * The actual function performed by the POST method is determined by the server and is usually dependent on the\n\t * Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory\n\t * containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a\n\t * database.\n\t *\n\t * The action performed by the POST method might not result in a resource that can be identified by a URI. In this\n\t * case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the\n\t * response includes an entity that describes the result.\n\t *\n\t * If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity\n\t * which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).\n\t *\n\t * Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header\n\t * fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.\n\t *\n\t * POST requests MUST obey the message transmission requirements set out in section 8.2.\n\t *\n\t * See section 15.1.3 for security considerations.\n\t */\n\tPOST: 'POST',\n\t/**\n\t * The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers\n\t * to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing\n\t * on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being\n\t * defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If\n\t * a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an\n\t * existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate\n\t * successful completion of the request. If the resource could not be created or modified with the Request-URI, an\n\t * appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST\n\t * \\NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a\n\t * 501 (Not Implemented) response in such cases.\n\t *\n\t * If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those\n\t * entries SHOULD be treated as stale. Responses to this method are not cacheable.\n\t *\n\t * The fundamental difference between the POST and PUT requests is reflected in the different meaning of the\n\t * Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource\n\t * might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations.\n\t * In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what\n\t * URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires\n\t * that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response, the user agent MAY\n\t * then make its own decision regarding whether or not to redirect the request.\n\t *\n\t * A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying\n\t * \"the current version\" which is separate from the URI identifying each particular version. In this case, a PUT\n\t * request on a general URI might result in several other URIs being defined by the origin server.\n\t *\n\t * HTTP/1.1 does not define how a PUT method affects the state of an origin server.\n\t *\n\t * PUT requests MUST obey the message transmission requirements set out in section 8.2.\n\t *\n\t * Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied\n\t * to the resource created or modified by the PUT.\n\t */\n\tPUT: 'PUT',\n\t/**\n\t * The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY\n\t * be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the\n\t * operation has been carried out, even if the status code returned from the origin server indicates that the action\n\t * has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response\n\t * is given, it intends to delete the resource or move it to an inaccessible location.\n\t *\n\t * A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if\n\t * the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not\n\t * include an entity.\n\t *\n\t * If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those\n\t * entries SHOULD be treated as stale. Responses to this method are not cacheable.\n\t */\n\tDELETE: 'DELETE',\n\t/**\n\t * The TRACE method is used to invoke a remote, application-layer loop- back of the request message. The final\n\t * recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK)\n\t * response. The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards\n\t * value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity.\n\t *\n\t * TRACE allows the client to see what is being received at the other end of the request chain and use that data for\n\t * testing or diagnostic information. The value of the Via header field (section 14.45) is of particular interest,\n\t * since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the\n\t * length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.\n\t *\n\t * If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a\n\t * Content-Type of \"message/http\". Responses to this method MUST NOT be cached.\n\t */\n\tTRACE: 'TRACE',\n\t/**\n\t * This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a\n\t * tunnel (e.g. SSL tunneling [44]).\n\t */\n\tCONNECT: 'CONNECT',\n\t/**\n\t * The PATCH method requests that a set of changes described in the\n\t * request entity be applied to the resource identified by the Request-\n\t * URI.  The set of changes is represented in a format called a \"patch\n\t * document\" identified by a media type.  If the Request-URI does not\n\t * point to an existing resource, the server MAY create a new resource,\n\t * depending on the patch document type (whether it can logically modify\n\t * a null resource) and permissions, etc.\n\t *\n\t * The difference between the PUT and PATCH requests is reflected in the\n\t * way the server processes the enclosed entity to modify the resource\n\t * identified by the Request-URI.  In a PUT request, the enclosed entity\n\t * is considered to be a modified version of the resource stored on the\n\t * origin server, and the client is requesting that the stored version\n\t * be replaced.  With PATCH, however, the enclosed entity contains a set\n\t * of instructions describing how a resource currently residing on the\n\t * origin server should be modified to produce a new version.  The PATCH\n\t * method affects the resource identified by the Request-URI, and it\n\t * also MAY have side effects on other resources; i.e., new resources\n\t * may be created, or existing ones modified, by the application of a\n\t * PATCH.\n\t *\n\t * PATCH is neither safe nor idempotent as defined by [RFC2616], Section\n\t * 9.1.\n\t *\n\t * A PATCH request can be issued in such a way as to be idempotent,\n\t * which also helps prevent bad outcomes from collisions between two\n\t * PATCH requests on the same resource in a similar time frame.\n\t * Collisions from multiple PATCH requests may be more dangerous than\n\t * PUT collisions because some patch formats need to operate from a\n\t * known base-point or else they will corrupt the resource.  Clients\n\t * using this kind of patch application SHOULD use a conditional request\n\t * such that the request will fail if the resource has been updated\n\t * since the client last accessed the resource.  For example, the client\n\t * can use a strong ETag [RFC2616] in an If-Match header on the PATCH\n\t * request.\n\t *\n\t * There are also cases where patch formats do not need to operate from\n\t * a known base-point (e.g., appending text lines to log files, or non-\n\t * colliding rows to database tables), in which case the same care in\n\t * client requests is not needed.\n\t *\n\t * The server MUST apply the entire set of changes atomically and never\n\t * provide (e.g., in response to a GET during this operation) a\n\t * partially modified representation.  If the entire patch document\n\t * cannot be successfully applied, then the server MUST NOT apply any of\n\t * the changes.  The determination of what constitutes a successful\n\t * PATCH can vary depending on the patch document and the type of\n\t * resource(s) being modified.  For example, the common 'diff' utility\n\t * can generate a patch document that applies to multiple files in a\n\t * directory hierarchy.  The atomicity requirement holds for all\n\t * directly affected files.  See \"Error Handling\", Section 2.2, for\n\t * details on status codes and possible error conditions.\n\t *\n\t * If the request passes through a cache and the Request-URI identifies\n\t * one or more currently cached entities, those entries SHOULD be\n\t * treated as stale.  A response to this method is only cacheable if it\n\t * contains explicit freshness information (such as an Expires header or\n\t * \"Cache-Control: max-age\" directive) as well as the Content-Location\n\t * header matching the Request-URI, indicating that the PATCH response\n\t * body is a resource representation.  A cached PATCH response can only\n\t * be used to respond to subsequent GET and HEAD requests; it MUST NOT\n\t * be used to respond to other methods (in particular, PATCH).\n\t *\n\t * Note that entity-headers contained in the request apply only to the\n\t * contained patch document and MUST NOT be applied to the resource\n\t * being modified.  Thus, a Content-Language header could be present on\n\t * the request, but it would only mean (for whatever that's worth) that\n\t * the patch document had a language.  Servers SHOULD NOT store such\n\t * headers except as trace information, and SHOULD NOT use such header\n\t * values the same way they might be used on PUT requests.  Therefore,\n\t * this document does not specify a way to modify a document's Content-\n\t * Type or Content-Language value through headers, though a mechanism\n\t * could well be designed to achieve this goal through a patch document.\n\t *\n\t * There is no guarantee that a resource can be modified with PATCH.\n\t * Further, it is expected that different patch document formats will be\n\t * appropriate for different types of resources and that no single\n\t * format will be appropriate for all types of resources.  Therefore,\n\t * there is no single default patch document format that implementations\n\t * are required to support.  Servers MUST ensure that a received patch\n\t * document is appropriate for the type of resource identified by the\n\t * Request-URI.\n\t *\n\t * Clients need to choose when to use PATCH rather than PUT.  For\n\t * example, if the patch document size is larger than the size of the\n\t * new resource data that would be used in a PUT, then it might make\n\t * sense to use PUT instead of PATCH.  A comparison to POST is even more\n\t * difficult, because POST is used in widely varying ways and can\n\t * encompass PUT and PATCH-like operations if the server chooses.  If\n\t * the operation does not modify the resource identified by the Request-\n\t * URI in a predictable way, POST should be considered instead of PATCH\n\t * or PUT.\n\t */\n\tPATCH: 'PATCH'\n} as const;\n\nexport { HttpRequestMethod };"],
+  "mappings": "AAGA,IAAMA,EAAoB,CAoCzB,QAAS,UAsBT,IAAK,MAaL,KAAM,OA+BN,KAAM,OAmCN,IAAK,MAeL,OAAQ,SAeR,MAAO,QAKP,QAAS,UA+FT,MAAO,OACR",
+  "names": ["HttpRequestMethod"]
+}

package/dist/response-headers.d.ts

@@ -0,0 +1,345 @@
+/** Defining a constant object HTTP response headers */
+declare const HttpResponseHeader: {
+    /**
+     * Implemented as a misunderstanding of the HTTP specifications. Common because of mistakes in implementations of early HTTP versions. Has exactly the same functionality as standard Connection field.
+     *
+     * @example
+     * proxy-connection: keep-alive
+     */
+    readonly PROXY_CONNECTION: "proxy-connection";
+    /**
+     * Server-side deep packet insertion of a unique ID identifying customers of Verizon Wireless, also known as "perma-cookie" or "supercookie"
+     *
+     * @example
+     * x-uidh: ...
+     */
+    readonly X_UIDH: "x-uidh";
+    /**
+     * Used to prevent cross-site request forgery. Alternative header names are: X-CSRFToken and X-XSRF-TOKEN
+     *
+     * @example
+     * x-csrf-token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
+     */
+    readonly X_CSRF_TOKEN: "x-csrf-token";
+    /**
+     * Specifying which web sites can participate in cross-origin resource sharing
+     *
+     * @example
+     * access-control-allow-origin: *
+     * Provisional
+     */
+    readonly ACCESS_CONTROL_ALLOW_ORIGIN: "access-control-allow-origin";
+    /**
+     * Specifies which patch document formats this server supports
+     *
+     * @example
+     * accept-patch: text/example,charset=utf-8
+     * Permanent
+     */
+    readonly ACCEPT_PATCH: "accept-patch";
+    /**
+     * What partial content range types this server supports via byte serving
+     *
+     * @example
+     * accept-ranges: bytes
+     * Permanent
+     */
+    readonly ACCEPT_RANGES: "accept-ranges";
+    /**
+     * The age the object has been in a proxy cache in seconds
+     *
+     * @example
+     * age: 12
+     * Permanent
+     */
+    readonly AGE: "age";
+    /**
+     * Valid actions for a specified resource. To be used for a 405 Method not allowed
+     *
+     * @example
+     * allow: GET, HEAD
+     * Permanent
+     */
+    readonly ALLOW: "allow";
+    /**
+     * Tells all caching mechanisms from server to client whether they may cache this object. It is measured in seconds
+     *
+     * @example
+     * cache-control: max-age=3600
+     * Permanent
+     */
+    readonly CACHE_CONTROL: "cache-control";
+    /**
+     * Control options for the current connection and list of hop-by-hop response fields
+     *
+     * @example
+     * connection: close
+     * Permanent
+     */
+    readonly CONNECTION: "connection";
+    /**
+     * An opportunity to raise a "File Download" dialogue box for a known MIME type with binary format or suggest a filename for dynamic content. Quotes are necessary with special characters.
+     *
+     * @example
+     * content-disposition: attachment, filename="fname.ext"
+     * Permanent
+     */
+    readonly CONTENT_DISPOSITION: "content-disposition";
+    /**
+     * The type of encoding used on the data. See HTTP compression.
+     *
+     * @example
+     * content-encoding: gzip
+     * Permanent
+     */
+    readonly CONTENT_ENCODING: "content-encoding";
+    /**
+     * The natural language or languages of the intended audience for the enclosed content
+     *
+     * @example
+     * content-language: da
+     * Permanent
+     */
+    readonly CONTENT_LANGUAGE: "content-language";
+    /**
+     * The length of the response body in octets (8-bit bytes)
+     *
+     * @example
+     * content-length: 348
+     * Permanent
+     */
+    readonly CONTENT_LENGTH: "content-length";
+    /**
+     * An alternate location for the returned data
+     *
+     * @example
+     * content-location: /index.htm
+     * Permanent
+     */
+    readonly CONTENT_LOCATION: "content-location";
+    /**
+     * Where in a full body message this partial message belongs
+     *
+     * @example
+     * content-range: bytes 21010-47021/47022
+     * Permanent
+     */
+    readonly CONTENT_RANGE: "content-range";
+    /**
+     * The MIME type of this content
+     *
+     * @example
+     * content-type: text/html, charset=utf-8
+     * Permanent
+     */
+    readonly CONTENT_TYPE: "content-type";
+    /**
+     * The date and time that the message was sent (in "HTTP-date" format as defined by RFC 7231)
+     *
+     * @example
+     * date: Tue, 15 Nov 1994 08:12:31 GMT
+     * Permanent
+     */
+    readonly DATE: "date";
+    /**
+     * An identifier for a specific version of a resource, often a message digest
+     *
+     * @example
+     * etag: "737060cd8c284d8af7ad3082f209582d"
+     * Permanent
+     */
+    readonly ETAG: "etag";
+    /**
+     * Gives the date/time after which the response is considered stale (in "HTTP-date" format as defined by RFC 7231)
+     *
+     * @example
+     * expires: Thu, 01 Dec 1994 16:00:00 GMT
+     * Permanent
+     */
+    readonly EXPIRES: "expires";
+    /**
+     * The last modified date for the requested object (in "HTTP-date" format as defined by RFC 7231)
+     *
+     * @example
+     * last-modified: Tue, 15 Nov 1994 12:45:26 GMT
+     * Permanent
+     */
+    readonly LAST_MODIFIED: "last-modified";
+    /**
+     * Used to express a typed relationship with another resource, where the relation type is defined by RFC 5988
+     *
+     * @example
+     * link: </feed>, rel="alternate"
+     * Permanent
+     */
+    readonly LINK: "link";
+    /**
+     * Used in redirection, or when a new resource has been created.
+     *
+     * @example
+     * location: http://www.w3.org/pub/WWW/People.html
+     * Permanent
+     */
+    readonly LOCATION: "location";
+    /**
+     * This field is supposed to set P3P policy, in the form of P3P:CP="your_compact_policy". However, P3P did not take off, most browsers have never fully
+     * implemented it, a lot of websites set this field with fake policy text, that was enough to fool browsers the existence of P3P policy and grant permissions for third party cookies.
+     *
+     * @example
+     * p3p: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
+     * Permanent
+     */
+    readonly P3P: "p3p";
+    /**
+     * Implementation-specific fields that may have various effects anywhere along the request-response chain.
+     *
+     * @example
+     * pragma: no-cache
+     * Permanent
+     */
+    readonly PRAGMA: "pragma";
+    /**
+     * Request authentication to access the proxy.
+     *
+     * @example
+     * proxy-authenticate: Basic
+     * Permanent
+     */
+    readonly PROXY_AUTHENTICATION: "proxy-authenticate";
+    /**
+     * HTTP Public Key Pinning, announces hash of website's authentic TLS certificate
+     *
+     * @example
+     * public-key-pins: max-age=2592000, pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=",
+     * Permanent
+     */
+    readonly PUBLIC_KEY_PINS: "public-key-pins";
+    /**
+     * If an entity is temporarily unavailable, this instructs the client to try again later. Value could be a specified period of time (in seconds) or a HTTP-date.
+     *
+     * @example
+     * retry-after: 120
+     * retry-after: Fri, 07 Nov 2014 23:59:59 GMT
+     * Permanent
+     */
+    readonly RETRY_AFTER: "retry-after";
+    /**
+     * A name for the server
+     *
+     * @example
+     * server: Apache/2.4.1 (Unix)
+     * Permanent
+     */
+    readonly SERVER: "server";
+    /**
+     * An HTTP cookie
+     *
+     * @example
+     * set-cookie: UserID=JohnDoe, Max-Age=3600, Version=1
+     * Permanent
+     */
+    readonly SET_COOKIE: "set-cookie";
+    /**
+     * CGI header field specifying the status of the HTTP response. Normal HTTP responses use a separate "Status-Line" instead, defined by RFC 7230.
+     *
+     * @example
+     * status: 200 OK
+     */
+    readonly STATUS: "status";
+    /**
+     * A HSTS Policy informing the HTTP client how long to cache the HTTPS only policy and whether this applies to subdomains.
+     *
+     * @example
+     * strict-transport-security: max-age=16070400, includeSubDomains
+     * Permanent
+     */
+    readonly STRICT_TRANSPORT_SECURITY: "strict-transport-security";
+    /**
+     * The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer coding.
+     *
+     * @example
+     * trailer: Max-Forwards
+     * Permanent
+     */
+    readonly TRAILER: "trailer";
+    /**
+     * The form of encoding used to safely transfer the entity to the user. Currently defined methods are: chunked, compress, deflate, gzip, identity.
+     *
+     * @example
+     * transfer-encoding: chunked
+     * Permanent
+     */
+    readonly TRANSFER_ENCODING: "transfer-encoding";
+    /**
+     * Ask the client to upgrade to another protocol.
+     *
+     * @example
+     * upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
+     * Permanent
+     */
+    readonly UPGRADE: "upgrade";
+    /**
+     * Tells downstream proxies how to match future request headers to decide whether the cached response can be used rather than requesting a fresh one from the origin server.
+     *
+     * @example
+     * vary: *
+     * Permanent
+     */
+    readonly VARY: "vary";
+    /**
+     * Informs the client of proxies through which the response was sent.
+     *
+     * @example
+     * via: 1.0 fred, 1.1 example.com (Apache/1.1)
+     * Permanent
+     */
+    readonly VIA: "via";
+    /**
+     * A general warning about possible problems with the entity body.
+     *
+     * @example
+     * warning: 199 Miscellaneous warning
+     * Permanent
+     */
+    readonly WARNING: "warning";
+    /**
+     * Indicates the authentication scheme that should be used to access the requested entity.
+     *
+     * @example
+     * www-authenticate: Basic
+     * Permanent
+     */
+    readonly WWW_AUTHENTICATE: "www-authenticate";
+    /**
+     * Cross-site scripting (XSS) filter
+     *
+     * @example
+     * x-xss-protection: 1, mode=block
+     */
+    readonly X_XSS_PROTECTION: "x-xss-protection";
+    /**
+     * The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed
+     * to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints.
+     * This helps guard against cross-site scripting attacks (Cross-site_scripting).
+     *
+     * @example
+     * content-security-policy: default-src
+     */
+    readonly CONTENT_SECURITY_POLICY: "content-security-policy";
+    /**
+     * The only defined value, "nosniff", prevents Internet Explorer from MIME-sniffing a response away from the declared content-type. This also applies to Google Chrome, when downloading extensions.
+     *
+     * @example
+     * x-content-type-options: nosniff
+     */
+    readonly X_CONTENT_TYPE_OPTIONS: "x-content-type-options";
+    /**
+     * specifies the technology (e.g. ASP.NET, PHP, JBoss) supporting the web application (version details are often in X-Runtime, X-Version, or X-AspNet-Version)
+     *
+     * @example
+     * x-powered-by: PHP/5.4.0
+     */
+    readonly X_POWERED_BY: "x-powered-by";
+};
+
+export { HttpResponseHeader };