Commit Graph

646 Commits

Author SHA1 Message Date
Norman Maurer
cee38ed2b6 [maven-release-plugin] prepare for next development iteration 2016-03-29 16:45:13 +02:00
Norman Maurer
9cd9e7daeb [maven-release-plugin] prepare release netty-4.1.0.CR5 2016-03-29 16:44:33 +02:00
Eric Anderson
e24a5d8839 Map HTTP/2 Streams to Channels
Motivation:

This allows using handlers for Streams in normal Netty-style. Frames are
read/written to the channel as messages, not directly as a
callback/method call. Handlers allow mixing and can ease HTTP/1 and
HTTP/2 interoperability by eventually supporting HTTP/1 handlers in
HTTP/2 and vise versa.

Modifications:

New handler Http2MultiplexCodec that converts from the current HTTP/2
API to a message-based API and child channels for streams.

Result:

The basics are done for server-side: new streams trigger creation of new
channels in much the same appearance to how new connections trigger new
channel creation. The basic frames HEADERS and DATA are handled, but
also GOAWAY and RST_STREAM.

Inbound flow control is implemented, but outbound is not. That will be
done later, along with not completing write promises on the child
channel until the write actually completes on the parent.

There is not yet support for outbound priority/weight, push promises,
and many other features.

There is a generic Object that may be set on stream frames. This also
paves the way for client-side support which needs a way to refer to
yet-to-be-created streams (due to how HEADERS allocates a stream id, and
the allocation order must be the same as transmission order).
2016-03-25 12:14:44 -07:00
Norman Maurer
28d03adbfe [maven-release-plugin] prepare for next development iteration 2016-03-21 11:51:50 +01:00
Norman Maurer
4653dc1d05 [maven-release-plugin] prepare release netty-4.1.0.CR4 2016-03-21 11:51:12 +01:00
Sergey Polovko
68bbd4e966 Handle only those http requests that equal to adjusted websocket path
Motivation:

It will be easier to support websockets in server application by using WebSocketServerProtocolHandshakeHandler class and not reinvent its functionality. But currently it handles all http requests as if they were websocket handshake requests.

Modifications:

Check if http request path is equals to adjusted websocket path.
Fixed example of websocket server implementation.

Result:

WebSocketServerProtocolHandshakeHandler handles only websocket handshake requests.
2016-03-04 08:36:14 +01:00
Norman Maurer
ca443e42e0 [maven-release-plugin] prepare for next development iteration 2016-02-19 23:00:11 +01:00
Norman Maurer
f39eb9a6b2 [maven-release-plugin] prepare release netty-4.1.0.CR3 2016-02-19 22:59:52 +01:00
Xiaoyan Lin
36aa11937d ByteBuf for Key instead of String for codec-memcache
Motivation:

The key can be ByteBuf to avoid converting between ByteBuf and String. See #3689.

Modifications:

Replace the type of key with ByteBuf.

Result:

The type of key becomes ByteBuf.
2016-02-08 15:21:24 -08:00
Norman Maurer
75a2ddd61c [maven-release-plugin] prepare for next development iteration 2016-02-04 16:51:44 +01:00
Norman Maurer
7eb3a60dba [maven-release-plugin] prepare release netty-4.1.0.CR2 2016-02-04 16:37:06 +01:00
Norman Maurer
210ebe1354 Allow to specify tcnative artifactId and verion to allow run tests easily with different tcnative flavors
Motivation:

As we now can easily build static linked versions of tcnative it makes sense to run our netty build against all of them.
This helps to ensure our code works with libressl, openssl and boringssl.

Modifications:

Allow to specify -Dtcnative.artifactId= and -Dtcnative.version=

Result:

