             let line = try stream.receiveLine()
             guard !line.isEmpty else { break }
             /*
-             https://tools.ietf.org/html/rfc7230#section-3
-
-             ******* [WARNING] ********
-
-             A sender MUST NOT send whitespace between the start-line and the
-             first header field.  A recipient that receives whitespace between the
-             start-line and the first header field MUST either reject the message
-             as invalid or consume each whitespace-preceded line without further
-             processing of it (i.e., ignore the entire line, along with any
-             subsequent lines preceded by whitespace, until a properly formed
-             header field is received or the header section is terminated).
-
-             The presence of such whitespace in a request might be an attempt to
-             trick a server into ignoring that field or processing the line after
-             it as a new request, either of which might result in a security
-             vulnerability if other implementations within the request chain
-             interpret the same message differently.  Likewise, the presence of
-             such whitespace in a response might be ignored by some clients or
-             cause others to cease parsing.
-             */
+                 https://tools.ietf.org/html/rfc7230#section-3
+
+                 ******* [WARNING] ********
+
+                 A sender MUST NOT send whitespace between the start-line and the
+                 first header field.  A recipient that receives whitespace between the
+                 start-line and the first header field MUST either reject the message
+                 as invalid or consume each whitespace-preceded line without further
+                 processing of it (i.e., ignore the entire line, along with any
+                 subsequent lines preceded by whitespace, until a properly formed
+                 header field is received or the header section is terminated).
+
+                 The presence of such whitespace in a request might be an attempt to
+                 trick a server into ignoring that field or processing the line after
+                 it as a new request, either of which might result in a security
+                 vulnerability if other implementations within the request chain
+                 interpret the same message differently.  Likewise, the presence of
+                 such whitespace in a response might be ignored by some clients or
+                 cause others to cease parsing.
+            */
             guard whitespaceCheck || !line[0].isWhitespace else { throw Error.invalidRequest }
             whitespaceCheck = true
 
             /*
-             Each header field consists of a case-insensitive field name followed
-             by a colon (":"), optional leading whitespace, the field value, and
-             optional trailing whitespace.
-
-             header-field   = field-name ":" OWS field-value OWS
-
-             field-name     = token
-             field-value    = *( field-content / obs-fold )
-             field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
-             field-vchar    = VCHAR / obs-text
-
-             obs-fold       = CRLF 1*( SP / HTAB )
-             ; obsolete line folding
-             ; see Section 3.2.4
-
-             The field-name token labels the corresponding field-value as having
-             the semantics defined by that header field.  For example, the Date
-             header field is defined in Section 7.1.1.2 of [RFC7231] as containing
-             the origination timestamp for the message in which it appears.
-             */
+                 Each header field consists of a case-insensitive field name followed
+                 by a colon (":"), optional leading whitespace, the field value, and
+                 optional trailing whitespace.
+
+                 header-field   = field-name ":" OWS field-value OWS
+
+                 field-name     = token
+                 field-value    = *( field-content / obs-fold )
+                 field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
+                 field-vchar    = VCHAR / obs-text
+
+                 obs-fold       = CRLF 1*( SP / HTAB )
+                 ; obsolete line folding
+                 ; see Section 3.2.4
+
+                 The field-name token labels the corresponding field-value as having
+                 the semantics defined by that header field.  For example, the Date
+                 header field is defined in Section 7.1.1.2 of [RFC7231] as containing
+                 the origination timestamp for the message in which it appears.
+            */
             let comps = line.split(separator: .colon, maxSplits: 1)
             guard comps.count == 2 else { continue }
 
             /*
-             No whitespace is allowed between the header field-name and colon.  In
-             the past, differences in the handling of such whitespace have led to
-             security vulnerabilities in request routing and response handling.  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).
-             */
+                 No whitespace is allowed between the header field-name and colon.  In
+                 the past, differences in the handling of such whitespace have led to
+                 security vulnerabilities in request routing and response handling.  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).
+            */
             guard comps[0].last?.isWhitespace == false else { throw Error.invalidKeyWhitespace }
             let field = comps[0].string
             let value = comps[1].array

            where transferEncoding.lowercased().hasSuffix("chunked") // chunked MUST be last component
        {
            /*
             3.6.1 Chunked Transfer Coding

             The chunked encoding modifies the body of a message in order to
             transfer it as a series of chunks, each with its own size indicator,
             followed by an OPTIONAL trailer containing entity-header fields. This
             allows dynamically produced content to be transferred along with the
             information necessary for the recipient to verify that it has
             received the full message.
             */
            var buffer: Bytes = []

            while true {

            // 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
            */
            let host: String
            let port: Int

