* Simplification of HTTPResponse/HTTPResponseWriter
* `HTTPResponse` is redundent. Its `status` and `headers` properties
are moved to parameters of `writeHeader` method of `HTTPResponseWriter`
instance. `transferEncoding` handling is moved to `HTTPHeaders` - it
is not as simple as an enum and depends on used HTTP protocol version
and capabilites set by a client in its request headers.
`httpVersion` should not be configured by an outer scope - a server should
use the HTTP version which was requested by a client.
* `writeResponse` and `writeContinue` are replaced by `writeHeader`.
* `writeTrailer` accepts trailers as `HTTPHeaders` struct.
* All `write*` methods accept a completion handler.
* `writeBody` accepts `UnsafeHTTPResponseBody` instead of just `Data`
and `Dispatch`. It should be used only in the scope of a call and a
copy should be made or value should be checked for `HTTPResponseBody`
conformance before storing it anythere. This approch allows to reduce
memory copying.
* `Result<POSIXError, Void>` enum is replaced with `Result`. In the
first case `POSIXError` and `Void` are generic parameters names, not
types. I think this behaviour was unintended.
* Always respond with HTTP/1.1 for any HTTP/1.x requests
* Get back HTTPResponse for possible use in the client
* Convert HTTPResponseStatus to a struct
* `HTTPResponseStatus` is a struct now. It is better then an enum
in this case because it could be possible to provide an alternative
reason phrase as allowed by RFC7231:
"The reason phrases listed here are only recommendations -- they
can be replaced by local equivalents without affecting the protocol."
* `HTTPResponseStatus` struct is smaller then enum. Struct's size(stride)
are 32(32) whereas enum's are 33(40).
* Removed conformance to protocol `RawRepresentable` because custom
reason phrases conflict with the message of `RawRepresentable`:
"With a RawRepresentable type, you can switch back and forth between a
custom type and an associated RawValue type without losing the value
of the original RawRepresentable type."
* Added conformance to `CustomStringConvertble` to provide an easy
conversion to HTTP status line.
* Added conformance to `ExpressibleByIntegerLiteral` to provide an
easy way to pass numeric value instead of `.humanReadable`.
For many server-side developers 200, 404 and 500 have much more
meaning then `.ok`, `.notFound` and `.internalServerError`.
* Added `class` property in conformance with RFC7231 recommendation:
"HTTP clients are not required to understand the meaning of all
registered status codes, though such understanding is obviously
desirable. However, a client MUST understand the class of any
status code, as indicated by the first digit, and treat an
unrecognized status code as being equivalent to the x00 status
code of that class..."
* Update API documentation for HTTPResponseStatus
* Modify type of HTTP status-code: UInt16 -> Int
`Int` better match Swift API guidelines then `UInt16` and
requires the same memory in struct because of alignment.
* Swiftify HTTPResponseStatus initializers
Arjun Nayini
Ian Partridge
Chris Bailey
Aleksey Mashanov
Tanner