Easy to run netty build against different tcnative flavors.
2016-01-29 22:27:19 +01:00
Norman Maurer
a2732c6542 [#4755] Make WebSocketClientCompressionHandler @Sharable
Motivation:

WebSocketClientCompressionHandler is stateless so it should be @Sharable.

Modifications:

Add @Sharable annotation to WebSocketClientCompressionHandler, make constructor private and add static field to get the instance.

Result:

Less object creation.
2016-01-28 10:28:09 +01:00
Norman Maurer
1c417e5f82 [maven-release-plugin] prepare for next development iteration 2016-01-21 15:35:55 +01:00
Norman Maurer
c681a40a78 [maven-release-plugin] prepare release netty-4.1.0.CR1 2016-01-21 15:28:21 +01:00
Xiaoyan Lin
751ed6cc94 Avoid unnecessary boxing/unboxing
Motivation:

Boxing/unboxing can be avoided.

Modifications:

Use parseInt/parseLong to avoid unnecessary boxing/unboxing.

Result:

Remove unnecessary boxing/unboxing.
2016-01-08 17:38:20 +01:00
Trustin Lee
55af6f1552 Use jetty-alpn-agent to simplify pom.xml
Motivation:

We had to add a new profile for each OpenJDK/OracleJDK release to make
Maven choose the correct alpn-boot.jar and npn-boot.jar. As a result,
our pom.xml has a large number of `<profile/>` sections.

Modifications:

- Use jetty-alpn-agent, which chooses the correct alpn-boot.jar and
  npn-boot.jar automatically to remove all the nasty profile sections
  from pom.xml
  - Visit https://github.com/trustin/jetty-alpn-agent for more info

Result:

Cleaner pom.xml
2016-01-04 20:40:32 +01:00
Fabian Lange
619d82b56f Removed unused imports
Motivation:

Warnings in IDE, unclean code, negligible performance impact.

Modification:

Deletion of unused imports

Result:

No more warnings in IDE, cleaner code, negligible performance improvement.
2016-01-04 14:32:29 +01:00
Xiaoyan Lin
475d901131 Fix errors reported by javadoc
Motivation:

Javadoc reports errors about invalid docs.

Modifications:

Fix some errors reported by javadoc.

Result:

A lot of javadoc errors are fixed by this patch.
2015-12-27 08:36:45 +01:00
Norman Maurer
dc615ecaaf [#4212] Backport WebSocket Extension handlers for client and server.
Motivation:

We have websocket extension support (with compression) in old master. We should port this to 4.1

Modifications:

Backport relevant code.

Result:

websocket extension support (with compression) is now in 4.1.
2015-12-18 09:48:10 +01:00
Trustin Lee
b39380ad83 Revamp InboundHttp2ToHttpAdapter builder API
Related: #4572 #4574

Motivation:

Consistency in our builder API design

Modifications:

- Add AbstractInboundHttp2ToHttpAdapterBuilder
- Replace the old 'Builder's with InboundHttp2ToHttpAdapterBuilder and
  InboundHttp2ToHttpPriorityAdapterBuilder

Result:

Builder API consistency
2015-12-18 12:44:46 +09:00
Trustin Lee
412f719aa8 Extract the builder of CorsConfig to top level
Motivation:

Consistency in API design

Modifications:

- Deprecate CorsConfig.Builder and its factory methods
- Deprecate CorsConfig.DateValueGenerator
- Add CorsConfigBuilder and its factory methods
- Fix typo (curcuit -> circuit)

Result:

Consistency with other builder APIs such as SslContextBuilder and
Http2ConnectionHandlerBuilder
2015-12-18 12:38:44 +09:00
Trustin Lee
2202e8f967 Revamp the Http2ConnectionHandler builder API
Related: #4572

Motivation:

- A user might want to extend Http2ConnectionHandler and define his/her
  own static inner Builder class that extends
  Http2ConnectionHandler.BuilderBase. This introduces potential
  confusion because there's already Http2ConnectionHandler.Builder. Your
  IDE will warn about this name duplication as well.
- BuilderBase exposes all setters with public modifier. A user's Builder
  might not want to expose them to enforce it to certain configuration.
  There's no way to hide them because it's public already and they are
  final.
- BuilderBase.build(Http2ConnectionDecoder, Http2ConnectionEncoder)
  ignores most properties exposed by BuilderBase, such as
  validateHeaders, frameLogger and encoderEnforceMaxConcurrentStreams.
  If any build() method ignores the properties exposed by the builder,
  there's something wrong.
- A user's Builder that extends BuilderBase might want to require more
  parameters in build(). There's no way to do that cleanly because
  build() is public and final already.

Modifications:

- Make BuilderBase and Builder top-level so that there's no duplicate
  name issue anymore.
  - Add AbstractHttp2ConnectionHandlerBuilder
  - Add Http2ConnectionHandlerBuilder
  - Add HttpToHttp2ConnectionHandlerBuilder
- Make all builder methods in AbstractHttp2ConnectionHandlerBuilder
  protected so that a subclass can choose which methods to expose
- Provide only a single build() method
  - Add connection() and codec() so that a user can still specify
    Http2Connection or Http2Connection(En|De)coder explicitly
  - Implement proper state validation mechanism so that it is prevented
    to invoke conflicting setters

Result:

Less confusing yet flexible builder API
2015-12-17 14:08:13 +09:00
Norman Maurer
2ecce8fa56 [maven-release-plugin] prepare for next development iteration 2015-11-10 22:59:33 +01:00
Norman Maurer
6a93f331d3 [maven-release-plugin] prepare release netty-4.1.0.Beta8 2015-11-10 22:50:57 +01:00
Scott Mitchell
035053be4a HTTP/2 Client Example TLS Pipeline Initialization
Motivation:
The HTTP/2 client example is not validating the results of ALPN if TLS is enabled.

Modifications:
- Use ApplicationProtocolNegotiationHandler to validate ALPN results.

Result:
Client example validates ALPN results.
2015-11-07 10:15:20 -08:00
Norman Maurer
6ebf4d1f5b [#4347] Remove not needed write operation from example.
Motivation:

The proxy example contains some code that is not needed. This can confuse the reader.

Modifications:

Remove the not needed ctx.write(...).

Result:

Less confusing code.
2015-10-14 10:57:04 +02:00
Norman Maurer
2ff2806ada [maven-release-plugin] prepare for next development iteration 2015-10-02 09:03:29 +02:00
Norman Maurer
5a43de10f7 [maven-release-plugin] prepare release netty-4.1.0.Beta7 2015-10-02 09:02:58 +02:00
Scott Mitchell
284e3702d8 Http2ConnectionHandler Builder instead of constructors
Motivation:
Using the builder pattern for Http2ConnectionHandler (and subclasses) would be advantageous for the following reasons:
1. Provides the consistent construction afforded by the builder pattern for 'optional' arguments. Users can specify these options 1 time in the builder and then re-use the builder after this.
2. Enforces that the Http2ConnectionHandler's internals (decoder Http2FrameListener) are initialized after construction.

Modifications:
- Add an extensible builder which can be used to build Http2ConnectionHandler objects
- Update classes which inherit from Http2ConnectionHandler

Result:
It is easier to specify options and construct Http2ConnectionHandler objects.
2015-10-01 13:51:03 -07:00
Scott Mitchell
1485a87e25 Http2ConnectionHandler and Http2FrameListener cyclic dependency
Motivation:
It is often the case that implementations of Http2FrameListener will want to send responses when data is read. The Http2FrameListener needs access to the Http2ConnectionHandler (or the encoder contained within) to be able to send responses. However the Http2ConnectionHandler requires a Http2FrameListener instance to be passed in during construction time. This creates a cyclic dependency which can make it difficult to cleanly accomplish this relationship.

Modifications:
- Add Http2ConnectionDecoder.frameListener(..) method to set the frame listener. This will allow the listener to be set after construction.

Result:
Classes which inherit from Http2ConnectionHandler can more cleanly set the Http2FrameListener.
2015-09-30 15:41:15 -07:00
nmittler
3ee44a3dbb Update Netty to latest netty-tcnative
Motivation:

The latest netty-tcnative fixes a bug in determining the version of the runtime openssl lib.  It also publishes an artificact with the classifier linux-<arch>-fedora for fedora-based systems.

Modifications:

Modified the build files to use the "-fedora" classifier when appropriate for tcnative. Care is taken, however, to not change the classifier for the native epoll transport.

Result:

Netty is updated the the new shiny netty-tcnative.
2015-09-18 12:07:21 -07:00
Scott Mitchell
c7e3f6c6fd HTTP/2 defines using String instead of CharSequence
Motivation:
Http2CodecUtils has some static variables which are defined as Strings instead of CharSequence. One of these defines is used as a header name and should be AsciiString.

Modifications:
- Change the String defines in Http2CodecUtils to CharSequence

Result:
Types are more consistently using CharSequence and adding the upgrade header will require less work.
2015-09-16 14:55:33 -07:00
Scott Mitchell
1d4d5fe312 DefaultHttp2Headers should throw exception of type Http2Exception
Motivation:
The DefaultHttp2Headers code is throwing a IllegalArgumentException if an invalid character is detected. This is being ignored by the HTTP/2 codec instead of generating a GOAWAY.

Modifications:
- Throw a Http2Exception of type PROTOCOL_ERROR in accordance with https://tools.ietf.org/html/rfc7540#section-8.1.2.6
- Update examples which were building invalid headers

Result:
More compliant with https://tools.ietf.org/html/rfc7540#section-8.1.2.6
2015-09-16 13:47:05 -07:00
Norman Maurer
34de2667c7 [maven-release-plugin] prepare for next development iteration 2015-09-02 11:45:20 +02:00
Norman Maurer
2eb444ec1d [maven-release-plugin] prepare release netty-4.1.0.Beta6 2015-09-02 11:36:11 +02:00
Scott Mitchell
b6a4f5de9d Refactor of HttpUtil and HttpHeaderUtil
Motivation:
There currently exists http.HttpUtil, http2.HttpUtil, and http.HttpHeaderUtil. Having 2 HttpUtil methods can be confusing and the utilty methods in the http package could be consolidated.

Modifications:
- Rename http2.HttpUtil to http2.HttpConversionUtil
- Move http.HttpHeaderUtil methods into http.HttpUtil

Result:
Consolidated utilities whose names don't overlap.
Fixes https://github.com/netty/netty/issues/4120
2015-08-27 08:49:58 -07:00
Scott Mitchell
ba6ce5449e Headers Performance Boost and Interface Simplification
Motivation:
A degradation in performance has been observed from the 4.0 branch as documented in https://github.com/netty/netty/issues/3962.

Modifications:
- Simplify Headers class hierarchy.
- Restore the DefaultHeaders to be based upon DefaultHttpHeaders from 4.0.
- Make various other modifications that are causing hot spots.

Result:
Performance is now on par with 4.0.
2015-08-17 08:50:11 -07:00
Jakob Buchgraber
6fd0a0c55f Faster and more memory efficient headers for HTTP, HTTP/2, STOMP and SPYD. Fixes #3600
Motivation:

We noticed that the headers implementation in Netty for HTTP/2 uses quite a lot of memory
and that also at least the performance of randomly accessing a header is quite poor. The main
concern however was memory usage, as profiling has shown that a DefaultHttp2Headers
not only use a lot of memory it also wastes a lot due to the underlying hashmaps having
to be resized potentially several times as new headers are being inserted.

This is tracked as issue #3600.

Modifications:
We redesigned the DefaultHeaders to simply take a Map object in its constructor and
reimplemented the class using only the Map primitives. That way the implementation
is very concise and hopefully easy to understand and it allows each concrete headers
implementation to provide its own map or to even use a different headers implementation
for processing requests and writing responses i.e. incoming headers need to provide
fast random access while outgoing headers need fast insertion and fast iteration. The
new implementation can support this with hardly any code changes. It also comes
with the advantage that if the Netty project decides to add a third party collections library
as a dependency, one can simply plug in one of those very fast and memory efficient map
implementations and get faster and smaller headers for free.

For now, we are using the JDK's TreeMap for HTTP and HTTP/2 default headers.

Result:

- Significantly fewer lines of code in the implementation. While the total commit is still
  roughly 400 lines less, the actual implementation is a lot less. I just added some more
  tests and microbenchmarks.

- Overall performance is up. The current implementation should be significantly faster
  for insertion and retrieval. However, it is slower when it comes to iteration. There is simply
  no way a TreeMap can have the same iteration performance as a linked list (as used in the
  current headers implementation). That's totally fine though, because when looking at the
  benchmark results @ejona86 pointed out that the performance of the headers is completely
  dominated by insertion, that is insertion is so significantly faster in the new implementation
  that it does make up for several times the iteration speed. You can't iterate what you haven't
  inserted. I am demonstrating that in this spreadsheet [1]. (Actually, iteration performance is
  only down for HTTP, it's significantly improved for HTTP/2).

- Memory is down. The implementation with TreeMap uses on avg ~30% less memory. It also does not
  produce any garbage while being resized. In load tests for GRPC we have seen a memory reduction
  of up to 1.2KB per RPC. I summarized the memory improvements in this spreadsheet [1]. The data
  was generated by [2] using JOL.

- While it was my original intend to only improve the memory usage for HTTP/2, it should be similarly
  improved for HTTP, SPDY and STOMP as they all share a common implementation.

[1] https://docs.google.com/spreadsheets/d/1ck3RQklyzEcCLlyJoqDXPCWRGVUuS-ArZf0etSXLVDQ/edit#gid=0
[2] https://gist.github.com/buchgr/4458a8bdb51dd58c82b4
2015-08-04 17:12:24 -07:00
Scott Mitchell
a7f83aa23e HTTP/2 Example Needs FullHttpRequest
Motivation:
The HTTP/2 hello world example server should be expecting a FullHttpRequest when falling back to HTTP/1.x mode.

Modifications:
- HelloWorldHttp1Handler should process FullHttpRequestObjects
- Http2ServerInitializer should insert an HttpObjectAggregator into the pipeline if no upgrade was attempted

Result:
Responses from the HelloWorldHttp1Handler should only come after full HTTP requests are received.
2015-07-07 13:50:23 -07:00
Frederic Bregier
caa1505020 Get uploaded size while upload is in progress
Proposal to fix issue #3636

Motivations:
Currently, while adding the next buffers to the decoder
(`decoder.offer()`), there is no way to access to the current HTTP
object being decoded since it can only be available currently once fully
decoded by `decoder.hasNext()`.
Some could want to know the progression on the overall transfer but also
per HTTP object.
While overall progression could be done using (if available) the global
Content-Length of the request and taking into account each HttpContent
size, the per HttpData object progression is unknown.

Modifications:
1) For HTTP object, `AbstractHttpData` has 2 protected properties named
`definedSize` and `size`, respectively the supposely final size and the
current (decoded until now) size.
This provides a new method `definedSize()` to get the current value for
`definedSize`. The `size` attribute is reachable by the `length()`
method.

Note however there are 2 different ways that currently managed the
`definedSize`:
a) `Attribute`: it is reset each time the value is less than actual
(when a buffer is added, the value is increased) since the final length
is not known (no Content-Length)
b) `FileUpload`: it is set at startup from the lengh provided

So these differences could lead in wrong perception;
a) `Attribute`: definedSize = size always
b) `FileUpload`: definedSize >= size always

