- 11月 09, 2017
-
-
由 Norman Maurer 创作于
Motivation: 93130b17 introduced a regression where we not "converted" an empty HttpContent to ByteBuf and just passed it on in the pipeline. This can lead to the situation that other handlers in the pipeline will see HttpContent instances which is not expected. Modifications: - Correctly convert HttpContent to ByteBuf when empty - Add unit test. Result: Handlers in the pipeline will see the expected message type.
-
由 Ning Sun 创作于
Motivation: There is an logic issue when checking if ChannelHandler is sharable. Modification: Corrected || to &&
- 11月 08, 2017
-
-
由 Carl Mastrangelo 创作于
Motivation: When looking for a leak, its nice to be able to request at least a number of leaks. Modification: * Made all leak records up to the target amoutn recorded, and only then enable backing off. * Enable recording more than 32 elements. Previously the shift amount made this impossible. Result: Ability to record all accesses.
-
由 Scott Mitchell 创作于
Motivation: AbstractCoalescingBufferQueue#add accounts for void promises, but AbstractCoalescingBufferQueue#addFirst does not. These methods should be consistent. Modifications: - AbstractCoalescingBufferQueue#addFirst should account for void promises and share code with AbstractCoalescingBufferQueue#add Result: More correct void promise handling in AbstractCoalescingBufferQueue.
-
由 Scott Mitchell 创作于
complete Motivation: SslHandler removes a Buffer/Promise pair from AbstractCoalescingBufferQueue when wrapping data. However it is possible the SSLEngine will not consume the entire buffer. In this case SslHandler adds the Buffer back to the queue, but doesn't add the Promise back to the queue. This may result in the promise completing immediately in finishFlush, and generally not correlating to the completion of writing the corresponding Buffer Modifications: - AbstractCoalescingBufferQueue#addFirst should also support adding the ChannelPromise - In the event of a handshake timeout we should immediately fail pending writes immediately to get a more accurate exception Result: Fixes https://github.com/netty/netty/issues/7378.
-
- 11月 07, 2017
-
-
由 Scott Mitchell 创作于
Motivation: For use cases that create headers, but do not need to modify them a read only variant of HttpHeaders would be useful and may be able to provide better iteration performance for encoding. Modifications: - Introduce ReadOnlyHttpHeaders that is backed by a flat array Result: ReadOnlyHttpHeaders exists for non-modifiable HttpHeaders use cases.
-
由 Norman Maurer 创作于
Motivation: We need to set readPending to false when we detect a EOF while issue a read as otherwise we may not unregister from the Selector / Epoll / KQueue and so keep on receving wakeups. The important bit is that we may even get a wakeup for a read event but will still will only be able to read 0 bytes from the socket, so we need to be very careful when we clear the readPending. This can happen because we generally using edge-triggered mode for our native transports and because of the nature of edge-triggered we may schedule an read event just to find out there is nothing left to read atm (because we completely drained the socket on the previous read). Modifications: Set readPending to false when EOF is detected. Result: Fixes [#7255].
-
由 Scott Mitchell 创作于
Motivation: SslHandler only supports ByteBuf objects, but will not release objects of other types. SslHandler will also not release objects if its internal state is not correctly setup. Modifications: - Release non-ByteBuf objects in write - Release all objects if the SslHandler queue is not setup Result: Less leaks in SslHandler.
-
由 Scott Mitchell 创作于
Motivation: HTTP/2 allows writes of 0 length data frames. However in some cases EMPTY_BUFFER is used instead of the actual buffer that was written. This may mask writes of released buffers or otherwise invalid buffer objects. It is also possible that if the buffer is invalid AbstractCoalescingBufferQueue will not release the aggregated buffer nor fail the associated promise. Modifications: - DefaultHttp2FrameCodec should take care to fail the promise, even if releasing the data throws - AbstractCoalescingBufferQueue should release any aggregated data and fail the associated promise if something goes wrong during aggregation Result: More correct handling of invalid buffers in HTTP/2 code.
-
由 Norman Maurer 创作于
This reverts commit 413c7c2c as it introduced an regression when edge-triggered mode is used which is true for our native transports by default. With 413c7c2c included it was possible that we set readPending to false by mistake even if we would be interested in read more.
-
- 11月 03, 2017
-
-
由 Norman Maurer 创作于
Motivation: 7995afee introduced a change that broke special handling of WebSockets 00. Modifications: Correctly delegate to super method which has special handling for WebSockets 00. Result: Fixes [#7362].
-
由 Scott Mitchell 创作于
Motivation: HttpObjectEncoder and MessageAggregator treat buffers that are not readable special. If a buffer is not readable, then an EMPTY_BUFFER is written and the actual buffer is ignored. If the buffer has already been released then this will not be correct as the promise will be completed, but in reality the original content shouldn't have resulted in any write because it was invalid. Modifications: - HttpObjectEncoder should retain/write the original buffer instead of using EMPTY_BUFFER - MessageAggregator should retain/write the original ByteBufHolder instead of using EMPTY_BUFFER Result: Invalid write operations which happen to not be readable correctly reflect failed status in the promise, and do not result in any writes to the channel.
-
由 Scott Mitchell 创作于
infinite loop Motivation: If SslHandler sets jdkCompatibilityMode to false and ReferenceCountedOpenSslEngine sets jdkCompatibilityMode to true there is a chance we will get stuck in an infinite loop if the peer sends a TLS packet with length greater than 2^14 (the maximum length allowed in the TLS 1.2 RFC [1]). However there are legacy implementations which actually send larger TLS payloads than 2^14 (e.g. OpenJDK's SSLSessionImpl [2]) and in this case ReferenceCountedOpenSslEngine will return BUFFER_OVERFLOW in an attempt to notify that a larger buffer is to be used, but if the buffer is already at max size this process will repeat indefinitely. [1] https://tools.ietf.org/html/rfc5246#section-6.2.1 [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d5a00b1e8f78/src/share/classes/sun/security/ssl/SSLSessionImpl.java#l793 Modifications: - Support TLS payload sizes greater than 2^14 in ReferenceCountedOpenSslEngine - ReferenceCountedOpenSslEngine should throw an exception if a BUFFER_OVERFLOW is impossible to rectify Result: No more infinite loop in ReferenceCountedOpenSslEngine due to BUFFER_OVERFLOW and large TLS payload lengths.
-
- 11月 02, 2017
-
-
由 Norman Maurer 创作于
Motivation: ReferenceCountedOpenSslEngine.rejectRemoteInitiatedRenegotiation() is called in a finally block to ensure we always check for renegotiation. The problem here is that sometimes we will already shutdown the engine before we call the method which will lead to an NPE in this case as the ssl pointer was already destroyed. Modifications: Check that the engine is not destroyed yet before calling SSL.getHandshakeCount(...) Result: Fixes [#7353].
-
由 Scott Mitchell 创作于
Motivation: Some SSLEngine implementations (e.g. ReferenceCountedOpenSslContext) support unwrapping/wrapping multiple packets at a time. The SslHandler behaves differently if the SSLEngine supports this feature, but currently requires that the constructor argument between the SSLEngine creation and SslHandler are coordinated. This can be difficult, or require package private access, if extending the SslHandler. Modifications: - The SslHandler should inspect the SSLEngine to see if it supports jdkCompatibilityMode instead of relying on getting an extra constructor argument which maybe out of synch with the SSLEngine Result: Easier to override SslHandler and have consistent jdkCompatibilityMode between SSLEngine and SslHandler.
-
- 11月 01, 2017
-
-
由 Norman Maurer 创作于
Motivation: We should ensure we only try to load the netty-tcnative version that was compiled for the architecture we are using. Modifications: Include architecture into native lib name. Result: Only load native lib if the architecture is supported.
-
- 10月 29, 2017
-
-
由 Janusz Dziemidowicz 创作于
Motivation: Linux kernel 4.11 introduced a new socket option, TCP_FASTOPEN_CONNECT, that greatly simplifies making TCP Fast Open connections on client side. Usually simply setting the flag before connect() call is enough, no more changes are required. Details can be found in kernel commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19f6d3f3 Modifications: TCP_FASTOPEN_CONNECT socket option was added to EpollChannelOption class. Result: Netty clients can easily make TCP Fast Open connections. Simply calling option(EpollChannelOption.TCP_FASTOPEN_CONNECT, true) in client bootstrap is enough (given recent enough kernel).
-
由 Piotr Kołaczkowski 创作于
This change allows to upgrade a plain HTTP 1.x connection to TLS according to RFC 2817. Switching the transport layer to TLS should be possible without removing HttpClientCodec from the pipeline, because HTTP/1.x layer of the protocol remains untouched by the switch and the HttpClientCodec state must be retained for proper handling the remainder of the response message, per RFC 2817 requirement in point 3.3: Once the TLS handshake completes successfully, the server MUST continue with the response to the original request. After this commit, the upgrade can be established by simply inserting an SslHandler at the front of the pipeline after receiving 101 SWITCHING PROTOCOLS response, exactly as described in SslHander documentation. Modifications: - Don't set HttpObjectDecoder into UPGRADED state if 101 SWITCHING_PROTOCOLS response contains HTTP/1.0 or HTTP/1.1 in the protocol stack described by the Upgrade header. - Skip pairing comparison for 101 SWITCHING_PROTOCOLS, similar to 100 CONTINUE, since 101 is not the final response to the original request and the final response is expected after TLS handshake. Fixes #7293.
-
由 Trask Stalnaker 创作于
Motivation: Fix NullPointerExceptions that occur when running netty-tcnative inside the bootstrap class loader. Modifications: - Replace loader.getResource(...) with ClassLoader.getSystemResource(...) when loader is null. - Replace loader.loadClass(...) with Class.forName(..., false, loader) which works when loader is both null and non-null. Result: Support running native libs in bootstrap class loader
-
- 10月 27, 2017
-
-
由 Scott Mitchell 创作于
Motivation: If a child channel's read is triggered outside the parent channel's read loop then it is possible a WINDOW_UPDATE will be written, but not flushed. If a child channel's beginRead processes data from the inboundBuffer and then readPending is set to false, which will result in data not being delivered if in the parent's read loop and more data is attempted to be delievered to that child channel. Modifications: - The child channel must force a flush if a frame is written as a result of reading a frame, and this is not in the parent channel's read loop - The child channel must allow a transition from dequeueing from beginRead into the parent channel's read loop to deliver more data Result: The child channel flushes data when reading outside the parent's read loop, and has frames delivered more reliably.
-
- 10月 25, 2017
-
-
由 Scott Mitchell 创作于
Motivation: readPending is currently only set to false if data is delivered to the application, however this may result in duplicate events being received from the selector in the event that the socket was closed. Modifications: - We should set readPending to false before each read attempt for all transports besides NIO. - Based upon the Javadocs it is possible that NIO may have spurious wakeups [1]. In this case we should be more cautious and only set readPending to false if data was actually read. [1] https://docs.oracle.com/javase/7/docs/api/java/nio/channels/SelectionKey.html That a selection key's ready set indicates that its channel is ready for some operation category is a hint, but not a guarantee, that an operation in such a category may be performed by a thread without causing the thread to block. Result: Notification from the selector (or simulated events from kqueue/epoll ET) in the event of socket closure. Fixes https://github.com/netty/netty/issues/7255
-
由 Lionel Li 创作于
Motivation: Http2StreamFrameToHttpObjectCodec was not properly encoding and decoding 100-Continue HttpResponse/Http2SettingsFrame properly. It was encoding 100-Continue FullHttpResponse as an Http2SettingFrame with endStream=true, causing the child channel to terminate. It was not decoding 100-Continue Http2SettingsFrame (endStream=false) as FullHttpResponse. This should be fixed as it would cause http2 child stream to prematurely close, and could cause HttpObjectAggregator to fail if it's in the pipeline. Modification: - Fixed encode() to properly encode 100-Continue FullHttpResponse as Http2SettingsFrame with endStream=false - Reject 100-Continue HttpResponse that are NOT FullHttpResponse - Fixed decode() to properly decode 100-Continue Http2SettingsFrame (endStream=false) as a FullHttpResponse - made Http2StreamFrameToHttpObjectCodec sharable so that it can b used among child streams within the same Http2MultiplexCodec Result: Now Http2StreamFrameToHttpObjectCodec should be properly handling 100-Continue responses.
-
由 Dmitry Minkovsky 创作于
Motivation: I am receiving a multipart/form_data upload from a Mailgun webhook. This webhook used to send parts like this: --74e78d11b0214bdcbc2f86491eeb4902 Content-Disposition: form-data; name="attachment-2"; filename="attached_�айл.txt" Content-Type: text/plain Content-Length: 32 This is the content of the file --74e78d11b0214bdcbc2f86491eeb4902-- but now it posts parts like this: --74e78d11b0214bdcbc2f86491eeb4902 Content-Disposition: form-data; name="attachment-2"; filename*=utf-8''attached_%D1%84%D0%B0%D0%B9%D0%BB.txt This is the content of the file --74e78d11b0214bdcbc2f86491eeb4902-- This new format uses field parameter encoding described in RFC 5987. More about this encoding can be found here. Netty does not parse this format. The result is the filename is not decoded and the part is not parsed into a FileUpload. Modification: Added failing test in HttpPostRequestDecoderTest.java and updated HttpPostMultipartRequestDecoder.java Refactored to please Netkins Result: Fixes: HttpPostMultipartRequestDecoder identifies the RFC 5987 format and parses it. Previous functionality is retained.
-
由 Carl Mastrangelo 创作于
Motivation: Phantom references are for cleaning up resources that were forgotten, which means they keep their referent alive. This means garbage is kept around until the refqueue is drained, rather than when the reference is unreachable. Modification: Use Weak References instead of Phantoms Result: More punctual leak detection.
-
由 Norman Maurer 创作于
Motivation: We can end up with a buffer leak if SSLEngine.wrap(...) throws. Modifications: Correctly release the ByteBuf if SSLEngine.wrap(...) throws. Result: Fixes [#7337].
-
- 10月 24, 2017
-
-
由 Ned Twigg 创作于
Motivation: Before this commit, it is impossible to access the path component of the URI before it has been decoded. This makes it impossible to distinguish between the following URIs: /user/title?key=value /user%2Ftitle?key=value The user could already access the raw uri value, but they had to calculate pathEndIdx themselves, even though it might already be cached inside QueryStringDecoder. Result: The user can easily and efficiently access the undecoded path and query.
-
由 Lionel Li 创作于
Motivation: Previously client Http2ConnectionHandler trigger a user event immediately when the HTTP/2 connection preface is sent. Any attempt to immediately send a new request could cause the server to terminate the connection, as it might not have received the SETTINGS frame from the client. Per RFC7540 Section 3.5, the preface "MUST be followed by a SETTINGS frame (Section 6.5), which MAY be empty." (https://tools.ietf.org/html/rfc7540#section-3.5) This event could be made more meaningful if it also indicates that the initial client SETTINGS frame has been sent to signal that the channel is ready to send new requests. Modification: - Renamed event to Http2ConnectionPrefaceAndSettingsFrameWrittenEvent. - Modified Http2ConnectionHandler to trigger the user event only if it is a client and it has sent both the preface and SETTINGS frame. Result: It is now safe to use the event as an indicator that the HTTP/2 connection is ready to send new requests.
-
由 Norman Maurer 创作于
Motivation: A regression was introduced in 86e653e0 which had the effect that the writability was not updated for a Channel while queueing data in the SslHandler. Modifications: - Factor out code that will increment / decrement pending bytes and use it in AbstractCoalescingBufferQueue and PendingWriteQueue - Add test-case Result: Channel writability changes are triggered again.
-
由 Norman Maurer 创作于
Ensure setting / getting the traffic class on an ipv4 only system works when using the native transport. Motivation: We tried to set IPV6 opts on an ipv4 only system and so failed to set / get the traffic opts. This resulted in a test-error when trying to compile netty on ipv4 only systems. Modifications: Use the correct opts depending on if the system is ipv4 only or not. Result: Be able to build and use on ipv4 only systems.
-
由 Nikolay Fedorovskikh 创作于
Motivation: Bug in capacity calculation: occurs auto convert to string instead of sum up. Modifications: Use `eventName.length()` in sum. Result: Less trash in logs.
-
由 Norman Maurer 创作于
Motivation: We should also enforce the handshake timeout on the server-side to allow closing connections which will not finish the handshake in an expected amount of time. Modifications: - Enforce the timeout on the server and client side - Add unit test. Result: Fixes [#7230].
-
由 Scott Mitchell 创作于
Motviation: DnsNameResolverContext#followCname attempts to build a query to follow a CNAME, but puts the original hostname in the DnsQuery instead of the CNAME hostname. This will result in not following CNAME redirects correctly. Result: - DnsNameResolverContext#followCname should use the CNAME instead of the original hostname when building the DnsQuery Result: More correct handling of redirect queries.
-
- 10月 23, 2017
-
-
由 Nikolay Fedorovskikh 创作于
Motivation: An `origin`/`sec-websocket-origin` header value in websocket client is filling incorrect in some cases: - Hostname is not converting to lower-case as prescribed by RFC 6354 (see [1]). - Selecting a `http` scheme when source URI has `wss`/`https` scheme and non-standard port. Modifications: - Convert uri-host to lower-case. - Use a `https` scheme if source URI scheme is `wss`/`https`, or if source scheme is null and port == 443. Result: Correct filling an `origin` header for WS client. [1] https://tools.ietf.org/html/rfc6454#section-4
-
由 Idel Pivnitskiy 创作于
Motivation: Use actual links to new locations of Protobuf repo and documentation to avoid problems when redirect will not work. Modification: Links in comments and all/pom.xml Result: Correct links to Protobuf resources
-
由 Norman Maurer 创作于
Motivation: We should add @SupressWarnings Modifications: Add annotations. Result: Less warnings
-
- 10月 22, 2017
-
-
由 Idel Pivnitskiy 创作于
Motivation: Objects of java.util.TreeMap or java.util.TreeSet will become non-Serializable if instantiated with Comparators, which are not also Serializable. This can result in unexpected and difficult-to-diagnose bugs. Modifications: Implements Serializable for all classes, which implements Comparator. Result: Proper Comparators which will not force collections to non-Serializable mode.
-
- 10月 21, 2017
-
-
由 Idel Pivnitskiy 创作于
Motivation: Even if it's a super micro-optimization (most JVM could optimize such cases in runtime), in theory (and according to some perf tests) it may help a bit. It also makes a code more clear and allows you to access such methods in the test scope directly, without instance of the class. Modifications: Add 'static' modifier for all methods, where it possible. Mostly in test scope. Result: Cleaner code with proper 'static' modifiers.
-
由 Nikolay Fedorovskikh 创作于
Motivation: Javadoc of the `ByteBufUtil#copy(AsciiString, int, ByteBuf, int, int)` is incorrect. Modifications: Fix it. Result: The description of the `#copy` method is not misleading.
-
由 Nikolay Fedorovskikh 创作于
Motivation: In the `ByteBufOutputStream` we can use an appropriate methods of `ByteBuf` to reduce calls of virtual methods and do not copying converting logic. Modifications: - Use an appropriate methods of `ByteBuf` - Remove redundant conversions (int -> byte, int -> char). - Use `ByteBuf#writeCharSequence` in the `writeBytes(String)'. Result: Less code duplication. A `writeBytes(String)` method is faster. No unnecessary conversions. More consistent and cleaner code.
-