andreacavalli/netty5
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
5,696 Commits 27 Branches 234 Tags 84 MiB
Java 99.8%
Shell 0.1%
2c4aff13c7
Go to file
Trustin Lee 2c4aff13c7 Add an operation that resets the state of HttpObjectDecoder 
Motivation:

Currently, it is impossible to give a user the full control over what to do in response to the request with 'Expect: 100-continue' header.  Currently, a user have to do one of the following:

- Accept the request and respond with 100 Continue, or
- Send the reject response and close the connection.

.. which means it is impossible to send the reject response and keep the connection alive so that the client sends additional requests.

Modification:

Added a public method called 'reset()' to HttpObjectDecoder so that a user can reset the state of the decoder easily.  Once called, the decoder will assume the next input will be the beginning of a new request.

HttpObjectAggregator now calls `reset()`right after calling 'handleOversizedMessage()' so that the decoder can continue to decode the subsequent request even after the request with 'Expect: 100-continue' header is rejected.

Added relevant unit tests / Minor clean-up

Result:

This commit completes the fix of #2211
2014-02-20 13:41:54 -08:00
all Ensure native transport is included in all and tarball 2014-02-17 22:46:07 +01:00
buffer Determine the default allocator from system property 2014-02-14 13:04:12 -08:00
codec Fix resource leaks in ByteArrayEncoderTest 2014-02-16 11:50:09 -08:00
codec-http Add an operation that resets the state of HttpObjectDecoder 2014-02-20 13:41:54 -08:00
codec-memcache Deprecate CombinedChannelDuplexHandler in favor of ChannelHandlerAppender 2014-02-13 19:20:25 -08:00
codec-socks Update the version to 4.1.0.Alpha1-SNAPSHOT 2014-02-13 18:32:26 -08:00
common Fix a regression which could lead to GenericFutureListeners never been notifed. Part of [#2186]. 2014-02-20 15:13:25 +01:00
example Update the version to 4.1.0.Alpha1-SNAPSHOT 2014-02-13 18:32:26 -08:00
handler Do not use String.format() for log message generation 2014-02-13 19:31:17 -08:00
license Add back jzlib license file and notice 2013-02-21 14:00:59 -08:00
microbench Update JMH to 0.3.2 2014-02-14 13:16:13 -08:00
tarball Update the version to 4.1.0.Alpha1-SNAPSHOT 2014-02-13 18:32:26 -08:00
testsuite Update the version to 4.1.0.Alpha1-SNAPSHOT 2014-02-13 18:32:26 -08:00
transport Move marking ChannelPromise for writes uncancellable to addFlush for keep things simple 2014-02-17 16:16:08 +01:00
transport-native-epoll Correctly handle remove from epoll and EPOLLRDHUP. Also fix a bug with removing EPOLLIN and EPOLLOUT 2014-02-19 16:34:57 +01:00
transport-rxtx Update the version to 4.1.0.Alpha1-SNAPSHOT 2014-02-13 18:32:26 -08:00
transport-sctp Update the version to 4.1.0.Alpha1-SNAPSHOT 2014-02-13 18:32:26 -08:00
transport-udt Update the version to 4.1.0.Alpha1-SNAPSHOT 2014-02-13 18:32:26 -08:00
.fbfilter.xml Update license headers 2012-06-04 13:31:44 -07:00
.fbprefs Updated Find Bugs configuration 2009-03-04 10:33:09 +00:00
.gitignore Format and partially describe Gitignore 2013-12-10 07:04:38 +01:00
.travis.yml Travis CI branch whitelisting 2013-03-11 09:55:43 +09:00
LICENSE.txt Relicensed to Apache License v2 2009-08-28 07:15:49 +00:00
NOTICE.txt Add back jzlib license file and notice 2013-02-21 14:00:59 -08:00
pom.xml Introduce a native transport for linux using epoll ET 2014-02-15 22:44:56 +01:00
README.md Update README.md 2014-01-16 14:38:36 +09:00

README.md

Netty Project

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

Links

How to build

For the detailed information about building and developing Netty, please visit the developer guide. This page only gives very basic information.

You require the following to build Netty:

Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+) is enough to run your Netty-based application.

Branches to look

The 'master' branch is where the development of the latest major version lives on. The development of all other major versions takes place in each branch whose name is identical to its major version number. For example, the development of 3.x and 4.x resides in the branch '3' and the branch '4' respectively.