Therefore the comment tries to explain clearly the different behaviors.

2) In the InterfaceHttpPostRequestDecoder (and the derived classes), I
add a new method: `decoder.currentPartialHttpData()` which will return a
`InterfaceHttpData` (if any) as the current `Attribute` or `FileUpload`
(the 2 generic types), which will allow then the programmer to check
according to the real type (instance of) the 2 methods `definedSize()`
and `length()`.

This method check if currentFileUpload or currentAttribute are null and
returns the one (only one could be not null) that is not null.

Note that if this method returns null, it might mean 2 situations:
a) the last `HttpData` (whatever attribute or file upload) is already
finished and therefore accessible through `next()`
b) there is not yet any `HttpData` in decoding (body not yet parsed for
instance)

Result:
The developper has more access and therefore control on the current
upload.
The coding from developper side could looks like in the example in
HttpUloadServerHandler.
2015-06-12 14:16:07 +02:00
Trustin Lee
0ca65f1373 Lazily instantiate HttpServerUpgradeHandler.UpgradeCodec
Related: #3814

Motivation:

To implement the support for an upgrade from cleartext HTTP/1.1
connection to cleartext HTTP/2 (h2c) connection, a user usually uses
HttpServerUpgradeHandler.

It does its job, but it requires a user to instantiate the UpgradeCodecs
for all supported protocols upfront. It means redundancy for the
connections that are not upgraded.

Modifications:

- Change the constructor of HttpServerUpgradeHandler
  - Accept UpgraceCodecFactory instead of UpgradeCodecs
- The default constructor of HttpServerUpgradeHandler sets the
  maxContentLength to 0 now, which shouldn't be a problem because a
  usual upgrade request is a GET.
- Update the examples accordingly

Result:

A user can instantiate Http2ServerUpgradeCodec and its related objects
(Http2Connection, Http2FrameReader/Writer, Http2FrameListener, etc) only
when necessary.
2015-06-10 12:06:27 +09:00
Trustin Lee
73d79a4b3b Do not use hard-coded handler names in HTTP/2
Motivation:

Our HTTP/2 implementation sometimes uses hard-coded handler names when
adding/removing a handler to/from a pipeline. It's not really a good
idea because it can easily result in name clashes. Unless there is a
good reason, we need to use the reference to the handlers

Modifications:

- Allow null as a handler name for Http2Client/ServerUpgradeCodec
  - Use null as the default upgrade handler name
- Do not use handler name strings in some test cases and examples

Result:

Fixes #3815
2015-06-10 11:46:02 +09:00
Trustin Lee
0775089496 Replace SpdyOrHttpChooser and Http2OrHttpChooser with ApplicationProtocolNegotiationHandler
Motivation:

SpdyOrHttpChooser and Http2OrHttpChooser duplicate fair amount code with each other.

Modification:

- Replace SpdyOrHttpChooser and Http2OrHttpChooser with ApplicationProtocolNegotiationHandler
- Add ApplicationProtocolNames to define the known application-level protocol names

Result:

- Less code duplication
- A user can perform dynamic pipeline configuration that follows ALPN/NPN for any protocols.
2015-06-05 11:58:20 +09:00
Trustin Lee
afb46b926f Improve the API design of Http2OrHttpChooser and SpdyOrHttpChooser
Related: #3641 and #3813

Motivation:

When setting up an HTTP/1 or HTTP/2 (or SPDY) pipeline, a user usually
ends up with adding arbitrary set of handlers.

Http2OrHttpChooser and SpdyOrHttpChooser have two abstract methods
(create*Handler()) that expect a user to return a single handler, and
also have add*Handlers() methods that add the handler returned by
create*Handler() to the pipeline as well as the pre-defined set of
handlers.

The problem is, some users (read: I) don't need all of them or the
user wants to add more than one handler. For example, take a look at
io.netty.example.http2.tiles.Http2OrHttpHandler, which works around
this issue by overriding addHttp2Handlers() and making
createHttp2RequestHandler() a no-op.

Modifications:

- Replace add*Handlers() and create*Handler() with configure*()
- Rename getProtocol() to selectProtocol() to make what it does clear
- Provide the default implementation of selectProtocol()
- Remove SelectedProtocol.UNKNOWN and use null instead, because
  'UNKNOWN' is not a protocol
- Proper exception handling in the *OrHttpChooser so that the
  exception is logged and the connection is closed when failed to
  select a protocol
- Make SpdyClient example always use SSL. It was always using SSL
  anyway.
- Implement SslHandshakeCompletionEvent.toString() for debuggability
- Remove an orphaned class: JettyNpnSslSession
- Add SslHandler.applicationProtocol() to get the name of the
  application protocol
  - SSLSession.getProtocol() now returns transport-layer protocol name
    only, so that it conforms to its contract.

Result:

- *OrHttpChooser have better API.
- *OrHttpChooser handle protocol selection failure properly.
- SSLSession.getProtocol() now conforms to its contract.
- SpdyClient example works with SpdyServer example out of the box
2015-06-05 11:58:19 +09:00
Jean-Rémi Desjardins
9bcfef0f10 Fix incoherence in WebSocket example
Motivation:

The logic in the current websocket example is confusing and misleading

Modifications:

Remove occurrences of "http" and "https" and replace them with "ws" and "wss"

Result:

The example code is now coherent and is easier to understand for a new user.
2015-06-04 19:24:02 +02:00
Jestan Nirojan
4877fffa0a SCTP echo client/server multi-homing examples
Motivation:
There are no Netty SCTP examples on multi-homing.

Modifications:
- Added new example classes based on echo client/server example

Result:
Better documentation
2015-05-22 22:24:09 +02:00
Leonardo Freitas Gomes
781a85520c Add HTTP/2 Netty tiles example
Motivation:

Adding an example that showcases Netty’s HTTP/2 codec and that is
slightly more complex than the existing hello-world example. It is
based on the Gopher tiles example available here:
https://http2.golang.org/gophertiles?latency=0

Modifications:

Moved current http2 example to http2/helloworld.
Added http2 tiles example under http2/tiles.

Result:

A Netty tiles example is available.
2015-05-18 14:16:54 -07:00
Scott Mitchell
c6d61f9b43 Fix merge issue introduced by 04c0d77
Motiviation:
Interface changes between master and 4.1 branch resulted in a compile failure.

Modifications:
- change messageReceived to channelRead0

Result:
No more compile error.
2015-05-18 08:44:08 -07:00
Scott Mitchell
04c0d77287 HTTP/2 Server Example No Response for HTTP/1.x Only Clients
Motiviation:
The HTTP/2 server example just hangs when a client is using only HTTP with no ALPN or upgrade attempts. We should still send some kind of response.

Modifications:
The HTTP/2 server example has a special handler to detect no upgrade HTTP clients and generate a response.

Result:
Clients that just use HTTP with no upgrade will no appear hung when interacting with the HTTP/2 server example.
2015-05-18 08:40:06 -07:00
Scott Mitchell
2dd59e44b7 ALPN/NPN Examples Not using failure behavior compatible with all SslProviders
Motivation:
Examples that are using ALPN/NPN are using a failure mode which is not supported by the JDK SslProvider. The examples fail to run and throw an exception if the JDK SslProvider is used.

Modifications:
- Use SelectorFailureBehavior.NO_ADVERTISE
- Use SelectedListenerFailureBehavior.ACCEPT

Result:
Examples can be run with both OpenSsl and JDK SslProviders.
2015-05-08 09:39:09 -07:00
Eric Anderson
2927cdd504 Swap to SslContextBuilder in examples
Motivation:

Using factory methods of SslContext is deprecated. Code should be using
SslContextBuilder instead. This would have been done when the old
methods were deprecated, but memcache and http2 examples didn't exist in
the 4.0 branch which the PR was against.

Modifications:

Swap to the new construction pattern.

Result:

