* 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 HTTPMethod to a struct
* Compare on rawValue rather than description
* Remove RawRepresentable and add ExpressibleByStringLiteral conformance
* Make HTTPHeaders more user-friendly
* Header name is a struct conforming to `ExpressibleByStringLiteral`.
Standard header names are available through static constants.
This allows to save some CPU on lowercasing and hash value
calculation.
* Original headers are stored until first modification. Iterator
of `HTTPHeaders` iterates over original headers while they are actual,
in other case it iterates over underlying mutable dictionary.
* Default subscript returns values of all headers with the same
name concatenated with comma [RFC7230, section 3.2.2], except
for "Set-Cookie" for which only first value is returned.
* As-is values of all headers with same name can be accessed
through subscript with label `valuesFor`.
* append() method is modified to accept dictionary literal.
replace() method is added.
* Split HTTPHeaders implementation to separate extensions
* 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
HTTP is a living protocol, methods are added
all the time.
I would prefer that we wouldn't use a closed
construct like an enum for an extensible type,
but at least we need to have a 'other' case
to be future-proof.
Helge Hess
Aleksey Mashanov
Chris Bailey