@d1g1tal/transportr 3.1.4 → 3.1.5

package/dist/iife/request-method.js

@@ -1,4 +1,296 @@
-(() => {
-	var T={OPTIONS:"OPTIONS",GET:"GET",HEAD:"HEAD",POST:"POST",PUT:"PUT",DELETE:"DELETE",TRACE:"TRACE",CONNECT:"CONNECT",PATCH:"PATCH"};
-	globalThis.RequestMethod = T;
+var __mod = (() => {
+  var __defProp = Object.defineProperty;
+  var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
+  var __getOwnPropNames = Object.getOwnPropertyNames;
+  var __hasOwnProp = Object.prototype.hasOwnProperty;
+  var __export = (target, all) => {
+    for (var name in all)
+      __defProp(target, name, { get: all[name], enumerable: true });
+  };
+  var __copyProps = (to, from, except, desc) => {
+    if (from && typeof from === "object" || typeof from === "function") {
+      for (let key of __getOwnPropNames(from))
+        if (!__hasOwnProp.call(to, key) && key !== except)
+          __defProp(to, key, { get: () => from[key], enumerable: !(desc = __getOwnPropDesc(from, key)) || desc.enumerable });
+    }
+    return to;
+  };
+  var __toCommonJS = (mod) => __copyProps(__defProp({}, "__esModule", { value: true }), mod);
+
+  // src/request-method.ts
+  var request_method_exports = {};
+  __export(request_method_exports, {
+    RequestMethod: () => RequestMethod
+  });
+  var RequestMethod = {
+    /**
+     * 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.
+     */
+    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.
+     */
+    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.
+     */
+    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.
+     */
+    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.
+     */
+    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.
+     */
+    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.
+     */
+    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]).
+     */
+    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.
+     */
+    PATCH: "PATCH"
+  };
+  return __toCommonJS(request_method_exports);
 })();
+globalThis.RequestMethod = __mod.RequestMethod;

package/dist/iife/response-header.js