No more deprecated warnings during build of examples. Users are
instructed to use the new pattern.
2015-05-07 15:57:25 -07:00
Norman Maurer
f23b7b4efd [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
Norman Maurer
871ce43b1f [maven-release-plugin] prepare release netty-4.1.0.Beta5 2015-05-07 14:20:38 -04:00
Stephane Landelle
97d871a755 Validate cookie name and value characters Motivation:
RFC6265 specifies which characters are allowed in a cookie name and value.

Netty is currently too lax, which can used for HttpOnly escaping.

Modification:

In ServerCookieDecoder: discard cookie key-value pairs that contain invalid characters.
In ClientCookieEncoder: throw an exception when trying to encode cookies with invalid characters.

Result:

The problem described in the motivation section is fixed.
2015-05-07 06:33:36 +02:00
Scott Mitchell
9a7a85dbe5 ByteString introduced as AsciiString super class
Motivation:
The usage and code within AsciiString has exceeded the original design scope for this class. Its usage as a binary string is confusing and on the verge of violating interface assumptions in some spots.

Modifications:
- ByteString will be created as a base class to AsciiString. All of the generic byte handling processing will live in ByteString and all the special character encoding will live in AsciiString.

Results:
The AsciiString interface will be clarified. Users of AsciiString can now be clear of the limitations the class imposes while users of the ByteString class don't have to live with those limitations.
2015-04-14 16:35:17 -07:00
Eric Anderson
bd224286f5 [#3531] Create SslContext.Builder
Motivation:

SslContext factory methods have gotten out of control; it's past time to
swap to a builder.

Modifications:

New Builder class. The existing factory methods must be left as-is for
backward compatibility.

Result:

Fixes #3531
2015-04-14 07:28:34 +02:00
Norman Maurer
1e8a2e69db [#3592] Flush when writing HttpChunkedInput
Motivation:

We missed to flush the channel when using HttpChunkedInput (this is done when using SSL). This will result in a stale.

Modifications:

Replace ctx.write(...) with ctx.writeAndFlush(...)

Result:

Correctly working example.
2015-04-10 21:19:25 +02:00
Norman Maurer
aebbb862ac Add support for ALPN when using openssl + NPN client mode and support for CipherSuiteFilter
Motivation:

To support HTTP2 we need APLN support. This was not provided before when using OpenSslEngine, so SSLEngine (JDK one) was the only bet.
Beside this CipherSuiteFilter was not supported

Modifications:

- Upgrade netty-tcnative and make use of new features to support ALPN and NPN in server and client mode.
- Guard against segfaults after the ssl pointer is freed
- support correctly different failure behaviours
- add support for CipherSuiteFilter

Result:

Be able to use OpenSslEngine for ALPN / NPN for server and client.
2015-04-10 18:52:34 +02:00
Scott Mitchell
0d3a6e0511 HTTP/2 Decoder reduce preface conditional checks
Motivation:
The DefaultHttp2ConnectionDecoder class is calling verifyPrefaceReceived() for almost every frame event at all times.
The Http2ConnectionHandler class is calling readClientPrefaceString() on every decode event.

Modifications:
- DefaultHttp2ConnectionDecoder should not have to continuously call verifyPrefaceReceived() because it transitions boolean state 1 time for each connection.
- Http2ConnectionHandler should not have to continuously call readClientPrefaceString() because it transitions boolean state 1 time for each connection.

Result:
- Less conditional checks for the mainstream usage of the connection.
2015-03-28 18:52:35 -07:00
nmittler
0fe67cfba5 Using public LogLevel for HTTP/2 frame logging.
Motivation:

The Http2FrameLogger is currently using the internal logging classes. We should change this so that it's using the public classes and then converts internally.

Modifications:

Modified Http2FrameLogger and the examples to use the public LogLevel class.

Result:

Fixes #2512
2015-03-17 15:10:35 -07:00
Norman Maurer
fce0989844 [maven-release-plugin] prepare for next development iteration 2015-03-03 02:06:47 -05:00
Norman Maurer
ca3b1bc4b7 [maven-release-plugin] prepare release netty-4.1.0.Beta4 2015-03-03 02:05:52 -05:00
Trustin Lee
976db9269d Revamp io.netty.handler.codec.socksx
While implementing netty-handler-proxy, I realized various issues in our
current socksx package. Here's the list of the modifications and their
background:

- Split message types into interfaces and default implementations
  - so that a user can implement an alternative message implementations
- Use classes instead of enums when a user might want to define a new
  constant
  - so that a user can extend SOCKS5 protocol, such as:
    - defining a new error code
    - defining a new address type
- Rename the message classes
  - to avoid abbreviated class names. e.g:
    - Cmd -> Command
    - Init -> Initial
  - so that the class names align better with the protocol
    specifications. e.g:
    - AuthRequest -> PasswordAuthRequest
    - AuthScheme -> AuthMethod
- Rename the property names of the messages
  - so that the property names align better when the field names in the
    protocol specifications
- Improve the decoder implementations
  - Give a user more control over when a decoder has to be removed
  - Use DecoderResult and DecoderResultProvider to handle decode failure
    gracefully. i.e. no more Unknown* message classes
- Add SocksPortUnifinicationServerHandler since it's useful to the users
  who write a SOCKS server
  - Cleaned up and moved from the socksproxy example
2015-02-10 09:14:13 +09:00
Nitesh Kant
2d24e1f27d Back port HTTP/2 codec from master to 4.1
Motivation:

HTTP/2 codec was implemented in master branch.
Since, master is not yet stable and will be some time before it gets released, backporting it to 4.1, enables people to use the codec with a stable netty version.

Modification:

The code has been copied from master branch as is, with minor modifications to suit the `ChannelHandler` API in 4.x.
Apart from that change, there are two backward incompatible API changes included, namely,

- Added an abstract method:

  `public abstract Map.Entry<CharSequence, CharSequence> forEachEntry(EntryVisitor<CharSequence> visitor)
            throws Exception;`

to `HttpHeaders` and implemented the same in `DefaultHttpHeaders` as a delegate to the internal `TextHeader` instance.

- Added a method:

`FullHttpMessage copy(ByteBuf newContent);`

in `FullHttpMessage` with the implementations copied from relevant places in the master branch.

- Added missing abstract method related to setting/adding short values to `HttpHeaders`

Result:

HTTP/2 codec can be used with netty 4.1
2015-01-23 11:06:11 -05:00
Trustin Lee
0fc097cb20 Remove the references to the deprecated CookieDecoder 2015-01-21 22:31:06 +09:00
Daniel Norberg
54a39a94ac example: memcache: fix set command
Motivation:

The example MemcacheClient set command doesn't work.

Modifications:

Fill the extras field buffer with zeros so that it gets written to the
request payload.

Result:

The example MemcacheClient set command works.
2014-12-05 08:59:23 +01:00
Trustin Lee
338b60821d Do not write LastHttpContent twice in HttpStaticFileServer example
Related: #3122

Motivation:

The HttpStaticFileServer example writes the LastHttpContent twice at the
end of the transfer.  HttpChunkedInput already produces a
LastHttpContent at the end of the stream, so there's no reason to write
another.

Modifications:

Do not write LastHttpContent in HttpStaticFileServerHandler when
HttpChunkedInput is used to transfer a file.

Result:

HttpStaticFileServer does not violates the protocol anymore.
2014-11-21 11:43:32 +09:00
Daniel Bevenius
8ba9e5bede Add logLevel property to enable different log levels for the examples.
Motivation:

When running the examples using the provided run-examples.sh script the
log level is 'info' level. It can be handy to be able to configure a
different level, for example 'debug', while learning and trying out the
the examples.

Modifications:

Added a dependency to logback-classic to the examples pom.xml, and also
added a logback configuration file. The log level can be configured by
setting the 'logLevel' system property, and if that property is not set
the default will be 'info' level.
The run-examples.sh was updated to show an example of using the system
property to set the log level to 'debug'

Result:

It is now possible to turn on debug logging by settnig a system property
on the command line.
2014-11-21 10:48:57 +09:00
Idel Pivnitskiy
35db3c6710 Small performance improvements
Motivation:

Found performance issues via FindBugs and PMD.

Modifications:

- Removed unnecessary boxing/unboxing operations in DefaultTextHeaders.convertToInt(CharSequence) and DefaultTextHeaders.convertToLong(CharSequence). A boxed primitive is created from a string, just to extract the unboxed primitive value.
- Added a static modifier for DefaultHttp2Connection.ParentChangedEvent class. This class is an inner class, but does not use its embedded reference to the object which created it. This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary.
- Added a static compiled Pattern to avoid compile it each time it is used when we need to replace some part of authority.
- Improved using of StringBuilders.

Result:

Performance improvements.
2014-11-20 00:10:06 -05:00
Trustin Lee
4ce994dd4f Fix backward compatibility from the previous backport
Motivation:

The commit 50e06442c3 changed the type of
the constants in HttpHeaders.Names and HttpHeaders.Values, making 4.1
backward-incompatible with 4.0.

It also introduces newer utility classes such as HttpHeaderUtil, which
deprecates most static methods in HttpHeaders.  To ease the migration
between 4.1 and 5.0, we should deprecate all static methods that are
non-existent in 5.0, and provide proper counterpart.

Modification:

- Revert the changes in HttpHeaders.Names and Values
- Deprecate all static methods in HttpHeaders in favor of:
  - HttpHeaderUtil
  - the member methods of HttpHeaders
  - AsciiString
- Add integer and date access methods to HttpHeaders for easier future
  migration to 5.0
- Add HttpHeaderNames and HttpHeaderValues which provide standard HTTP
  constants in AsciiString
  - Deprecate HttpHeaders.Names and Values
  - Make HttpHeaderValues.WEBSOCKET lowercased because it's actually
    lowercased in all WebSocket versions but the oldest one
- Add RtspHeaderNames and RtspHeaderValues which provide standard RTSP
  constants in AsciiString
  - Deprecate RtspHeaders.*
- Do not use AsciiString.equalsIgnoreCase(CharSeq, CharSeq) if one of
  the parameters are AsciiString
- Avoid using AsciiString.toString() repetitively
  - Change the parameter type of some methods from String to
    CharSequence

Result:

Backward compatibility is recovered.  New classes and methods will make
the migration to 5.0 easier, once (Http|Rtsp)Header(Names|Values) are
ported to master.
2014-11-01 01:00:25 +09:00
Scott Mitchell
50e06442c3 Backport header improvements from 5.0
Motivation:
The header class hierarchy and algorithm was improved on the master branch for versions 5.x. These improvments should be backported to the 4.1 baseline.

Modifications:
- cherry-pick the following commits from the master branch: 2374e17, 36b4157, 222d258

Result:
Header improvements in master branch are available in 4.1 branch.
2014-11-01 00:59:57 +09:00
Scott Mitchell
04f77b76f8 Backport ALPN and Mutual Auth SSL
Motivation:

Improvements were made on the main line to support ALPN and mutual
authentication for TLS. These should be backported.

Modifications:

- Backport commits from the master branch
  - f8af84d599
  - e74c8edba3

Result:

Support for ALPN and mutual authentication.
2014-10-31 12:52:26 +09:00
Matthias Einwag
a7a654c82f Fix the websocket server example
Motivation:
As report in #2953 the websocket server example contained a bug and did therefore not work with chrome:
A websocket extension is added to the pipeline but extensions were disallowed in the handshaker and decoder,
which is leading the decoder to closing the connection after receiving an extension frame.

Modifications:
Allow websocket extensions in the handshaker to correctly enable the extension.

Result:
Working websocket server example
Fixes #2953
2014-10-25 16:17:55 +09:00
Trustin Lee
2309a75d15 Add proxy support for client socket connections
Related issue: #1133

Motivation:

There is no support for client socket connections via a proxy server in
Netty.

Modifications:

- Add a new module 'handler-proxy'
- Add ProxyHandler and its subclasses to support SOCKS 4a/5 and HTTP(S)
  proxy connections
- Add a full parameterized test for most scenarios
- Clean up pom.xml

Result:

A user can make an outgoing connection via proxy servers with only
trivial effort.
2014-10-14 12:29:08 +09:00
Matthias Einwag
547a0b04df Adding a benchmark for websockets
Motivation:

It is often helpful to measure the performance of connections, e.g. the
latency and the throughput. This can be performed through benchmarks.

Modification:

This adds a simple but configurable benchmark for websockets into the
example directory. The Netty WebSocket server will echo all received
websocket frames and will provide an HTML/JS page which serves as the
client for the benchmark.
The benchmark also provides a verification mode that verifies the sent
against the received data. This can be used for the verification ob
websocket frame encoding and decoding funtionality.

Result:

A benchmark is added in form a further Netty websocket example.
With this benchmark it is easily possible to measure the performance between Netty and a browser
2014-10-13 07:02:35 +02:00
Norman Maurer
eef2ad7cd2 [#2939] Fix SslContext usage in the examples for client side
Motivation:

We incorrectly used SslContext.newServerContext() in some places where a we needed a client context.

Modifications:

Use SslContext.newClientContext() when using ssl on the client side.

Result:

Working ssl client examples.
2014-09-26 20:59:06 +02:00
fredericBregier
5b3b48409f Fix example for Http Upload
Motivation:
The example mis handle two elements:
1) Last message is a LastHttpContent and is not taken into account by
the server handler
2) The client makes a sync on last write (chunked) but there is no flush
before, therefore the sync is waiting forever.

Modifications:
1) Take into account the message LastHttpContent in simple Get.
2) Removes sync but add flush for each post and multipost parts

