Conform to RFC 7230

[hjr3]

Regardless of using an internal HTTP library or hyper, there are a number of things an intermediary (gateway) must do in order to confirm with http://httpwg.org/specs/rfc7230.html.

Requirements (MUST or MUST NOT):

• Per Section 2.6 - Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) MUST send their own HTTP-version in forwarded messages.
• Per Section 3.2.1 - A proxy MUST forward unrecognized header fields unless the field-name is listed in the Connection header field (Section 6.1) or the proxy is specifically configured to block, or otherwise transform, such fields.
• Per Section 3.2.2 - A proxy MUST NOT change the order of these field values when forwarding a message.
• Per Section 3.2.4 - A proxy MUST remove any such whitespace from a response message before forwarding the message downstream.
• Per Section 3.2.4 - A proxy or gateway that receives an obs-fold in a response message that is not within a message/http container MUST either discard the message and replace it with a 502 (Bad Gateway) response, preferably with a representation explaining that unacceptable line folding was received, or replace each received obs-fold with one or more SP octets prior to interpreting the field value or forwarding the message downstream.
• Per Section 5.3.4 - If a proxy receives an OPTIONS request with an absolute-form of request-target in which the URI has an empty path and no query component, then the last proxy on the request chain MUST send a request-target of "*" when it forwards the request to the indicated origin server.
• Per Section 5.4 - When a proxy receives a request with an absolute-form of request-target, the proxy MUST ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy that forwards such a request MUST generate a new Host field-value based on the received request-target rather than forward the received Host field-value.
• Per Section 5.7 - An intermediary not acting as a tunnel MUST implement the Connection header field, as specified in Section 6.1, and exclude fields from being forwarded that are only intended for the incoming connection.
• Per Section 5.7 - An intermediary MUST NOT forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly.
• Per Section 5.7.1 - A proxy MUST send an appropriate Via header field, as described below, in each message that it forwards. An HTTP-to-HTTP gateway MUST send an appropriate Via header field in each inbound request message and MAY send a Via header field in forwarded response messages.
• Per Section 5.7.2 - A proxy MUST NOT change the host name if the request-target contains a fully qualified domain name.
• Per Section 5.7.2 - A proxy MUST NOT modify the "absolute-path" and "query" parts of the received request-target when forwarding it to the next inbound server, except as noted above to replace an empty path with "/" or "*".
• Per Section 5.7.2 - A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of a message that contains a no-transform cache-control directive (Section 5.2 of [RFC7234]).
• Per Section 6.1 - In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message.
• Per Section 6.1 - A proxy or gateway MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field itself (or replace it with the intermediary's own connection options for the forwarded message).
• Per Section 6.3 - A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
• Per Section 6.3.1 - A proxy MUST NOT automatically retry non-idempotent requests.

Best practices (MAY, MAY NOT, SHOULD, SHOULD NOT)

To Do