Skip to content
代码片段 群组 项目
  1. 7月 09, 2020
    • root's avatar
    • Norman Maurer's avatar
      Correctly return NEED_WRAP if we produced some data even if we could not... · cb9d4a1e
      Norman Maurer 创作于
      Correctly return NEED_WRAP if we produced some data even if we could not consume any during SSLEngine.wrap(...) (#10396)
      
      Motivation:
      
      At the moment we may report BUFFER_OVERFLOW when wrap(...) fails to consume data but still prodce some. This is not correct and we should better report NEED_WRAP as we already have produced some data (for example tickets). This way the user will try again without increasing the buffer size which is more correct and may reduce the number of allocations
      
      Modifications:
      
      Return NEED_WRAP when we produced some data but not consumed any.
      
      Result:
      
      Fix ReferenceCountedOpenSslEngine.wrap(...) state machine
      cb9d4a1e
  2. 7月 08, 2020
  3. 7月 07, 2020
  4. 7月 06, 2020
    • Bennett Lynch's avatar
      Add option to HttpObjectDecoder to allow duplicate Content-Lengths (#10349) · 9557c88d
      Bennett Lynch 创作于
      Motivation:
      
      Since https://github.com/netty/netty/pull/9865 (Netty 4.1.44) the
      default behavior of the HttpObjectDecoder has been to reject any HTTP
      message that is found to have multiple Content-Length headers when
      decoding. This behavior is well-justified as per the risks outlined in
      https://github.com/netty/netty/issues/9861, however, we can see from the
      cited RFC section that there are multiple possible options offered for
      responding to this scenario:
      
      > If a message is received that has multiple Content-Length header
      > fields with field-values consisting of the same decimal value, or a
      > single Content-Length header field with a field value containing a
      > list of identical decimal values (e.g., "Content-Length: 42, 42"),
      > indicating that duplicate Content-Length header fields have been
      > generated or combined by an upstream message processor, then the
      > recipient MUST either reject the message as invalid or replace the
      > duplicated field-values with a single valid Content-Length field
      > containing that decimal value prior to determining the message body
      > length or forwarding the message.
      
      https://tools.ietf.org/html/rfc7230#section-3.3.2
      
      Netty opted for the first option (rejecting as invalid), which seems
      like the safest, but the second option (replacing duplicate values with
      a single value) is also valid behavior.
      
      Modifications:
      
      * Introduce "allowDuplicateContentLengths" parameter to
      HttpObjectDecoder (defaulting to false).
      * When set to true, will allow multiple Content-Length headers only if
      they are all the same value. The duplicated field-values will be
      replaced with a single valid Content-Length field.
      * Add new parameterized test class for testing different variations of
      multiple Content-Length headers.
      
      Result:
      
      This is a backwards-compatible change with no functional change to the
      existing behavior.
      
      Note that the existing logic would result in NumberFormatExceptions
      for header values like "Content-Length: 42, 42". The new logic correctly
      reports these as IllegalArgumentException with the proper error message.
      
      Additionally note that this behavior is only applied to HTTP/1.1, but I
      suspect that we may want to expand that to include HTTP/1.0 as well...
      That behavior is not modified here to minimize the scope of this change.
      9557c88d
    • feijermu's avatar
      Add detailed error message corresponding to the IndexOutOfBoundsException... · 7a05aa1c
      feijermu 创作于
      Add detailed error message corresponding to the IndexOutOfBoundsException while calling getEntry(...) (#10386)
      
      Motivation:
      `getEntry(...)` may throw an IndexOutOfBoundsException without any error messages.
      
      
      Modification:
      
      Add detailed error message corresponding to the IndexOutOfBoundsException while calling `getEntry(...)` in HpackDynamicTable.java.
      
      Result: 
      
      Easier to debug
      7a05aa1c
    • violetagg's avatar
      Do not report... · 9893ac72
      violetagg 创作于
      Do not report ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify as blocking call (#10387)
      
      Motivation:
      
      When BlockHound is installed,
      ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify
      is reported as blocking call.
      
      Modifications:
      
      Add allowBlockingCallsInside configuration for
      ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify
      
      Result:
      
      Fixes #10384
      9893ac72
    • feijermu's avatar
      Add unit test for HpackDynamicTable. (#10389) · a6084370
      feijermu 创作于
      Motivation:
      
      `HpackDynamicTable` needs some test cases to ensure bug-free.
      
      Modification:
      
      Add unit test for `HpackDynamicTable`.
      
      Result:
      
      Improve test coverage slightly.
      a6084370
  5. 7月 03, 2020
    • Norman Maurer's avatar
      Correctly include TLS1.3 ciphers in the enabled ciphersuites when using BoringSSL (#10388) · cbe238a9
      Norman Maurer 创作于
      Motivation:
      
      BoringSSL behaves differently then OpenSSL and not include any TLS1.3 ciphers in the returned array when calling SSL_get_ciphers(...). This is due the fact that it also not allow to explicit configure which are supported and which not for TLS1.3. To mimic the behaviour expected by the SSLEngine API we should workaround this.
      
      Modifications:
      
      - Add a unit test that verifies enabled protocols / ciphers
      - Add special handling for BoringSSL and tls1.3
      
      Result:
      
      Make behaviour consistent
      cbe238a9
  6. 7月 01, 2020
    • skyguard1's avatar
      Fix #10378,ResourceLeakDetectorFactory.newResourceLeakDetector(Class, int)... · 523dc5c2
      skyguard1 创作于
      Fix #10378,ResourceLeakDetectorFactory.newResourceLeakDetector(Class, int) ignores  sampling interval (#10383)
      
      Motivation:
      
      newResourceLeakDetector(...) did not correctly pass the samplingInterval parameter and so it was ignored.
      
      Modification:
      
      ResourceLeakDetectorFactory.newResourceLeakDetector(Class, int) use the second parameter as the sampling interval of the newly created ResourceLeakDetector.
      
      Result:
      
      Fixes #10378
      523dc5c2
  7. 6月 26, 2020
  8. 6月 25, 2020
    • Norman Maurer's avatar
      Ensure we feed all data to the SSLEngine during handshaking in our tests (#10373) · bd577ef5
      Norman Maurer 创作于
      Motivation:
      
      Due a bug in our test we may dropped data on the floor which are generated during handshaking (or slightly after). This could lead to corrupt state in the engine itself and so fail tests. This is especially true for TLS1.3 which generates the sessions on the server after the "actual handshake" is done.
      
      Modifications:
      
      Contine with wrap / unwrap until all data was consumed
      
      Result:
      
      Correctly feed all data to the engine during testing
      bd577ef5
  9. 6月 24, 2020
  10. 6月 23, 2020
    • Norman Maurer's avatar
      Expand ChannelPipeline javadocs to cover UnorderedThreadPoolEventExecutor (#10361) · e0dc0549
      Norman Maurer 创作于
      Motivation:
      
      Seems like some users are suprised by the behaviour of DefaultEventExecutor when used within the ChannelPipeline. We should clarify the semantics and also mention UnordedThreadPoolEventExecutor which may be more inline with their expectations
      
      Modifications:
      
      Add javadocs section about UnorderedThreadPoolEventExecutor and expand details for DefaultEventExecutor
      
      Result:
      
      Clarify sematics
      e0dc0549
    • feijermu's avatar
      Fix a javadoc mistake. (#10364) · 8b3abf3b
      feijermu 创作于
      Motivation:
      
      There exists a `javadoc` mistake in `HttpHeaderValues.java`.
      
      Modification:
      
      Just correct this `javadoc` mistake...
      8b3abf3b
  11. 6月 22, 2020
  12. 6月 12, 2020
    • 离诌's avatar
      version: remove Duplicating managed version (#10329) · 4dc6764d
      离诌 创作于
      Motivation:
      
      remove Duplicating managed version, cause it is already defined in the parent project.
      
      Modification:
      
      - origin 
      ```
      <dependency>
            <groupId>io.netty</groupId>
            <artifactId>netty-dev-tools</artifactId>
            <scope>test</scope>
            <version>${project.version}</version>
            <optional>true</optional>
      </dependency>
      
      <plugin>
              <groupId>org.codehaus.mojo</groupId>
              <artifactId>build-helper-maven-plugin</artifactId>
              <version>1.10</version>
      </plugin>
      ```
      
      - after modify
      
      ```
      <dependency>
            <groupId>io.netty</groupId>
            <artifactId>netty-dev-tools</artifactId>
            <scope>test</scope>
            <optional>true</optional>
      </dependency>
      
      <plugin>
              <groupId>org.codehaus.mojo</groupId>
              <artifactId>build-helper-maven-plugin</artifactId>
      </plugin>
      ```
      
      Result:
      
      remove Duplicating managed version
      4dc6764d
    • Bennett Lynch's avatar
      Consolidate HttpObjectDecoder default values into constants (#10344) · bcb62be6
      Bennett Lynch 创作于
      Motivation
      
      HttpObjectDecoder and its associated classes make frequent use of
      default values for maxInitialLineLength, maxHeaderSize, maxChunkSize,
      etc. Today, these defaults are defined in-line in constructors and
      duplicated across many classes. This repetition is more prone to error
      and inconsistencies.
      
      Furthermore, due to the current lack of builder support, if a user wants
      to change just one of these values (e.g., maxHeaderSize), they are also
      required to know and repeat the other default values (e.g.,
      maxInitialLineLength and maxChunkSize).
      
      The primary motivation for this change is as we are considering adding
      another constructor parameter (for multiple content length behavior),
      appending this parameter may require some users to have prior knowledge
      of the default initialBufferSize, and it would be cleaner to allow them
      to reference the default constant.
      
      Modifications
      
      * Consolidate the HttpObjectDecoder default values into public constants
      * Reference these constants where possible
      
      Result
      
      No functional change. Additional telescoping constructors will be easier
      and safer to write. Users may have an easier experience changing single
      parameters.
      bcb62be6
  13. 6月 05, 2020
    • Kareem Ali's avatar
      Motivation: (#10326) · b559711f
      Kareem Ali 创作于
      
      The current FLowControlHandler keeps a flag to track whether a read() call is pending.
      This could lead to a scenario where you call read multiple times when the queue is empty,
      and when the FlowControlHandler Queue starts getting messages, channelRead will be fired only once,
      when we should've fired x many times, once for each time the handlers downstream called read().
      
      Modifications:
      
      Minor change to replace the boolean flag with a counter and adding a unit test for this scenario.
      
      Result:
      
      I used TDD, so I wrote the test, made sure it's failing, then updated the code and re-ran the test
      to make sure it's successful after the changes.
      
      Co-authored-by: default avatarKareem Ali <kali@localhost.localdomain>
      b559711f
    • Andrey Mizurov's avatar
      Fix #10261 stomp can be chunked, so implement StompWebSocketFrameEncoder (#10274) · 714dd00a
      Andrey Mizurov 创作于
      Motivation:
      
      Current implementation `StompSubframeEncoder` can encode `StompFrame` into several separate chunks or encode separately `StompHeadersSubframe` and `StompContentSubframe`. But some client libraries (e.g. stomp.js) do not support aggregation.
      
      Modification:
      
      Add StompWebSocketFrameEncoder for integration between origin stomp suframe encoder and `ContinuationWebSocketFrame` to support  chunks on transport level.
      
      Result:
      
      Fixes #10261 
      714dd00a
    • Norman Maurer's avatar
      Update test to directly check for SslHandshakeTimeoutException (#10339) · 9a558f1b
      Norman Maurer 创作于
      Motivation:
      
      9b7e091b added a special SSLHandshakeException sub-class to signal handshake timeouts but we missed to update a testcase to directly assert the type of the exception.
      
      Modifications:
      
      Assert directly that SslHandshakeTimeoutException is used
      
      Result:
      
      Test cleanup
      9a558f1b
  14. 6月 04, 2020
  15. 6月 03, 2020
    • feijermu's avatar
      Fix a test case problem: testSwallowedReadComplete(...) may fail with an... · 21eb936d
      feijermu 创作于
      Fix a test case problem: testSwallowedReadComplete(...) may fail with an AssertionError sometimes. (#10313)
      
      Motivation:
      
      It seems that `testSwallowedReadComplete(...)` may fail with an AssertionError sometimes after my tests. The relevant stack trace is as follows:
      
      ```
      java.lang.AssertionError: expected:<IdleStateEvent(READER_IDLE, first)> but was:<null>
      	at org.junit.Assert.fail(Assert.java:88)
      	at org.junit.Assert.failNotEquals(Assert.java:834)
      	at org.junit.Assert.assertEquals(Assert.java:118)
      	at org.junit.Assert.assertEquals(Assert.java:144)
      	at io.netty.handler.flow.FlowControlHandlerTest.testSwallowedReadComplete(FlowControlHandlerTest.java:478)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:498)
      	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
      	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
      	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
      	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
      	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
      	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
      	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
      	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
      	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
      	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
      	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
      	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
      	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
      	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
      	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
      	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
      	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
      	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:542)
      	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:770)
      	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:464)
      	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210)
      
      ```
      Obviously the `readerIdleTime` of `IdleStateHandler` and the thread sleep time before `EmbeddedChannel.runPendingTasks` are both 100ms. And if `userEvents.poll()` happened before `userEvents.add(...)` or no `IdleStateEvent` fired at all, this test case would fail.
      
      Modification:
      
      Sleep for a little more time before running all pending tasks in the `EmbeddedChannel`.
      
      Result:
      
      Fix the problem of small probability of failure.
      21eb936d
  16. 6月 02, 2020
    • Lin Gao's avatar
      More values other than chunked defined in Transfer-Encoding header leads to decode failure (#10321) · de134da7
      Lin Gao 创作于
      Motivation:
      
      `containsValue()` will check if there are multiple values defined in the specific header name, we need to use this method instead of `contains()` for the `Transfer-Encoding` header to cover the case that multiple values defined, like: `Transfer-Encoding: gzip, chunked`
      
      Modification:
      
      Change from `contains()` to `containsValue()` in `HttpUtil.isTransferEncodingChunked()` method.
      
      Result:
      
      Fixes #10320
      de134da7
    • Andrey Mizurov's avatar
      Set (and override) reserved websocket handshake response headers after custom... · 0dc94e49
      Andrey Mizurov 创作于
      Set (and override) reserved websocket handshake response headers after custom to avoid duplication (#10319)
      
      Motivation:
      Currently we passing custom websocket handshaker response headers to a `WebSocketServerHandshaker` but they can contain a reserved headers (e.g. Connection, Upgrade, Sec-Websocket-Accept) what lead to duplication because we use response.headers().add(..) instead of response.headers().set(..).
      
      Modification:
      In each `WebSocketServerHandshaker00`, ... `WebSocketServerHandshaker13` implementation replace the method add(..) to set(..) for reserved response headers.
      
      Result:
      
      Less error-prone
      0dc94e49
    • Josef Grieb's avatar
      Update GraalVM with JDK 8 and add GraalVM with JDK 11 (#10333) · 18bdfd9c
      Josef Grieb 创作于
      Motivation:
      
      A new GraalVM with JDK 11 was released and GraalVM adds Java 11 support
      
      Modification:
      
      - Update GraalVM JDK 8 version
      - Add GraalVM JDK 11 support
      
      Result:
      
      Build with GraalVM JDK 11 and use latest GraalVM JDK 8 version
      18bdfd9c
    • Norman Maurer's avatar
      Include more details if we throw an IllegalArgumentException because of overflow (#10330) · 6e0d2233
      Norman Maurer 创作于
      Motivation:
      
      We should include as much details as possible when throwing an IllegalArgumentException because of overflow in CompositeByteBuf
      
      Modifications:
      
      Add more details and factor out check into a static method to share code
      
      Result:
      
      Make it more clear why an operations failed
      6e0d2233
    • Scott Mitchell's avatar
      SslHandler#wrap to preserve exception if SSLEngine is closed (#10327) · bc943808
      Scott Mitchell 创作于
      Motivation:
      SslHandler currently throws a general SSLException if a wrap attempt
      fails due to the SSLEngine being closed. If writes are queued the
      failure rational typically requires more investigation to track down the
      original failure from a previous event. We may have more informative
      rational for the failure and so we should use it.
      
      Modifications:
      - SslHandler#wrap to use failure information from the handshake or prior
      transport closure if available
      
      Result:
      More informative exceptions from SslHandler#wrap if the SSLEngine has
      been previously closed.
      bc943808
  17. 5月 25, 2020
  18. 5月 20, 2020
  19. 5月 19, 2020
    • feijermu's avatar
      Dequeue all cached messages and destroy the queue instance after removing the... · f66412c8
      feijermu 创作于
      Dequeue all cached messages and destroy the queue instance after removing the FlowControlHandler from channel pipeline. (#10304)
      
      Motivation:
      
      The `FlowControlHandler` may cache the received messages in a queue in order to do the flow control. However, if this handler is manually removed from pipeline during runtime, those cached messages might not be passed to the next channel handler forever.
      
      Modification:
      
      Dequeue all these cached messages and call `ChannelHandlerContext.fireChannelRead(...)` in `handlerRemoved(...)` method.
      
      Result:
      Avoid losing the received messages.
      f66412c8
  20. 5月 18, 2020
  21. 5月 15, 2020
    • Robert Varga's avatar
      Include aarch64 packages in netty-bom (#10292) · bdbf68f9
      Robert Varga 创作于
      
      
      Motivation:
      
      The linux-aarch64 packages are not declared in netty-bom. There are no consistency checks for netty bom, hence it can easily miss updates when artifacts are added.
      
      Modifications:
      
      - Add declarations.
      - Modify netty-all to depend on netty-bom for version declarations,
      thus requiring netty-bom to be uptodate.
      
      Result:
      
      Be able to reference aarch64 packages without an explicit version. The content of netty-all is guaranteed to be declared in netty-bom, adding a safety net.
      
      Signed-off-by: default avatarRobert Varga <robert.varga@pantheon.tech>
      bdbf68f9
    • sanjaypujare's avatar
      Make ReferenceCountedOpenSslContext.setUseTasks public (#10289) · 20b8685c
      sanjaypujare 创作于
      Motivation:
      make the existing setter `ReferenceCountedOpenSslContext.setUseTasks` public
      
      Modification:
      
      Added the `public` qualified and removed the comment "for tests only"
      
      Result:
      
      Fixes #10288  
      20b8685c
    • Norman Maurer's avatar
      Respect jdk.tls.client.enableSessionTicketExtension and... · 69db5bff
      Norman Maurer 创作于
      Respect jdk.tls.client.enableSessionTicketExtension and jdk.tls.server.enableSessionTicketExtension when using native SSL impl (#10296)
      
      Motivation:
      
      We should respect jdk.tls.client.enableSessionTicketExtension and jdk.tls.server.enableSessionTicketExtension when using the native SSL implementation as well to make the usage of it easier and more consistent. These properties were introduced by JDK13:
      
      https://seanjmullan.org/blog/2019/08/05/jdk13
      
      Modifications:
      
      Check if the properties are set to true and if so enable tickets
      
      Result:
      
      Easier to enable tickets and be more consistent
      69db5bff
    • Norman Maurer's avatar
      Guard against re-entrancy issues while draining AbstractCoalescingBufferQueue (#10294) · 75df58a7
      Norman Maurer 创作于
      Motivation:
      
      AbstractCoalescingBufferQueue had a bug which could lead to an empty queue while still report bytes left. This was due the fact that we decremented the pending bytes before draining the queue one-by-one. The problem here is that while the queue is drained we may notify the promise which may add again buffers to the queue for which we never decrement the bytes while we drain these
      
      Modifications:
      
      - Decrement the pending bytes every time we drain a buffer from the queue
      - Add unit tests
      
      Result:
      
      Fixes https://github.com/netty/netty/issues/10286
      75df58a7
加载中