Results:
Example is no more blocked after get test.

Should be done also in 4.0 and Master (similar changes)
2014-08-18 10:48:54 +02:00
Trustin Lee
b5f61d0de5 [maven-release-plugin] prepare for next development iteration 2014-08-16 03:27:42 +09:00
Trustin Lee
76ac3b21a5 [maven-release-plugin] prepare release netty-4.1.0.Beta3 2014-08-16 03:27:37 +09:00
Trustin Lee
b3c1904cc9 [maven-release-plugin] prepare for next development iteration 2014-08-15 09:31:03 +09:00
Trustin Lee
e013b2400f [maven-release-plugin] prepare release netty-4.1.0.Beta2 2014-08-15 09:30:59 +09:00
Trustin Lee
fc1429c00c Overall clean-up on socksx package
- SocksV[45] -> Socks[45]
- Make encodeAsByteBuf package private with some hassle
- Split SocksMessageEncoder into Socks4MessageEncoder and
  Socks5MessageEncoder, and remove the original
- Remove lazy singleton instantiation; we don't need it.
- Remove the deprecated methods
- Fix Javadoc errors
2014-08-14 16:41:04 -07:00
bk1te
1a05004523 Add socksx package which supports SOCKS 4/4a/5
Motivation:

SOCKS 4 and 5 are very different protocols although they share the same
name.  It is not possible to incorporate the two protocol versions into
a single package.

Modifications:

- Add a new package called 'socksx' to supercede 'socks' package.
- Add SOCKS 4/4a support to the 'socksx' package

Result:

codec-socks now supports all SOCKS versions
2014-08-14 16:40:46 -07:00
Norman Maurer
33a810a513 Move generic code to HttpOrSpdyChooser to simplify implementations
Motivation:

HttpOrSpdyChooser can be simplified so the user not need to implement getProtocol(...) method.

Modification:

Add implementation for the method. The user can override it if necessary.

Result:

Easier usage of HttpOrSpdyChooser.
2014-07-07 09:37:10 +02:00
Trustin Lee
e167b02d52 [maven-release-plugin] prepare for next development iteration 2014-07-04 17:26:02 +09:00
Trustin Lee
ba50cb829b [maven-release-plugin] prepare release netty-4.1.0.Beta1 2014-07-04 17:25:54 +09:00
Trustin Lee
787663a644 [maven-release-plugin] rollback the release of netty-4.1.0.Beta1 2014-07-04 17:11:14 +09:00
Trustin Lee
83eae705e1 [maven-release-plugin] prepare release netty-4.1.0.Beta1 2014-07-04 17:02:17 +09:00
Trustin Lee
10623ae133 Let OkResponseHandler extend SimpleChannelInboundHandler
Motivation:

OkResponseHandler is the last handler in the pipeline of the HTTP CORS
example.  It is responsible for releasing all messages it handled.

Modification:

Extend SimpleChannelInboundHandler instead of
ChannelInboundHandlerAdapter

Result:

Fixed a leak
2014-07-03 18:14:40 +09:00
Trustin Lee
d0912f2709 Fix most inspector warnings
Motivation:

It's good to minimize potentially broken windows.

Modifications:

Fix most inspector warnings from our profile
Update IntObjectHashMap

Result:

Cleaner code
2014-07-02 19:55:07 +09:00
Trustin Lee
41d44a8161 Remove 'get' prefix from all HTTP/SPDY messages
Motivation:

Persuit for the consistency in method naming

Modifications:

- Remove the 'get' prefix from all HTTP/SPDY message classes
- Fix some inspector warnings

Result:

Consistency
2014-06-24 18:03:33 +09:00
Norman Maurer
4036eda048 Make use of HttpChunkedInput as this will also work when compression is used 2014-06-23 09:38:48 +02:00
Trustin Lee
c076c33901 Backport the additional AsciiString/TextHeader changes from master
- Add useful static methods to AsciiString
- Add more getters in TextHeaders
- Remove unnecessary utility methods in SpdyHttpHeaders
2014-06-14 17:33:34 +09:00
Trustin Lee
681d460938 Introduce TextHeaders and AsciiString
Motivation:

We have quite a bit of code duplication between HTTP/1, HTTP/2, SPDY,
and STOMP codec, because they all have a notion of 'headers', which is a
multimap of string names and values.

Modifications:

- Add TextHeaders and its default implementation
- Add AsciiString to replace HttpHeaderEntity
  - Borrowed some portion from Apache Harmony's java.lang.String.
