             // abs_path
 
             /*
-             The most common form of Request-URI is that used to identify a
-             resource on an origin server or gateway. In this case the absolute
-             path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
-             the Request-URI, and the network location of the URI (authority) MUST
-             be transmitted in a Host header field. For example, a client wishing
-             to retrieve the resource above directly from the origin server would
-             create a TCP connection to port 80 of the host "www.w3.org" and send
-             the lines:
-
-             GET /pub/WWW/TheProject.html HTTP/1.1
-             Host: www.w3.org
-             */
+                 The most common form of Request-URI is that used to identify a
+                 resource on an origin server or gateway. In this case the absolute
+                 path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
+                 the Request-URI, and the network location of the URI (authority) MUST
+                 be transmitted in a Host header field. For example, a client wishing
+                 to retrieve the resource above directly from the origin server would
+                 create a TCP connection to port 80 of the host "www.w3.org" and send
+                 the lines:
+
+                 GET /pub/WWW/TheProject.html HTTP/1.1
+                 Host: www.w3.org
+            */
             let host: String
             let port: Int
 


/*
 ****************************** WARNING ******************************

 (reminders)

 ******************************

 A
 server MUST reject any received request message that contains
 whitespace between a header field-name and colon with a response code
 of 400 (Bad Request).

 ******************************

 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.

 ******************************

 The presence of a message body in a response depends on both the
 request method to which it is responding and the response status code
 (Section 3.1.2).  Responses to the HEAD request method (Section 4.3.2
 of [RFC7231]) never include a message body because the associated
 response header fields (e.g., Transfer-Encoding, Content-Length,
 etc.), if present, indicate only what their values would have been if
 the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx
 (Successful) responses to a CONNECT request method (Section 4.3.6 of
 [RFC7231]) switch to tunnel mode instead of having a message body.
 All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
 responses do not include a message body.  All other responses do
 include a message body, although the body might be of zero length.

 ******************************

 A server MAY send a Content-Length header field in a response to a
 HEAD request (Section 4.3.2 of [RFC7231]); a server MUST NOT send
 Content-Length in such a response unless its field-value equals the
 decimal number of octets that would have been sent in the payload
 body of a response if the same request had used the GET method.

 *****************************

 If a message is received that has multiple Content-Length header
 fields with field-values consisting of the same decimal value, or a
 single Content-Length header field with a field value containing a
 list of identical decimal values (e.g., "Content-Length: 42, 42"),
 indicating that duplicate Content-Length header fields have been
 generated or combined by an upstream message processor, then the
 recipient MUST either reject the message as invalid or replace the
 duplicated field-values with a single valid Content-Length field
 containing that decimal value prior to determining the message body
 length or forwarding the message.

 ******************************

 A recipient MUST ignore unrecognized chunk extensions.

 ******************************
 */

public final class RequestParser {
    enum Error: ErrorProtocol {
        case streamEmpty

            // absoluteURI

            /*
                 To allow for transition to absoluteURIs in all requests in future
                 versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
                 form in requests, even though HTTP/1.1 clients will only generate
                 them in requests to proxies.

                 An example Request-Line would be:

                 GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
            */
            uri = try URIParser.parse(uri: uriSlice)
        }
        return uri
    }

    /**
         HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
         of the protocol. The protocol versioning policy is intended to allow
         the sender to indicate the format of a message and its capacity for
