Tags: swift-server/async-http-client
Tags
Add support for HTTP/1 connection pre-warming (#856) Motivation This patch adds support for HTTP/1 connection pre-warming. This allows the user to request that the HTTP/1 connection pool create and maintain extra connections, above-and-beyond those strictly needed to run the pool. This pool can be used to absorb small spikes in request traffic without increasing latency to account for connection creation. Modifications - Added new configuration properties for pre-warmed connections. - Amended the HTTP/1 state machine to create new connections where necessary. - Added state machine tests. Results Pre-warmed connections are available.
Fix trailing space in ConnectionPool.Key string (#855) Motivation: The trailing space is visible in log message metadata, and depending upon the log handler in use, will sometimes be visible due to quoting. Modifications: Just remove the trailing space. Result: There won't be a trailing space in the key anymore. This has no functional impact whatsoever as far as I was able to determine.
Work around Foundation revert (#813) Motivation Foundation has reverted several of the changes of behaviour in the URL type, leaving 6.0 and 6.1 with a different behaviour on non-Apple platforms than all other versions. We should tolerate that. Modifications Update the tests to understand the difference. Result Tests pass
fix 5.10 compile on Ubuntu 24.04 (Noble) for Intel (x86_64) (#810) Specifically Swift 5.10 _on Intel on Ubuntu Noble (24.04)_ has a crazy bug which leads to compilation failures in a `#if compiler(>=6.0)` block: swiftlang/swift#79285 . This workaround fixes the compilation by _changing the whitespace_. Thanks @gwynne for finding this workaround! --------- Co-authored-by: Johannes Weiss <johannes@jweiss.io>
baby steps towards a Structured Concurrency API (#806) At the moment, `HTTPClient`'s entire API surface violates Structured Concurrency. Both the creation & shutdown of a HTTP client as well as making requests (#807) doesn't follow Structured Concurrency. Some of the problems are: 1. Upon return of methods, resources are still in active use in other threads/tasks 2. Cancellation doesn't always work This PR is baby steps towards a Structured Concurrency API, starting with start/shutdown of the HTTP client. Co-authored-by: Johannes Weiss <johannes@jweiss.io>
Avoid precondition failure in write timeout (#803) ### Motivation: In some cases we can crash because of a precondition failure when the write timeout fires and we aren't in the running state. This can happen for example if the connection is closed whilst the write timer is active. ### Modifications: * Remove the precondition and instead take no action if the timeout fires outside of the running state. Instead we take a new `Action`, `.noAction` when the timer fires. * Clear write timeouts upon request completion. When a request completes we have no use for the idle write timer, we clear the read timer and we should clear the write one too. ### Result: Fewer crashes. The supplied tests fails without these changes and passes with either of them.
PreviousNext