@d1g1tal/transportr 1.4.4 → 2.0.0

package/src/http-request-methods.js

@@ -1,277 +0,0 @@
-/**
- * Defining a constant object with the name HttpRequestMethod.
- *
- * @module HttpRequestMethod
- * @constant {Object<string, string>}
- */
-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.
-	 */
-	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'
-};
-
-export default HttpRequestMethod;

package/src/http-response-headers.js

@@ -1,350 +0,0 @@
-/**
- * Defining a constant object with a bunch of properties.
- *
- * @module HttpResponseHeader
- * @constant {Object<string, string>}
- */
-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
-	 */
-	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'
-};
-
-export default HttpResponseHeader;