### Motivation
NIO may send `channelRead` events without a handlers requesting more data with a `context.read()` invocation. This happens if the remote has closed the connection and NIO wants to inform the handlers as soon as possible.
### Changes
- Don't `precondition` on `channelRead` events anymore.
- Close channel if we received an http end without a `context.read()` invocation
### Motivation
In the `HTTP1ConnectionStateMachine` we set the connection state to `.closed` after having forwarded an error to the inner RequestStateMachine. Since we set the state to close, the `state.modify` function did not create an action that would close the connection.
### Changes
- Modify the ConnectionState based on the RequestStateMachine's action only in the `state.modify` function.
- Add a test to verify the fixed behavior.
- Use ExpressibleByDictionaryLiteral syntax for some HTTPHeaders to increase readability.
### Result
Connections are closed, if an error happens, while we are in a request.
If a request times out because no connection could be attained, we should fail the request with the last connection creation error. If no connection creation error is present and there is no active connection, we fail the request with a connectTimeout error.
Add a `HTTPConnectionPool.Connection` type that is a box around an actual connection. The purpose of the box is to ensure no actions are invoked on the connection within the state machine. Further the box can be used for testing the state machine without creating actual connections.
- Refactored code from `TaskHandler` into new method `HTTPClient.Request.createRequestHead` that creates an `HTTPRequestHead` and matching `RequestFramingMetadata`
- Added required property `requestFramingMetadata` to `HTTPExecutingRequest`
- Added property `requestFramingMetadata` to `RequestBag`
Co-authored-by: Cory Benfield <lukasa@apple.com>
- Adding four new protocols:
- `HTTPExecutingRequest` a protocol representing an HTTP task that is executed on a ChannelHandler.
- `HTTPScheduledRequest` a protocol representing an HTTP task that is scheduled for execution, but in a waiting state (example: Waiting for an idle connection in the connection pool).
- `HTTPRequestExecutor` a protocol that can be used from the `HTTPExecutingRequest` abstracting away functionality that will normally be implemented by a `ChannelHandler`
- `HTTPRequestScheduler` a protocol that can be used from the `HTTPScheduledRequest` abstracting away functionality that will normally be implemented by a `ConnectionPool`
- An implementation of the `HTTPExecutingTask` and `HTTPScheduledRequest` called `RequestBag`. It implements our current API using the new protocols
Co-authored-by: George Barnett <gbarnett@apple.com>
Co-authored-by: Cory Benfield <lukasa@apple.com>
- `ConsumerControlState` was replaced with `ResponseStreamState` in `HTTPRequestStateMachine`
- `channelRead`s are buffered up to a `channelReadComplete`.
- on `channelReadComplete` all buffered body parts are forwarded to the consumer
This commit adds an explicit `HTTPRequestStateMachine`. It is intended to be used in two instances in the future:
1. As a substate machine for a `HTTP1ConnectionStateMachine`, when the connection is in a request.
2. As a state machine for a `HTTP2RequestHandler` that operates on a single http2 stream created by the multiplexer.
The new code paths are not triggered today, but will be enabled in the future.
- The connection creation logic has been refactored into a number of smaller methods that can be combined
- Connection creation now has a logical home. It is moved from `Utils.swift` into a `ConnectionFactory`
- There are explicit `ChannelHandlers` that are used for connection creation:
- `TLSEventsHandler` got its own file and unit tests
- `HTTP1ProxyConnectHandler` got its own file and unit tests
- `SOCKSEventsHandler` got its own file and unit tests
- Some small things are already part of this pr that will get their context later. For example:
- `HTTPConnectionPool` is added as a namespace to not cause major renames in follow up PRs
- `HTTPConnectionPool.Connection.ID` and its generator were added now. (This will be used later to identify a connection during its lifetime)
- the file `HTTPConnectionPool+Manager` was added to give `HTTPConnectionPool.Connection.ID.Generator` already its final destination.