- Reimplement HttpHeaders, SpdyHeaders, and StompHeaders using
  TextHeaders
- Add AsciiHeadersEncoder to reuse the encoding a TextHeaders
  - Used a dedicated encoder for HTTP headers for better performance
    though
- Remove shortcut methods in SpdyHeaders
- Replace SpdyHeaders.getStatus() with HttpResponseStatus.parseLine()

Result:

- Removed quite a bit of code duplication in the header implementations.
- Slightly better performance thanks to improved header validation and
  hash code calculation
2014-06-14 15:36:19 +09:00
Trustin Lee
8b0a0f9a8f Introduce MessageAggregator and DecoderResultProvider
Motivation:

We have different message aggregator implementations for different
protocols, but they are very similar with each other.  They all stems
from HttpObjectAggregator.  If we provide an abstract class that provide
generic message aggregation functionality, we will remove their code
duplication.

Modifications:

- Add MessageAggregator which provides generic message aggregation
- Reimplement all existing aggregators using MessageAggregator
- Add DecoderResultProvider interface and extend it wherever possible so
  that MessageAggregator respects the state of the decoded message

Result:

Less code duplication
2014-06-05 16:51:14 +09:00
Trustin Lee
a8143eda27 Overall refactoring of the STOMP codec
- StompObject -> StompSubframe
- StompFrame -> StompHeadersSubframe
- StompContent -> StompContntSubframe
- FullStompFrame -> StompFrame
- StompEncoder/Decoder -> StompSubframeEncoder/Decoder
- StompAggregator -> StompSubframeAggregator
- Simplify the example
- Update Javadoc
- Miscellaneous cleanup
2014-06-04 17:09:42 +09:00
Sergey Skachkov
b286079205 Initial STOMP protocol work from @sskachkov 2014-06-04 17:09:42 +09:00
Daniel Bevenius
c1d6ba0598 OkResponseHandler should return a FullHttpResponse.
Motivation:
Currently OkResponseHandler returns a DefaultHttpResponse which is not
correct and it should be returning complete http response.

Modifications:
Updated OkResponseHandler to return an instance of
DefaultFullHttpResponse.

Result:
It is not possible to add compression to the example without getting any
errors.
2014-06-03 09:44:32 +02:00
Trustin Lee
9961cae7cf Use a forked exec-maven-plugin instead of maven-antrun-plugin
Motivation:

maven-antrun-plugin does not redirect stdin, and thus it's impossible to
run interactive examples such as securechat-client and telnet-client.
org.codehaus.mojo:exec-maven-plugin redirects stdin, but it buffers
stdout and stderr, and thus an application output is not flushed timely.

Modifications:

Deploy a forked version of exec-maven-plugin which flushes output
buffers in a timely manner.

Result:

Interactive examples work.  Launches faster than maven-antrun-plugin.
2014-05-23 20:06:04 +09:00
Trustin Lee
223efc5f99 Clean up the examples
Motivation:

The examples have not been updated since long time ago, showing various
issues fixed in this commit.

Modifications:

- Overall simplification to reduce LoC
  - Use system properties to get options instead of parsing args.
  - Minimize option validation
  - Just use System.out/err instead of Logger
  - Do not pass config as parameters - just access it directly
  - Move the main logic to main(String[]) instead of creating a new
    instance meaninglessly
    - Update netty-build-21 to make checkstyle not complain
  - Remove 'throws Exception' clause if possible
- Line wrap at 120 (previously at 80)
- Add an option to enable SSL for most examples
- Use ChannelFuture.sync() instead of await()
- Use System.out for the actual result. Use System.err otherwise.
- Delete examples that are not very useful:
  - applet
  - websocket/html5
  - websocketx/sslserver
  - localecho/multithreaded
- Add run-example.sh which simplifies launching an example from command
  line
- Rewrite FileServer example

Result:

Shorter and simpler examples.  A user can focus more on what it actually
does than miscellaneous stuff.  A user can launch an example very
easily.
2014-05-23 17:13:09 +09:00
Trustin Lee
37931306d5 Use maven-antrun-plugin instead of exec-maven-plugin
Motivation:

exec-maven-plugin does not flush stdout and stderr, making the console
output from the examples invisible to users

Modification:

Use maven-antrun-plugin instead

Result:

A user sees the output from the examples immediately.
2014-05-22 18:54:21 +09:00
Trustin Lee
5ce410c69e Future compatibility with TLS ALPN
Motivation:

According to TLS ALPN draft-05, a client sends the list of the supported
protocols and a server responds with the selected protocol, which is
different from NPN.  Therefore, ApplicationProtocolSelector won't work
with ALPN

Modifications:

- Use Iterable<String> to list the supported protocols on the client
  side, rather than using ApplicationProtocolSelector
- Remove ApplicationProtocolSelector

Result:

Future compatibility with TLS ALPN
2014-05-22 10:03:02 +09:00
Trustin Lee
d318f526a2 Update the instruction for running SPDY examples 2014-05-21 17:30:07 +09:00
Trustin Lee
861ed1e7ad Add unified NextProtoNego extension support to SslContext
Motivation:

- OpenSslEngine and JDK SSLEngine (+ Jetty NPN) have different APIs to
  support NextProtoNego extension.
  - It is impossible to configure NPN with SslContext when the provider
    type is JDK.

Modification:

- Implement NextProtoNego extension by overriding the behavior of
  SSLSession.getProtocol() for both OpenSSLEngine and JDK SSLEngine.
  - SSLEngine.getProtocol() returns a string delimited by a colon (':')
    where the first component is the transport protosol (e.g. TLSv1.2)
    and the second component is the name of the application protocol
- Remove the direct reference of Jetty NPN classes from the examples
- Add SslContext.newApplicationProtocolSelector

Result:

- A user can now use both JDK SSLEngine and OpenSslEngine for NPN-based
  protocols such as HTTP2 and SPDY
2014-05-21 17:24:52 +09:00
Trustin Lee
4436870b28 Clean up the execution mechanism of examples
Motivation:

- There's no way to pass an argument to an example.
- Assigning a Maven profile for each example is an overkill.
  It makes the pom.xml crowded.

Modifications:

- Remove example profiles from example/pom.xml
- Keep the list of examples in run-example.sh
- run-example.sh passes all options to exec-maven-plugin.
  For example, we can now do this:

    ./run-example.sh -Dssl -Dport=443 http-server

Result:

- It's much easier to add a new example and provide an easy way to
  launch it.
