### Motivation:
There will be times when a client wishes to send larger requests with gzipped bodies to save on network traffic. This PR adds a `NIOHTTPRequestDecompressor` which can be added to the server's channel pipeline so those requests are automatically inflated.
### Modifications:
- Added a `CNIOExtrasZlib_voidPtr_to_BytefPtr` C method.
- Added a `NIOHTTPRequestDecompressor` type.
- Added a `HTTPResponseDecompressorTest` test case.
### Result:
Now you don't have to manually check the `Content-Encoding` header and decompress the body on each incoming request.
* extract common classes for server request decompressor
* review fix: make fields private and make state part of the handler
* review fixes
* review fix: reserve capacity before inflating
### Motivation:
Many HTTP servers can send compressed responses to clients and it would be a great feature for `AsyncHTTPClient` to support it. But since we want to minizime usage of unsafe APIs in SSWG projects, I propose to consolidate interfacing with zlib to `nio-extras` since it already supports `zlib` compression.
### Modifications:
Added `HTTPResponseDecompressor` and accompanying tests
### Result:
Users (primarily `AsyncHTTPClient`) can now provide automatic response decompression support.
Motivation:
ServerQuiescingHelper used to swallow close errors and it shoulnd't do
that.
Modifications:
Don't swallow close errors.
Result:
More correctness.
Motivation:
Use B2MDVerifier for the B2MDs in NIOExtras. Already found one bug,
separetely fixed in #51.
Modifications:
Write a basic validation test for all B2MDs.
Result:
Better test coverage.
Motivation:
The script to generate a podspec used the minimum platform versions for
NIOTS instead of NIO.
Modifications:
Lower the minimum platform version to match those supported by NIO.
Result:
Larger Cocoapods platform support.
Motivation:
JSPN-RPC uses various framing methods, one is Content-Length based
framing. NIOExtras should provide encoder/decoders for this.
Modifications:
Add such codecs.
Result:
NIOExtras more useful
Motivation:
LineBasedFrameDecoder previously would only correctly decode \r\n as a
line-ending iff \r\n were not split apart.
Modifications:
Handle \r\n arriving apart.
Result:
more correct line splitting
Motivation:
README has an overview with the handlers that NIOExtras provides, some
were missing.
Modifications:
Add the missing ones.
Result:
Better README.
Motivation:
Especially with TLS but also without, in real production environments it
can be handy to be able to write pcap files from NIO directly.
Modifications:
add a ChannelHandler that can write a PCAP trace from what's going on in
the ChannelPipeline.
Result:
easier debugging in production
Motivation:
LineBasedFrameDecoder discarded everything after EOF and delivered it in
the left-over bytes error. For the real world however that doesn't make
much sense, you'd want all previously received lines and only receive
the partial lines as left-overs.
Modifications:
deliver lines until there are only partial lines left, even in case of
EOF.
Result:
LineBasedFrameDecoder more useful
Fixing a broken link in the readme file.
Modifications:
A single character correction in the readme file.
Result:
Improved pedanticism and/or readability depending upon the readers perspective.
Motivation:
to tag versions, we shouldn't depend on `.branch("master")`
Modifications:
depend on swift-nio: 2.0.0-convergence.1
Result:
ready to soon tag the first version
Motivation:
HTTPResponseCompressor is trivially removable, so mark it.
Modifications:
make HTTPResponseCompressor implement RemovableChannelHandler
Result:
HTTPResponseCompressor can be removed
Motivation:
Currently, we crash if there's any left over bytes available because
LineBasedFrameDecoder modifies cumulationBuffer in a way that is
illegal.
Modifications:
stop modifying cumulationBuffer in an illegal way
Result:
fewer crashes
Motivation:
Frequently, people want to terminate their pipeline with a handler that
takes in requests & a promise and on receipt of the response just
fulfill that promise.
Modifications:
- add `RequestResponseHandler`
- remove outdated of contents from README.md
Result:
more useful handlers
Motivation:
Users may want to log all of inbound and/or outbound events
Modifications:
Add DebugInboundEventsHandler and DebugOutboundEventsHandler
Result:
Users can plug additional handlers into their pipeline for default printing of events or getting a hook with relevant information for their own logging mechanism.
Motivation:
To improve the visibility of recently added files.
Modifications:
Adds 3 files to the file list in README.md.
Includes additional contributor.
Result:
Easier to see the full project contents as the readme is more accurate.
* Adds a LengthFieldPrepender class to prepend the length onto a message.
This class is a type of byte to message encoder.
Motivation:
To encode a prepended length field on data so that messages of arbitrary size can be sent.
Can work as a pair with the ‘LengthFieldBasedFrameDecoder’.
Modifications:
Added ‘LengthFieldPrepender’
Added unit tests for ‘LengthFieldPrepender’ in ‘LengthFieldPrependerTest’
Updated the linux text files by running the script.
Result:
The length can now be easily prepended to any message.
Motivation:
ByteToMessageDecoder is extremely brittle, for example a reentrant call
into decodeLast will present the user with bytes that were previously
seen...
Modification:
Discard bytes in decodeLast
Result:
LengthFieldBasedFrameDecoder will work if close called from channelRead.
* Adds a basic LengthFieldBasedFrameDecoder
Motivation:
Adding a popular type of decoder that is useful in real-world situations, particularly when dealing with protocol buffers.
Modifications:
Added the decoder class, tests and linux test files.
Result:
The project now includes a basic length field based decoder which can be built upon.
Further header specification may be required but this version suits basic usage.
* Renames the class files for the frame decoders to match the class names.
Motivation:
Neatening of the project by ensuring file names match the contained class names.
Modifications:
5 file renames, 4 of which are test files.
Result:
Ruby hooks script ran with no changes.
No breaking changes.
The project is a little neater.
* Adds a line-based frame decoder that can split received buffers on line endings.
Motivation:
As per https://github.com/apple/swift-nio/issues/473
Modifications:
Added a new decoder (LineBasedFrameDecoder) that splits incoming buffers on line end characters.
Result:
Received buffers will be split on line end character(s) ('\n' or '\r\n'), with these characters
stripped in the resulting buffers.
Motivation:
Probably a hangover of using NIO's version as template.
Modifications:
Updated the repository URL where to open PR in CONTRIBUTING.md
Result:
"Please open a pull request at https://github.com/apple/swift-nio-extras"
Provide a decoder for frames with a fixed length.
Motivation:
This was motivated by the issue https://github.com/apple/swift-nio/issues/474 as a good first issue.
Modifications:
Implemented a FixedLengthFrameDecoder as well as tests.
Result:
Users can decode fixed length frames.
Motivation:
in SwiftPM it's either of these three formats
- from: "0.1.0"
- .exact("0.1.0")
- .upToNextMajor(from: "0.1.0")
and I messed up the last one (forgot the `from:`)
Modifications:
fixed Package.swift
Result:
recommended syntax actually works
Motivation:
As swift-nio-extras is new, we can require Swift 4.1 which will allow us
to CI less stuff and also won't compatibility stuff for 4.0 that nobody
uses anymore.
Modifications:
require Swift 4.1
Result:
shinier
Motivation:
It's better for users to depend on `.upToNextMinor` instead of `.exact`
versions and I previously forgot to mention the quiescing helper in
the readme.
Modifications:
- mention quiescing helper in readme
- recommend to depend on this package with `.upToNextMinor`
Result:
better readme
Motivation:
We need the docker setup for CI.
Modifications:
Added docker setup. Started with swift-nio's setup and then removed
everything that we don't need (test, http, echo, integration-tests).
Result:
We can move forward doing CI.
