7995afee8f
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. |
||
|---|---|---|
| .github | ||
| all | ||
| bom | ||
| buffer | ||
| codec | ||
| codec-dns | ||
| codec-haproxy | ||
| codec-http | ||
| codec-http2 | ||
| codec-memcache | ||
| codec-mqtt | ||
| codec-redis | ||
| codec-smtp | ||
| codec-socks | ||
| codec-stomp | ||
| codec-xml | ||
| common | ||
| dev-tools | ||
| example | ||
| handler | ||
| handler-proxy | ||
| license | ||
| microbench | ||
| resolver | ||
| resolver-dns | ||
| tarball | ||
| testsuite | ||
| testsuite-autobahn | ||
| testsuite-osgi | ||
| transport | ||
| transport-native-epoll | ||
| transport-native-kqueue | ||
| transport-native-unix-common | ||
| transport-native-unix-common-tests | ||
| transport-rxtx | ||
| transport-sctp | ||
| transport-udt | ||
| .fbprefs | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| pom.xml | ||
| README.md | ||
| run-example.sh | ||
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:
- Latest stable Oracle JDK 7
- Latest stable Apache Maven
- If you are on Linux, you need additional development packages installed on your system, because you'll build the native transport.
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
Development of all versions takes place in each branch whose name is identical to <majorVersion>.<minorVersion>. For example, the development of 3.9 and 4.0 resides in the branch '3.9' and the branch '4.0' respectively.