@@ -1,4 +1,369 @@
-(() => {
-	var t={PROXY_CONNECTION:"proxy-connection",X_UIDH:"x-uidh",X_CSRF_TOKEN:"x-csrf-token",ACCESS_CONTROL_ALLOW_ORIGIN:"access-control-allow-origin",ACCEPT_PATCH:"accept-patch",ACCEPT_RANGES:"accept-ranges",AGE:"age",ALLOW:"allow",CACHE_CONTROL:"cache-control",CONNECTION:"connection",CONTENT_DISPOSITION:"content-disposition",CONTENT_ENCODING:"content-encoding",CONTENT_LANGUAGE:"content-language",CONTENT_LENGTH:"content-length",CONTENT_LOCATION:"content-location",CONTENT_RANGE:"content-range",CONTENT_TYPE:"content-type",DATE:"date",ETAG:"etag",EXPIRES:"expires",LAST_MODIFIED:"last-modified",LINK:"link",LOCATION:"location",P3P:"p3p",PRAGMA:"pragma",PROXY_AUTHENTICATION:"proxy-authenticate",PUBLIC_KEY_PINS:"public-key-pins",RETRY_AFTER:"retry-after",SERVER:"server",SET_COOKIE:"set-cookie",STATUS:"status",STRICT_TRANSPORT_SECURITY:"strict-transport-security",TRAILER:"trailer",TRANSFER_ENCODING:"transfer-encoding",UPGRADE:"upgrade",VARY:"vary",VIA:"via",WARNING:"warning",WWW_AUTHENTICATE:"www-authenticate",X_XSS_PROTECTION:"x-xss-protection",CONTENT_SECURITY_POLICY:"content-security-policy",X_CONTENT_TYPE_OPTIONS:"x-content-type-options",X_POWERED_BY:"x-powered-by"};
-	globalThis.ResponseHeader = t;
+var __mod = (() => {
+  var __defProp = Object.defineProperty;
+  var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
+  var __getOwnPropNames = Object.getOwnPropertyNames;
+  var __hasOwnProp = Object.prototype.hasOwnProperty;
+  var __export = (target, all) => {
+    for (var name in all)
+      __defProp(target, name, { get: all[name], enumerable: true });
+  };
+  var __copyProps = (to, from, except, desc) => {
+    if (from && typeof from === "object" || typeof from === "function") {
+      for (let key of __getOwnPropNames(from))
+        if (!__hasOwnProp.call(to, key) && key !== except)
+          __defProp(to, key, { get: () => from[key], enumerable: !(desc = __getOwnPropDesc(from, key)) || desc.enumerable });
+    }
+    return to;
+  };
+  var __toCommonJS = (mod) => __copyProps(__defProp({}, "__esModule", { value: true }), mod);
+
+  // src/response-header.ts
+  var response_header_exports = {};
+  __export(response_header_exports, {
+    ResponseHeader: () => ResponseHeader
+  });
+  var ResponseHeader = {
+    /**
+     * 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
+     */
+    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: ...
+     */
+    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
+     */
+    X_CSRF_TOKEN: "x-csrf-token",
+    /**
+     * Specifying which web sites can participate in cross-origin resource sharing
+     *
+     * @example
+     * access-control-allow-origin: *
+     * Provisional
+     */
+    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
+     */
+    ACCEPT_PATCH: "accept-patch",
+    /**
+     * What partial content range types this server supports via byte serving
+     *
+     * @example
+     * accept-ranges: bytes
+     * Permanent
+     */
+    ACCEPT_RANGES: "accept-ranges",
+    /**
+     * The age the object has been in a proxy cache in seconds
+     *
+     * @example
+     * age: 12
+     * Permanent
+     */
+    AGE: "age",
+    /**
+     * Valid actions for a specified resource. To be used for a 405 Method not allowed
+     *
+     * @example
+     * allow: GET, HEAD
+     * Permanent
+     */
+    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
+     */
+    CACHE_CONTROL: "cache-control",
+    /**
+     * Control options for the current connection and list of hop-by-hop response fields
+     *
+     * @example
+     * connection: close
+     * Permanent
+     */
+    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
+     */
+    CONTENT_DISPOSITION: "content-disposition",
+    /**
+     * The type of encoding used on the data. See HTTP compression.
+     *
+     * @example
+     * content-encoding: gzip
+     * Permanent
+     */
+    CONTENT_ENCODING: "content-encoding",
+    /**
+     * The natural language or languages of the intended audience for the enclosed content
+     *
+     * @example
+     * content-language: da
+     * Permanent
+     */
+    CONTENT_LANGUAGE: "content-language",
+    /**
+     * The length of the response body in octets (8-bit bytes)
+     *
+     * @example
+     * content-length: 348
+     * Permanent
+     */
+    CONTENT_LENGTH: "content-length",
+    /**
+     * An alternate location for the returned data
+     *
+     * @example
+     * content-location: /index.htm
+     * Permanent
+     */
+    CONTENT_LOCATION: "content-location",
+    /**
+     * Where in a full body message this partial message belongs
+     *
+     * @example
+     * content-range: bytes 21010-47021/47022
+     * Permanent
+     */
+    CONTENT_RANGE: "content-range",
+    /**
+     * The MIME type of this content
+     *
+     * @example
+     * content-type: text/html, charset=utf-8
+     * Permanent
+     */
+    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
+     */
+    DATE: "date",
+    /**
+     * An identifier for a specific version of a resource, often a message digest
+     *
+     * @example
+     * etag: "737060cd8c284d8af7ad3082f209582d"
+     * Permanent
+     */
+    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
+     */
+    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
+     */
+    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
+     */
+    LINK: "link",
+    /**
+     * Used in redirection, or when a new resource has been created.
+     *
+     * @example
+     * location: http://www.w3.org/pub/WWW/People.html
+     * Permanent
+     */
+    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
+     */
+    P3P: "p3p",
+    /**
+     * Implementation-specific fields that may have various effects anywhere along the request-response chain.
+     *
+     * @example
+     * pragma: no-cache
+     * Permanent
+     */
+    PRAGMA: "pragma",
+    /**
+     * Request authentication to access the proxy.
+     *
+     * @example
+     * proxy-authenticate: Basic
+     * Permanent
+     */
+    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
+     */
+    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
+     */
+    RETRY_AFTER: "retry-after",
+    /**
+     * A name for the server
+     *
+     * @example
+     * server: Apache/2.4.1 (Unix)
+     * Permanent
+     */
+    SERVER: "server",
+    /**
+     * An HTTP cookie
+     *
+     * @example
+     * set-cookie: UserID=JohnDoe, Max-Age=3600, Version=1
+     * Permanent
+     */
+    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
+     */
+    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
+     */
+    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
+     */
+    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
+     */
+    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
+     */
+    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
+     */
+    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
+     */
+    VIA: "via",
+    /**
+     * A general warning about possible problems with the entity body.
+     *
+     * @example
+     * warning: 199 Miscellaneous warning
+     * Permanent
+     */
+    WARNING: "warning",
+    /**
+     * Indicates the authentication scheme that should be used to access the requested entity.
+     *
+     * @example
+     * www-authenticate: Basic
+     * Permanent
+     */
+    WWW_AUTHENTICATE: "www-authenticate",
+    /**
+     * Cross-site scripting (XSS) filter
+     *
+     * @example
+     * x-xss-protection: 1, mode=block
+     */
+    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
+     */
+    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
+     */
+    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
+     */
+    X_POWERED_BY: "x-powered-by"
+  };
+  return __toCommonJS(response_header_exports);
 })();
+globalThis.ResponseHeader = __mod.ResponseHeader;