HTTPResumableUpload contains the core logic. It uses an event loop to
synchronize its state internally. Some methods are safe to call from off
of that event loop and have been moved to a new sendable view. The
HTTPResumableUpload type is marked as explicitly not sendable.
As such, most other types now hold on to the sendable view and use that
as the interface to HTTPResumableUpload.
HTTPResumableUploadChannel must be sendable (it's a Channel) and now
uses safe abstractions (where possible).
We use 8*10^9 in `NIOHTTPResponsiveness` however this number will
overrun the integer size on platforms with 32-bit pointer-width such as
watchOS.
This change drops down to use 1*10^9 on such platforms.
Implementation of
https://datatracker.ietf.org/doc/draft-ietf-ippm-responsiveness/ (draft
5) with flexible download and upload handlers to suit other use cases as
well.
### Motivation:
The provided handlers are useful for measuring responsiveness and
testing things like performance of proxies
### Modifications:
Add `NIOHTTPResponsiveness` and `NIOHTTPResponsivenessServer`
### Result:
We'll now have an implementation of the Responsiveness under Working
Conditions draft
---------
Co-authored-by: George Barnett <gbarnett@apple.com>
Add Android support
### Motivation:
Support the Android platform.
### Modifications:
Add Android imports and fix the default temporary directory to be
correct for the OS.
### Result:
The package will build and test on Android.
---------
Co-authored-by: George Barnett <gbarnett@apple.com>
Motivation:
The latest NIO release deprecated a number of APIs and added more
Sendable contraints.
Modifications:
- Use sync APIs where possible
- Use `_deprecated` but not `@deprecated` NIOFileHandle API
- Stop using NIOAny
Result:
No warnings
Allow applications to trigger HTTP/2 stream resets while using
NIOHTTPTypesHTTP2's codecs
### Motivation:
Resetting streams with specific error codes is required by some
applications such as those implementing the CONNECT method
(see https://datatracker.ietf.org/doc/html/rfc9113#section-8.5-8).
Unfortunately, the HTTP2ToHTTP codecs don't expose this capability to
applications.
### Modifications:
Introduce an outbound user event applications can trigger when needing
to reset an HTTP/2 stream.
### Result:
Now applications can trigger HTTP/2 stream resets while using the codecs
provided by NIOHTTPTypesHTTP2
Enable MemberImportVisibility check on all targets. Use a standard
string header and footer to bracket the new block for ease of updating
in the future with scripts.
Support HTTP resumable upload.
### Motivation:
Supporting HTTP resumable upload protocol defined in
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-resumable-upload-05
* Interop version 3: iOS 17.0, macOS 14.0
* Interop version 5: iOS 18.0, macOS 15.0
* Interop version 6: iOS 18.1, macOS 15.1
### Modifications:
2 new public classes, `HTTPResumableUploadHandler` and
`HTTPResumableUploadContext`, and a few other supporting objects to
manage resumable uploads and translate them into regular uploads.
---------
Co-authored-by: Jonathan Flat <jflat@apple.com>
Co-authored-by: Cory Benfield <lukasa@apple.com>
### Motivation:
To migrate to GitHub actions and centralised infrastructure.
### Modifications:
Changes of note:
* Adopt swift-format using rules from SwiftNIO
* Remove scripts and docker files which are no longer needed
### Result:
Feature parity with old CI.
### Motivation:
`LineBasedFrameDecoder.decodeLast` throws an error if there is more than
one frame’s worth of bytes remaining in the buffer.
This is in violation of the `NIOSingleStepByteToMessageDecoder`protocol
requirement that this method be called in a loop until all bytes are
decoded.
### Modifications:
* The method now only throws if the decode operation could not return a
frame and there are bytes left in the buffer (previously only the latter
criterion applied).
* Method documentation is updated.
* Test added.
### Result:
`LineBasedFrameDecoder.decodeLast` can cope with more edge cases.
Co-authored-by: Rick Newton-Rogers <rnro@apple.com>
* Added support for conditional response compression
* Updated expectations to be fulfilled via a defer
* Updated compression response predicate to return an intent enum rather than a boolean
Motivation:
`NIOHTTPDecompression` erroneously accumulates decompressed data sizes across multiple requests in a single channel, leading to unwarranted `DecompressionError.limit` errors. This affects applications using persistent connections, as the decompression limits are improperly enforced. This change aims to address and rectify this issue.
Modifications:
- Add initialization of `inflated` within `Decompressor.initializeDecoder`.
- Introduced new tests to validate decompression functionality across multiple requests on the same channel
Result:
This fix ensures each request's decompression size is independently considered, eliminating incorrect limit errors, and enhancing reliability for applications using HTTP compression with persistent connections.
Motivation:
The NIOPCAPRingBuffer can limit the number of fragment or the total
number of bytes in its buffer or both. When configuring the buffer to
limit only the maximum number of bytes it sets the maximum number of
fragments allowed to `.max`. On `init` the buffer has enough capacity
reserved to store tha maximum number of fragments.
This would be a large and potentially totally unnecessary allocation.
That is, if it didn't crash at runtime. It crashes at runtime as
`CircularBuffer` converts the requested capacity to a `UInt32` which
traps if you pass it an `Int.max`.
Modifications:
- Don't reserve capacity on init
- Adjust the test which tests the byte limit to not set a capacity as
well
Result:
- `NIOPCAPRingBuffer(maximumBytes:)` doesn't crash
* Add HTTP types adapter for SwiftNIO
* swiftformat
* Guard on Swift 5.8
* Review comments
* Update swift-http-types to 0.1.1
* Update swift-http-types to 1.0.0
* Review feedback
* Review feedback
* Bump minimum Swift version to 5.7.1
* Allow Host in any order
Motivation:
Now that Swift 5.9 is GM we should update the supported versions and
remove 5.6
Modifications:
* Update `Package.swift`
* Remove `#if swift(>=5.7)` guards
* Delete the 5.6 docker compose file and make a 5.10 one
* Update docs
Result:
Remove support for Swift 5.6, add 5.10
Motivation
Per SwiftNIO's formal version policy, we are ready to drop support for
Swift 5.5.
Modifications
This patch removes the support for 5.5 and all supporting
infrastructure. This includes the test generation functionality, which
is no longer required, as well as the files generated by that
functionality. It updates the dockerfile for 5.8, and it removes all
conditional compilation checks that are now definitionally true.
Result
A nice, clean, 5.6+ codebase
Motivation
syncClose will block whatever thread it's on indefinitely. That makes it
unsafe to call in async contexts.
Modifications
Add a new close() method that's async.
Make the existing method unavailable from async.
Add some tests.
Results
Easier to close these from async contexts
# Motivation
Currently the `QuiescingHelper` is crashing on a precondition if you call shutdown when it already was shutdown. However, that can totally happen and we should support it.
# Modification
Refactor the `QuiescingHelper` to exhaustively switch over its state in every method. Furthermore, I added a few more test cases to test realistic scenarios.
# Result
We are now reliable checking our state and making sure to allow most transitions.
* ServerQuiescingHelper no longer leaking promises
Motivation:
ServerQuiescingHelper leaked promises when promise left scope and not succeeded
Modifications:
Failing promise within a deinit
* Minor fixes
* generating linux tests
* mini update
Motivation:
Moving the HTTP1ProxyConnectHandler into swift-nio-extras will make the
code which is generally useful when dealing with HTTP1 proxies available
more easily to a wider audience.
Modifications:
The code and tests are copied over from 0b5bec741b/Sources/AsyncHTTPClient/ConnectionPool/ChannelHandler/HTTP1ProxyConnectHandler.swift.
Result:
HTTP1ProxyConnectHandler will be surfaced via the NIOExtras library
Motivation
Currently we don't confirm that the decompression has completed
successfully. This means that we can incorrectly spin forever attempting
to decompress past the end of a message, and that we can fail to notice
that a message is truncated. Neither of these is good.
Modifications
Propagate the message zlib gives us as to whether or not decompression
is done, and keep track of it.
Add some tests written by @vojtarylko to validate the behaviour.
Result
Correctly police the bounds of the messages.
Resolves#175 and #176.
Motivation:
An index page ties all the other documentation together
Modifications:
Add index pages for the library targets.
Correct a few minor errors in the main docs.
Result:
A more joined up documentation experience.
* Improve documentation for NIOExtras
Motivation:
Docs will help users do things correctly.
Modifications:
Add missing comments, improve links.
Result:
Better docc documentation
* Docc in NIOHTTPCompression
* NIOSOCKS docc
* Correct bad symbol
* Minor typo
Co-authored-by: Cory Benfield <lukasa@apple.com>
