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>
Motivation:
Publishing docs is a good thing.
Modifications:
Update Package.swift to allow docc documentation to be generated.
Result:
It is possible to generate docc docs.
Motivation:
Pods need to include all transitive dependencies in order
to work around https://github.com/apple/swift-nio/issues/2073.
We also ship a second library from this repo: NIOSOCKS which doesn't yet
have a pod published.
Modifications:
- Update the pod generation script
Result:
Pods include all transitive dependencies
As outlined in a [Swift forums post in November ’21](https://forums.swift.org/t/swiftnio-swift-version-support/53232), SwiftNIO will only support the latest non-patch Swift release and the 2 immediately prior non-patch versions.
- drop support for Swift 5.2 and 5.3.
- update CI for Swift 5.4 to run on bionic instead of focal to ensure that we still test bionic.
Motivation:
A clean build is good.
Modifications:
Make the warning string for debug mode a let constant.
Result:
No warning about concurrency safety.
Co-authored-by: Peter Adams <peteradamshc76@gmail.com>
Motivation:
The docs haven't been generated for a while.
See also: https://github.com/apple/swift-nio/pull/2013
Modifications:
- Add NIOSOCKS module
- Pass `--spm` flag to sourcekitten
- Update source location of sourcekitten
- Fix link to NIO docs
Result:
Docs build.
Motivation:
This SourceKitten submodule is not needed, and there isn't any
appropriate map, so it can't actually be initialized. This is breaking
adopters of swift-nio-extras.
Modifications:
- Delete the submodule.
Results:
Adopters can build again.
Motivation:
With NIO 2.32.0 we broke the core NIO module up into modules that split
apart the POSIX layer and the core abstractions. As a result, this
package no longer needs to express a hard dependency on the POSIX layer.
Modifications:
- Rewrote imports of NIO to NIOCore.
- Added NIOEmbedded and NIOPosix imports where necessary in tests.
- Extended soundness script to detect NIO imports.
- Note that the main modules still depend on NIO, which is necessary
for backwards-compatibility reasons. This dependency is unused.
Result:
No need to use NIOPosix.
motivation: fix ci
changes:
* only install ruby and jazzy on focal since jazzy id not supported onlder versions of ubuntu
* fix doc generations script adjusting it to latest source-kittent syntax
Changes made:
Removed CI config for 5.0 ad 5.1
Changed 5.2 to be based on 16.04 so we have some coverage there
Converted Package.swift to the latest syntax
Added a description to supported Swift versions in the README
* SOCKS handshake handler implementation
* Soundness
* Remove placeholder text
* Sad path tests
* Soundness
* Docs
* Fix workflow tests
* Make handler removable
* Protect methods
* Prevent test crashes
* Cleanup public types
* Add test that writing after auth fails
* Add force handler removal tests
* Remove client and server state from public api
* Explicitly handle states
* Remove promises
* Fix test
* Add data to authentication complete
* Refactor to add authentication complete flag
Implement a SOCKSv5 client according to RFC 1928. Server implementation will be added in another PR to keep sizes down.
https://datatracker.ietf.org/doc/html/rfc1928
A few meaningful changes:
Add all relevant types used across SOCKS clients and servers
Add a state machine used to manage a connection from a clients side
Add a channel handler that should be added at the very start of a channel pipeline
* fix crash in LengthFieldBasedFrameDecoder for malicious length values
Motivation:
LengthFieldBasedFrameDecoder will cause a fatal error if the length value does not fit into an `Int`.
This can happen if `lengthFieldLength` is set to `.eight` and we are on a 64 bit platform or if `lengthFieldLength` is set to `.four` and we are on a 32-bit platform.
If we then receive a length field value which is greater than `Int.max` the conversion from `UInt` to `Int` will cause a fatal error.
This could be abused to crash a server by only sending 4 or 8 bytes.
Modifications:
safely convert UInt64 & UInt32 to Int and throw an error if they can't be represented as an Int
Result:
- LengthFieldBasedFrameDecoder with lengthFieldLength set to `.eight` can no longer crash the server on a 64-bit platform
- LengthFieldBasedFrameDecoder with lengthFieldLength set to `.four` can no longer crash the server on a 32-bit platform
* use early exit instead of XCTSkipIf
* add support for `.eight` on 32-bit platforms
* limit frame length to `Int32.max`
* change test names
* throw correct error
* fix compilation for Swift 5.0 and add NIO prefix to error enum
* add test for maximum allowed length and one above the maximum allowed length
Signed-off-by: David Nadoba <dnadoba@gmail.com>
* run XCTest script
Signed-off-by: David Nadoba <dnadoba@gmail.com>
Co-authored-by: Johannes Weiss <johannesweiss@apple.com>
Motivation:
The RSocket protocol uses a 24 bit length field
Modifications:
- add two new methods readInteger and writeInteger on ByteBuffer that support reading and writing integers of any size.
- add a new case (.three) to ByteLength
Result:
LengthFieldBasedFrameDecoder & LengthFieldPrepender do now support a 24 bit length field
Co-authored-by: Johannes Weiss <johannesweiss@apple.com>
Motivation:
We support watchOS 6+ with SwiftNIO Transport Services; as such we should
include watchOS as a deployment target for our CocoaPods.
Modifications:
- Add a watchOS deployment target to `build_podspecs.sh`
Result:
Users can deploy to watchOS 6+ with CocoaPods.
Motivation:
As a rule of thumb we should always forward channel events to the next
handler. #106 added an implementation for `channelInactive` but forgot
to forward it.
Modifications:
- forward `channelInactive` in the `RequestResponseHandler`
Result:
Handlers after the `RequestResponseHandler` will recieve
`channelInactive`.
Motivation:
It's possible for channels to be closed without an error; and the
`RequestResponseHandler` should tolerate that by failing any promises
for which it does not have a response for.
Modifications:
- Add `ClosedBeforeReceivingResponseError`
- Fail outstanding promises with `ClosedBeforeReceivingResponseError` in
`RequestResponseHandler.channelInactive`
- Add a test.
Result:
Outstanding request promises are failed when the channel becomes inactive.
Motivation:
Current script always reports sdk errors on 5.2.
Modifications:
Only give -sdk where really necessary on 5.2 linux.
Result:
Script will work on 5.2 (although still reports silent errors)
