__Motivation__
Since request.headers().getAll() will never return null. And the check null condition will not work as expected.
__Modification__
Add isEmpty() checking as well.
__Result__
Fixes#11568
Motivation:
The MacOS-specific `connectx(2)` system call make it possible to establish client-side connections with TCP FastOpen.
Modification:
Add support for TCP FastOpen to the KQueue transport, and add the `connectx(2)` system call to `BsdSocket`.
Result:
It's now possible to use TCP FastOpen when initiating connections on MacOS.
Motivation:
This test is inherently flaky due to file descriptor reuse.
Even though we have taken steps to make it less flaky, it still fails sometimes.
When it does, the error message is not very helpful.
Modification:
Make use of assertThrows and assertThat to get more descriptive error messages when the tests fail.
Result:
More meaningful messages on test failures, which may help us make the tests more resilient in the future
Motivation:
There are lots of redundant variable declarations which should be inlined to make good look better.
Modification:
Made variables inlined.
Result:
Less redundant variable and more readable code.
Motivation:
TCP FastOpen is a pure optimisation, that is opportunistically applied.
There is no reason to make it specific to the epoll transport, and in the future we could add support to other transports.
Besides, the client-side equivalent, TCP_FASTOPEN_CONNECT, is already transport agnostic.
Modification:
Move the TCP_FASTOPEN channel option from EpollChannelOption to ChannelOption.
Mark the field in EpollChannelOption as deprecated.
Result:
All channel options related to TCP FastOpen are now transport agnostic.
However, we still only actually support TFO on the epoll transport.
Motivation:
io.netty.http2.validateContentLength SystemProperty was added as a way
to opt-out for compabitility for libraries/applications that violated
the RFC's content-length matching requirements [1] but have not yet been
fixed. This SystemProperty has been around for a few months now and it
is assumed these issues have now been addressed in 3rd party code.
[1] https://tools.ietf.org/html/rfc7540#section-8.1.2.6
Modifications:
- Remove the io.netty.http2.validateContentLength SystemProperty,
preventing folks from opting out of RFC's required content-length
matching.
Result:
No more escape hatch in H2 for content-length matching enforcement.
Motivation:
We should make variables `final` which are not reinstated again in code to match the code style and makes the code look better.
Modification:
Made couples of variables as `final`.
Result:
Variables marked as `final`.
Motivation:
We should keep bitwise operations simple and easy to understand.
Modification:
Simplify few Bitwise operations.
Result:
Less complicated bitwise operation code
Motivation:
We cannot control when "the system" reuses file descriptors.
This makes any test that assert on the behaviour of closed file descriptors inherently racy.
Modification:
Allow the EpollSocketChannelConfigTest socketoption tests a few tries to get the correct assertion on the behaviour of closed socket file descriptors.
Result:
The EpollSocketChannelConfigTest should now be much less flaky.
Motivation:
We should get rid of the unnecessary toString calls because they're redundant in nature.
Modification:
Removed unnecessary toString calls.
Result:
Better code
Motivation:
We should get rid of unnecessary semicolons because they don't do anything in code.
Modification:
Removed unnecessary semicolons.
Result:
Better code
Motivation:
There are lots of imports which are unused. We should get rid of them to make the code look better,
Modification:
Removed unused imports.
Result:
No unused imports.
Motivation:
This bug could occasionally cause SSL handshakes to time out, because the server-side handshake would fail to resume its event loop.
Modification:
Async delegate SSL tasks now lower their NEED_TASK status after they have executed, but before they run their completion callback.
This is important because the completion callback could be querying the handshake status.
This could cause the task delegator thread and the event look to race.
If the event look queries the handshake status first, it might think that it still needs to delegate another task.
If this happens, the delegator find a null task, and then fail to resume the event loop, causing the handshake to stall.
Result:
This data race no longer causes handshake timeouts.
Motivation:
We need to ensure we call wrap as long as there is something left to be send to the remote peer in cases of non-application data (like for example alerts).
Modifications:
Check the pending data and based on it return NEED_WRAP even when the handshake was done.
Result:
Always produce alerts etc
Motivation:
We should have guards in place to check increment or decrement count in `ReferenceCountUtil`. Increment and Decrement counts must be a positive integer.
Modification:
Added `ObjectUtil#checkPositive` checks.
Result:
Prevent release due to invalid count.
Motivation:
We the build failed we should ensure we also include hs_err* files as it may have failed due a native crash
Modifications:
Adjust path matching to include hs_err as well
Result:
Easier to debug native crashes
Motivation:
There is no decoder and encoder for TCP based DNS.
Result:
- Added decoder and encoder
- Added tests
- Added example
Result:
Be able to decode and encode TCP based dns
Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Motivation:
Due a bug in the statemachine we produced an decoding error when the GZIP footer was fragmented in some cases
Modifications:
- Fix statemachine
- Add testcase
Result:
Correctly decode GZIP in all cases
Motivation:
Users may want to clear the cache manually. For this it should be possible to access it first.
Modifications:
Change the visibility to public
Result:
Be able to clear the cache manually. Related to https://github.com/netty/netty/issues/11519
Motivation:
At the moment FastLzFrameEncoder depends on the buffer type. This is not needed and may cause memory copies
Modifications:
Rewrite to be able to just act on the ByteBuf
Result:
Less memory copies
Motivation:
750d235 did introduce a change in ApplicationProtocolNegotiationHandler that let the handler buffer all inbound data until the SSL handshake was completed. Due of this change a user might get buffer data forever if the SslHandler is not in the pipeline but the ApplicationProtocolNegotiationHandler was added. We should better guard the user against this "missconfiguration" of the ChannelPipeline.
Modifications:
- Remove the ApplicationProtocolNegotiationHandler when no SslHandler is present when the first message was received
- Add unit test
Result:
No possible that we buffer forever
Motivation:
While its technical impossible that a chunk is larger than 64kb it still makes things easier to read and more robust to add some size checks to LzfDecoder.
Modifications:
Check the maximum length
Result:
More robust and easier to reason about code
Motivation:
We did observe that the mutal auth tests are flaky on windows when running on the CI. Let's disable these for now.
Modifications:
Disable mutual auth tests on windows
Result:
More stable build. Related to https://github.com/netty/netty/issues/11489
Motivation:
For the code pattern of `Object.wait(...)` in `io.netty.util.concurrent.DefaultPromise.await0(...)`, it's better to follow the recommended code pattern according to [Object.wait(...)'s doc](https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#wait()):
```
synchronized (obj) {
while (<condition does not hold>)
obj.wait();
... // Perform action appropriate to condition
}
```
Modification:
Change the `Object.wait(...)`'s code pattern in `io.netty.util.concurrent.DefaultPromise.await0(...)`.
Result:
The `Object.wait(...)`'s code pattern in `io.netty.util.concurrent.DefaultPromise.await0(...)` meets the Java doc.
Motivation:
SelfSignedCertificate generates EC/RSA key pair and this should be explicitly mentioned in JavaDoc. Currently, only "RSA" was mentioned not "EC".
Modification:
Changed RSA to EC/RSA
Result:
Correct JavaDoc
Motivation:
Brotli4j had some changes for performance improvements. So we should upgrade to the latest version of Brotli4j.
See https://github.com/hyperxpro/Brotli4j/pull/27
Modification:
Upgraded Broti4j from 1.4.2 to 1.5.0.
Result:
Up-to-date Broti4j library.
Motivation:
As the release of JDK17 is getting closer and there are ea builds already we should ensure we can actually build netty with it.
Modifications:
- Add profile for JDK17
- Remove test-code that would fail with JDK17 due the changes in 4f4d0f5366.
Result:
Be able to build and run testsuite with JDK17
Motivation:
japicmp did fix some issues related to Java16+. Let's update so we can also enable it in later java versions
Modifications:
Update to 0.15.3
Result:
Be able to use japicmp with all java versions
Motivation:
FastLzFrameDecoder currently not use the allocator to alocate the output buffer. This means that if you use the PooledByteBufAllocator you still can't make use of the pooling. Beside this the decoder also does an uncessary memory copy when no compression is used.
Modifications:
- Allocate the output buffer via the allocator
- Don't allocate and copy if we handle an uncompressed chunk
- Make use of ByteBufChecksum for a few optimizations when running on a recent JDK
Result:
Less allocations when using FastLzFrameDecoder
Motivation:
There is no test case of `StringDecoder` here
Modification:
Need to add `StringDecoder` test case
Result:
Added test case of `StringDecoder`
Signed-off-by: xingrufei <xingrufei@sogou-inc.com>
Co-authored-by: xingrufei <xingrufei@sogou-inc.com>
Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Motivation:
At the moment we not correctly propagate cancellation in some case when we use the PromiseNotifier.
Modifications:
- Add PromiseNotifier static method which takes care of cancellation
- Add unit test
- Deprecate ChannelPromiseNotifier
Result:
Correctly propagate cancellation of operation
Co-authored-by: Nitesh Kant <nitesh_kant@apple.com>
Motivation:
Chunks are splitted up into even smaller chunks when the underlying
buffer's readable bytes are less than the chunk size.
The underlying buffer can be smaller than a chunk size if:
- The chunk size is larger than the maximum plaintext chunk allowed by the TLS RFC,
see: io.netty.handler.ssl.SslHandler.MAX_PLAINTEXT_LENGTH.
- The chunk sizes are variable in size,
which may cause Netty guess a buffer size that is smaller than a chunk size.
Modification:
Create a variable in HttpObjectDecoder: ByteBuf chunkedContent
- Initialize chunkedContent in READ_CHUNK_SIZE with chunkSize as buffer size.
- In READ_CHUNKED_CONTENT write bytes into chunkedContent
- If the remaining chunk size is not 0 and toRead ==maxChunkSize,
create a chunk using the chunkedContent and add it to the output messages
before re-initializing chunkedContent with the remaining chunkSize as buffer size.
- If the remaining chunk size is not 0 and toRead != maxChunkSize,
return without adding any output messages.
- If the remaining chunk size is 0,
create a chunk using the chunkedContent and add it to the output messages;
set chunkedContent = null and fall-through.
Result:
Support chunk sizes higher than the underlying buffer's readable bytes.
Co-authored-by: Nitesh Kant <nitesh_kant@apple.com>
Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Motivation:
New versions of Bouncy Castle libraries are out and we should upgrade to them.
Modification:
Upgraded all Bouncy Castle libraries to the latest version.
Result:
The latest versions of Bouncy Castle libraries.
Motivation:
As suggested in [section 5.3.4 in http2 spec](https://datatracker.ietf.org/doc/html/rfc7540#section-5.3.4):
> When a stream is removed from the dependency tree, its dependencies can be moved to become dependent on the parent of the closed stream. The weights of new dependencies are recalculated by distributing the weight of the dependency of the closed stream proportionally based on the weights of its dependencies.
For example, we have stream A and B depend on connection stream with default weights (16), and stream C depends on A with max weight (256). When stream A was closed, we move stream C to become dependent on the connection stream, then we should distribute the weight of stream A to its children (only stream C), so the new weight of stream C will be 16. If we keep the weight of stream C unchanged, it will get more resource than stream B
Modification:
- distribute weight to its children when closing a stream
- add a unit test for the case above and fix other related unit tests
Result:
More spec-compliant and more appropriate stream reprioritization
Co-authored-by: Heng Zhang <zhangheng@imo.im>
Motivation:
The TLS handshake must be able to finish on its own, without being driven by outside read calls.
This is currently not the case when TCP FastOpen is enabled.
Reads must be permitted and marked as pending, even when a channel is not active.
This is important because, with TCP FastOpen, the handshake processing of a TLS connection will start
before the connection has been established -- before the process of connecting has even been started.
The SslHandler on the client side will add the Client Hello message to the ChannelOutboundBuffer, then
issue a `ctx.read` call for the anticipated Server Hello response, and then flush the Client Hello
message which, in the case of TCP FastOpen, will cause the TCP connection to be established.
In this transaction, it is important that the `ctx.read` call is not ignored since, if auto-read is
turned off, this could delay or even prevent the Server Hello message from being processed, causing
the server-side handshake to time out.
Modification:
Attach a listener to the SslHandler.handshakeFuture in the EchoClient, that will call ctx.read.
Result:
The SocketSslEchoTest now tests that the SslHandler can finish handshakes on its own, without being driven by 3rd party ctx.read calls.
The various channel implementations have been updated to comply with this behaviour.