- We can still pass an arbitrary argument to the example being launched.
  (I'll update all examples to make them get their options from system
  properties rather than from args[].
2014-05-20 23:33:45 +09:00
Trustin Lee
5354ccaa8f Fix a build problem with JDK 8
Motivation:

Build fails with JDK 8 because npn-boot does not work with JDK 8

Modifications:

Do not specify bootclasspath when on JDK 8

Result:

Build is green again.
2014-05-20 22:40:11 +09:00
Trustin Lee
c77375cf54 Clean up example execution
Motivation:

- example/pom.xml has quite a bit of duplication.
- We expect that we depend on npn-boot in more than one module in the
  near future. (e.g. handler, codec-http, and codec-http2)

Modification:

- Deduplicate the profiles in example/pom.xml
- Move the build configuration related with npn-boot to the parent pom.
- Add run-example.sh that helps a user launch an example easily

Result:

- Cleaner build files
- Easier to add a new example
- Easier to launch an example
- Easier to run the tests that relies on npn-boot in the future
2014-05-20 20:09:05 +09:00
Trustin Lee
ef59c4ce61 Add netty-tcnative dependency to netty-example
Motivation:

It's useful to have netty-tcnative dependency in netty-example because
we can play with OpenSslEngine from our IDE.

Modifications:

Add netty-tcnative to example/pom.xml
2014-05-18 04:29:50 +09:00
Trustin Lee
b6c0c0c95f Add an OpenSslEngine and the universal API for enabling SSL
Motivation:

Some users already use an SSLEngine implementation in finagle-native. It
wraps OpenSSL to get higher SSL performance.  However, to take advantage
of it, finagle-native must be compiled manually, and it means we cannot
pull it in as a dependency and thus we cannot test our SslHandler
against the OpenSSL-based SSLEngine.  For an instance, we had #2216.

Because the construction procedures of JDK SSLEngine and OpenSslEngine
are very different from each other, we also need to provide a universal
way to enable SSL in a Netty application.

Modifications:

- Pull netty-tcnative in as an optional dependency.
  http://netty.io/wiki/forked-tomcat-native.html
- Backport NativeLibraryLoader from 4.0
- Move OpenSSL-based SSLEngine implementation into our code base.
  - Copied from finagle-native; originally written by @jpinner et al.
  - Overall cleanup by @trustin.
- Run all SslHandler tests with both default SSLEngine and OpenSslEngine
- Add a unified API for creating an SSL context
  - SslContext allows you to create a new SSLEngine or a new SslHandler
    with your PKCS#8 key and X.509 certificate chain.
  - Add JdkSslContext and its subclasses
  - Add OpenSslServerContext
- Add ApplicationProtocolSelector to ensure the future support for NPN
  (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on
  the client-side.
- Add SimpleTrustManagerFactory to help a user write a
  TrustManagerFactory easily, which should be useful for those who need
  to write an alternative verification mechanism. For example, we can
  use it to implement an unsafe TrustManagerFactory that accepts
  self-signed certificates for testing purposes.
- Add InsecureTrustManagerFactory and FingerprintTrustManager for quick
  and dirty testing
- Add SelfSignedCertificate class which generates a self-signed X.509
  certificate very easily.
- Update all our examples to use SslContext.newClient/ServerContext()
- SslHandler now logs the chosen cipher suite when handshake is
  finished.

Result:

- Cleaner unified API for configuring an SSL client and an SSL server
  regardless of its internal implementation.
- When native libraries are available, OpenSSL-based SSLEngine
  implementation is selected automatically to take advantage of its
  performance benefit.
- Examples take advantage of this modification and thus are cleaner.
2014-05-18 02:54:06 +09:00
Trustin Lee
b9039eaa82 Synchronized between 4.1 and master again (part 2)
Motivation:
4 and 5 were diverged long time ago and we recently reverted some of the
early commits in master.  We must make sure 4.1 and master are not very
different now.

Modification:
Remove ChannelHandlerInvoker.writeAndFlush(...) and the related
implementations.

Result:
4.1 and master got closer.
2014-04-25 15:06:26 +09:00
Trustin Lee
db3709e652 Synchronized between 4.1 and master
Motivation:

4 and 5 were diverged long time ago and we recently reverted some of the
early commits in master.  We must make sure 4.1 and master are not very
different now.

Modification:

Fix found differences

Result:

4.1 and master got closer.
2014-04-25 00:38:02 +09:00
Jeff Pinner
7808b9926d SPDY: refactor frame codec implementation
Motivation:

Currently, the SPDY frame encoding and decoding code is based upon
the ChannelHandler abstraction. This requires maintaining multiple
versions for 3.x and 4.x (and possibly 5.x moving forward).

Modifications:

The SPDY frame encoding and decoding code is separated from the
ChannelHandler and SpdyFrame abstractions. Also test coverage is
improved.

Result:

SpdyFrameCodec now implements the ChannelHandler abstraction and is
responsible for creating and handling SpdyFrame objects.
2014-04-15 19:57:38 +02:00
Michael Nitschinger
837ddc01d2 [example-memcache] fix formatting introduced by the memcache examples. 2014-04-11 12:16:28 +02:00
Matthew Leventi
7a6fa73989 Add a Example for Memcache Binary Codec
Motivation:
Currently, there exists no example which shows how to use the memcache binary
protocol.

Modifications:
Add an example client and client handler to show how to utilize the binary
protocol in a memcache client with a simple interactive shell.

Result:
Users looking for an example can now start off with the provided one.
2014-04-11 11:29:05 +02:00
Norman Maurer
88481131be [#2353] Use a privileged block to get ClassLoader and System property if needed
Motivation:
When using System.getProperty(...) and various methods to get a ClassLoader it will fail when a SecurityManager is in place.

Modifications:
Use a priveled block if needed. This work is based in the PR #2353 done by @anilsaldhana .

Result:
Code works also when SecurityManager is present
2014-04-08 14:12:25 +02:00
Daniel Bevenius
4fc9afa102 Adding origins whitelist support for CORS
Motivation:
Currently the CORS support only handles a single origin, or a wildcard
origin. This task should enhance Netty's CORS support to allow multiple
origins to be specified. Just being allowed to specify one origin is
particulary limiting when a site support both http and https for
example.

Modifications:
- Updated CorsConfig and its Builder to accept multiple origins.

Result:
Users are now able to configure multiple origins for CORS.

[https://github.com/netty/netty/issues/2346]
2014-03-30 19:40:48 +02:00
Trustin Lee
1e3b7d8273 Replace LocalEventLoopGroup with DefaultEventLoopGroup
Motivation:

LocalEventLoopGroup and LocalEventLoop are not really special for LocalChannels.  It can be used for other channel implementations as long as they don't require special handling.

Modifications:

- Add DefaultEventLoopGroup and DefaultEventLoop
- Deprecate LocalEventLoopGroup and make it extend DefaultEventLoopGroup
- Add DefaultEventLoop and remove LocalEventLoop
- Fix inspector warnings

Result:

- Better class names.
2014-03-24 11:39:55 +09:00
Norman Maurer
7c4ad004f6 Ensure the HttpResponseEncoder is always placed before the HttpObjectAggregator. Part of [#2219] 2014-03-05 06:58:04 +01:00
Jakob Buchgraber
156f311ee9 Added a secure WebSocket client example
Merged WebSocketClient and WebSocketSslClient

Add private constructors to fix checkstyle errors.

More checkstyle madness.

made WebSocketClientRunner final
2014-03-03 06:49:47 +01:00
Jeff Pinner
b02531f0aa SPDY: remove SPDY/3 support 2014-02-20 15:00:32 -08:00
Trustin Lee
ac70dc4546 Update the version to 4.1.0.Alpha1-SNAPSHOT 2014-02-13 18:32:26 -08:00
Michael Nitschinger
574480e332 Rename HttpDataFactory.*datas to *data. Fixes #2094 2014-02-13 17:45:36 -08:00
fredericBregier
651c7b056a Split HttpPostRequestDecoder into HttpPostStandardRequestDecoder and HttpPostMultipartRequestDecoder / Add HttpData.maxSize
- Related issues: #1937 #1938 and #1946
- Add InterfaceHttpPostRequestDecoder and Make HttpPostRequestDecoder implement it
- HttpPostRequestDecoder actually delegates itself to HttpPostStandardRequestDecoder or HttpPostMultipartRequestDecoder
- Remove IncompatibleDataDecoderException because it's not thrown anywhere now
2014-02-13 15:24:45 -08:00
Trustin Lee
c8ec5be842 Remove a version clause added by mistake 2014-02-08 11:07:58 -08:00
Trustin Lee
aeeb2e7bac Fix a build error related with NPN version and JDK8 2014-02-08 10:48:42 -08:00
Trustin Lee
87b853c60d Use smaller number of boss threads in the example
.. because usually there's no need to use many boss threads.
2014-02-07 14:43:07 -08:00
Trustin Lee
617739c515 Simplify exec-maven-plugin configuration
- Move the version number to the parent pom's pluginManagement section
- Remove unnecessary system properties
- Increase the scope of execution from compile to runtime
2014-02-07 13:40:22 -08:00
Trustin Lee
8e854bbf18 Fix indentation 2014-02-07 10:30:49 -08:00
Daniel Bevenius
9ca71f2d8e Adding ability to start spdy server/client using maven. 2014-02-07 11:28:36 +01:00
Trustin Lee
417f7264fd Reorganize the SPDY example
- Move the server example to spdy.server
- Move the client example to spdy.client
- Fix inspection warnings
2014-02-05 14:54:02 -08:00
Leonardo Freitas Gomes
69a1095976 SPDY client example
Demonstrates the usage of SPDY from a client perspective. One can also
use a SPDY-enabled browser as a client, but it’s easier to understand
the internals of the protocol from a client point-of-view if you have
some code you can debug.
2014-02-05 14:44:01 -08:00
jwilson
38d04c927f Tweak snoop example to send a full HTTP request.
Without this, future HTTP requests on this channel will
silently fail because the HttpObjectEncoder will be left
in an unhappy state.
2014-02-01 18:35:38 +01:00
Norman Maurer
293e34e13f Run autobahntestsuite as part of the build 2014-01-28 07:23:10 +01:00
Norman Maurer
d67184b488 [maven-release-plugin] prepare for next development iteration 2014-01-21 08:18:32 +01:00
Norman Maurer
287515210d [maven-release-plugin] prepare release netty-4.0.15.Final 2014-01-21 08:18:26 +01:00
Norman Maurer
5f8a0cc10b Make use of a Logger in the SPDY example and simplify it a bit 2014-01-21 07:33:35 +01:00
Veebs
9a9f98ffcd SPDY example app 2014-01-21 07:33:35 +01:00
Norman Maurer
e0b0a99887 Fix compile error 2014-01-16 09:00:27 +01:00
Daniel Bevenius
75b0360867 Adding a Cross Origin Resource Sharing (CORS) handler. 2014-01-16 08:18:16 +01:00
Veebs
1326ba54ee Replaced deprecated 'sendUnsupportedWebSocketVersionResponse()' with 'sendUnsupportedVersionResponse()' 2014-01-13 06:33:57 +01:00
Trustin Lee
e83d2e0b4e [maven-release-plugin] prepare for next development iteration 2013-12-22 21:57:48 +09:00
Trustin Lee
cdb700c7a4 [maven-release-plugin] prepare release netty-4.0.14.Final 2013-12-22 21:57:40 +09:00
Trustin Lee
0b7aedb13b [maven-release-plugin] rollback the release of netty-4.0.14.Final 2013-12-22 21:53:24 +09:00
Trustin Lee
4bf6ec7171 [maven-release-plugin] prepare release netty-4.0.14.Final 2013-12-22 21:52:56 +09:00
Trustin Lee
9c1a49c58e [maven-release-plugin] rollback the release of netty-4.0.14.Final 2013-12-22 21:47:35 +09:00
Trustin Lee
008a049bf4 [maven-release-plugin] prepare for next development iteration 2013-12-22 21:43:55 +09:00
Trustin Lee
f6cb9088c6 [maven-release-plugin] prepare release netty-4.0.14.Final 2013-12-22 21:43:45 +09:00
Norman Maurer
17f5865e38 [maven-release-plugin] prepare for next development iteration 2013-11-29 19:31:01 +01:00
Norman Maurer
ead617fdcc [maven-release-plugin] prepare release netty-4.0.14.Beta1 2013-11-29 19:30:55 +01:00
Norman Maurer
6cf2748dbb [maven-release-plugin] prepare for next development iteration 2013-11-28 15:04:51 +01:00
Norman Maurer
5fe7596f49 [maven-release-plugin] prepare release netty-4.0.13.Final 2013-11-28 15:04:46 +01:00
Trustin Lee
407f0a36f5 Simplify bundle generation / Add io.netty.versions.properties to all JARs
- Fixes #2003 properly
- Instead of using 'bundle' packaging, use 'jar' packaging.  This is
  more robust because some strict build tools fail to retrieve the
  artifacts from a Maven repository unless their packaging is not 'jar'.
- All artifacts now contain META-INF/io.netty.version.properties, which
  provides the detailed information about the build and repository.
- Removed OSGi testsuite temporarily because it gives false errors
  during split package test and examination.
- Add io.netty.util.Version for easy retrieval of version information
2013-11-26 22:01:46 +09:00
Norman Maurer
b5a587fadf Use pooled allocator for AutobahnServer and voidPromises 2013-11-15 12:00:33 +01:00
Norman Maurer
db78581bbb [maven-release-plugin] prepare for next development iteration 2013-11-07 18:11:45 +01:00
Norman Maurer
2386777af8 [maven-release-plugin] prepare release netty-4.0.12.Final 2013-11-07 18:11:38 +01:00
Trustin Lee
54db9ec725 Use StringUtil.simpleClassName(..) instead of Class.getSimpleName() where necessary
- Class.getSimpleName() doesn't render anonymous classes very well
- + some minor cleanup
2013-11-04 19:46:15 +09:00
Trustin Lee
2712ed9cbb Fix inspector warnings 2013-11-02 20:00:14 +09:00
Norman Maurer
ceab146b54 [maven-release-plugin] prepare for next development iteration 2013-10-21 07:43:42 +02:00
Norman Maurer
27a89d6032 [maven-release-plugin] prepare release netty-4.0.11.Final 2013-10-21 07:41:49 +02:00
Bill Gallagher
1542b36e80 minor gc optimization: better DefaultHttpHeaders.iterator() 2013-10-11 20:44:07 +02:00
Norman Maurer
d7da19f745 [maven-release-plugin] prepare for next development iteration 2013-10-02 15:48:52 +02:00
Norman Maurer
d35768ae11 [maven-release-plugin] prepare release netty-4.0.10.Final 2013-10-02 15:48:45 +02:00
Trustin Lee
cd275ba67e No need to use an unreleasable buffer - just wrap an array 2013-09-14 11:59:51 +02:00
Norman Maurer
ffab456aca Bump up version to reflect correct one 2013-09-09 11:20:12 +02:00
Norman Maurer
363531caf9 [maven-release-plugin] rollback the release of netty-4.0.9.Final 2013-09-06 09:18:34 +02:00
Norman Maurer
9d53573ee8 [maven-release-plugin] prepare for next development iteration 2013-09-06 09:17:15 +02:00
Norman Maurer
2e39b25cd4 [maven-release-plugin] prepare for next development iteration 2013-08-26 12:01:03 +02:00
Norman Maurer
b67659a866 [maven-release-plugin] prepare release netty-4.0.8.Final 2013-08-26 12:00:54 +02:00
radimch
9acf130adb resource leak: FileInputStream was never closed 2013-08-14 07:10:10 +02:00
bk1te
65fd9c0b12 use Promise instead of CallbackNotifier 2013-08-14 06:51:03 +02:00
radimch
0d6a6bde04 resource leak: Formatter was never closed 2013-08-09 14:55:54 +02:00
Norman Maurer
1d3560e389 [maven-release-plugin] prepare for next development iteration 2013-08-08 13:53:28 +02:00
Norman Maurer
8e97e6c461 [maven-release-plugin] prepare release netty-4.0.7.Final 2013-08-08 13:53:19 +02:00
Norman Maurer
3f2000fa3a [maven-release-plugin] prepare for next development iteration 2013-08-01 10:59:55 +02:00
Norman Maurer
3f70d5caa4 [maven-release-plugin] prepare release netty-4.0.6.Final 2013-08-01 10:59:46 +02:00
Norman Maurer
e3410680de [maven-release-plugin] prepare for next development iteration 2013-07-31 20:08:14 +02:00
Norman Maurer
0e124583d6 [maven-release-plugin] prepare release netty-4.0.5.Final 2013-07-31 20:08:05 +02:00
Norman Maurer
0bc7d3f5d1 [maven-release-plugin] prepare for next development iteration 2013-07-23 10:04:23 +02:00
Norman Maurer
ca00182797 [maven-release-plugin] prepare release netty-4.0.4.Final 2013-07-23 10:04:14 +02:00
Trustin Lee
762adfcb69 Update HttpStaticFileServer example / Fix bugs related with progress notification
- Fix a bug in DefaultProgressivePromise.tryProgress() where the notification is dropped
 - Fix a bug in AbstractChannel.calculateMessageSize() where FileRegion is not counted
 - HttpStaticFileServer example now uses zero copy file transfer if possible.
2013-07-19 13:21:32 +09:00
Trustin Lee
f96a8e5951 Implement ProgressivePromise notification in NIO byte channels and ChunkedWriteHandler
- Refine the contract of GenericProgressiveFutureListener.
- Negative 'total' now means 'unknown', which is useful for ChunkedWriteHandler.
2013-07-19 12:53:23 +09:00
Trustin Lee
b130ee6a6c [maven-release-plugin] prepare for next development iteration 2013-07-18 11:17:42 +09:00
Trustin Lee
10d395e829 [maven-release-plugin] prepare release netty-4.0.3.Final 2013-07-18 11:17:31 +09:00
Norman Maurer
fc7c950b08 [maven-release-plugin] prepare for next development iteration 2013-07-17 15:58:36 +02:00
Norman Maurer
bbbf72359e [maven-release-plugin] prepare release netty-4.0.2.Final 2013-07-17 15:58:28 +02:00
Trustin Lee
57eb531eb8 [maven-release-plugin] prepare for next development iteration 2013-07-16 17:16:10 +09:00
Trustin Lee
76cefcc421 [maven-release-plugin] prepare release netty-4.0.1.Final 2013-07-16 17:15:54 +09:00
kxbmap
ed72925547 Fix sendNumbers logic 2013-07-16 07:08:21 +02:00
Norman Maurer
5297eba280 [maven-release-plugin] prepare for next development iteration 2013-07-15 15:48:15 +02:00
Norman Maurer
c5d8af446a [maven-release-plugin] prepare release netty-4.0.0.Final 2013-07-15 15:48:05 +02:00
Trustin Lee
246a3ecdcb [maven-release-plugin] prepare for next development iteration 2013-07-15 20:58:33 +09:00
Trustin Lee
e8fd209115 [maven-release-plugin] prepare release netty-4.0.0.Final 2013-07-15 20:58:21 +09:00
Norman Maurer
ecb215c12f Fix buffer leaks 2013-07-14 22:50:53 +02:00
Norman Maurer
4e604a6553 Make clear how to use HTTPS in the helloworld example 2013-07-12 11:21:51 +02:00
Norman Maurer
e85ae721b2 Set the destroyed flag at the correct time and fix a the httpupload example to release all resources 2013-07-11 13:48:37 +02:00
Norman Maurer
c0580cfe71 Fix examples 2013-07-11 11:25:40 +02:00
Norman Maurer
1d577b1b8b [#1561] Fix Securechat example which was broken because Channel was not flushed 2013-07-11 11:07:06 +02:00
Norman Maurer
f47fa76b9a Fix resource leakage in example 2013-07-11 10:20:38 +02:00
Norman Maurer
b57d9f307f Allow per-write promises and disallow promises on flush()
- write() now accepts a ChannelPromise and returns ChannelFuture as most
  users expected.  It makes the user's life much easier because it is
  now much easier to get notified when a specific message has been
  written.
- flush() does not create a ChannelPromise nor returns ChannelFuture.
  It is now similar to what read() looks like.
2013-07-11 00:49:48 +09:00