Netty HTTP

Available as of Camel 2.12

The netty-http component is an extension to Netty component to facilitiate HTTP transport with Netty.

This camel component supports both producer and consumer endpoints.

	Upgrade to Netty 4.0 planned
	This component is intended to be upgraded to use Netty 4.0 when camel-netty4 component has finished being upgraded. At the time being this component is still based on Netty 3.x. The upgrade is intended to be as backwards compatible as possible.

Stream

Netty is stream based, which means the input it receives is submitted to Camel as a stream. That means you will only be able to read the content of the stream once. If you find a situation where the message body appears to be empty or you need to access the data multiple times (eg: doing multicasting, or redelivery error handling) you should use Stream Caching or convert the message body to a String which is safe to be re-read multiple times.

Maven users will need to add the following dependency to their pom.xml for this component:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-netty-http</artifactId>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>

The URI scheme for a netty component is as follows

netty-http:http://localhost:8080[?options]

You can append query options to the URI in the following format, ?option=value&option=value&...

Query parameters vs endpoint options

You may be wondering how Camel recognizes URI query parameters and endpoint options. For example you might create endpoint URI as follows - netty-http:http//example.com?myParam=myValue&compression=true . In this example myParam is the HTTP parameter, while compression is the Camel endpoint option. The strategy used by Camel in such situations is to resolve available endpoint options and remove them from the URI. It means that for the discussed example, the HTTP request sent by Netty HTTP producer to the endpoint will look as follows - http//example.com?myParam=myValue , because compression endpoint option will be resolved and removed from the target URL. Keep also in mind that you cannot specify endpoint options using dynamic headers (like CamelHttpQuery). Endpoint options can be specified only at the endpoint URI definition level (like to or from DSL elements).

	A lot more options
	Important: This component inherits all the options from Netty. So make sure to look at the Netty documentation as well. Notice that some options from Netty is not applicable when using this Netty HTTP component, such as options related to UDP transport.

The NettyHttpSecurityConfiguration has the following options:

The following headers can be used on the producer to control the HTTP request.

The following headers is provided as meta-data when a route starts from an Netty HTTP endpoint:

The description in the table takes offset in a route having: from("netty-http:http:0.0.0.0:8080/myapp")...

This component uses the org.apache.camel.component.netty.http.NettyHttpMessage as the message implementation on the Exchange. This allows end users to get access to the original Netty request/response instances if needed, as shown below. Mind that the original response may not be accessible at all times.

org.jboss.netty.handler.codec.http.HttpRequest request = exchange.getIn(NettyHttpMessage.class).getHttpRequest();

In the route below we use Netty HTTP as a HTTP server, which returns back a hardcoded "Bye World" message.

    from("netty-http:http://0.0.0.0:8080/foo")
      .transform().constant("Bye World");

And we can call this HTTP server using Camel also, with the ProducerTemplate as shown below:

    String out = template.requestBody("netty-http:http://localhost:8080/foo", "Hello World", String.class);
    System.out.println(out);

And we get back "Bye World" as the output.

By default Netty HTTP will only match on exact uri's. But you can instruct Netty to match prefixes. For example

from("netty-http:http://0.0.0.0:8123/foo").to("mock:foo");

In the route above Netty HTTP will only match if the uri is an exact match, so it will match if you enter http://0.0.0.0:8123/foo but not match if you do http://0.0.0.0:8123/foo/bar.

So if you want to enable wildcard matching you do as follows:

from("netty-http:http://0.0.0.0:8123/foo?matchOnUriPrefix=true").to("mock:foo");

So now Netty matches any endpoints with starts with foo.

To match any endpoint you can do:

from("netty-http:http://0.0.0.0:8123?matchOnUriPrefix=true").to("mock:foo");

In the same CamelContext you can have multiple routes from Netty HTTP that shares the same port (eg a org.jboss.netty.bootstrap.ServerBootstrap instance). Doing this requires a number of bootstrap options to be identical in the routes, as the routes will share the same org.jboss.netty.bootstrap.ServerBootstrap instance. The instance will be configured with the options from the first route created.

The options the routes must be identical configured is all the options defined in the org.apache.camel.component.netty.NettyServerBootstrapConfiguration configuration class. If you have configured another route with different options, Camel will throw an exception on startup, indicating the options is not identical. To mitigate this ensure all options is identical.

Here is an example with two routes that share the same port.

	Two routes sharing the same port
	from("netty-http:http://0.0.0.0:{{port}}/foo") .to("mock:foo") .transform().constant("Bye World"); from("netty-http:http://0.0.0.0:{{port}}/bar") .to("mock:bar") .transform().constant("Bye Camel");

And here is an example of a mis configured 2nd route that do not have identical org.apache.camel.component.netty.NettyServerBootstrapConfiguration option as the 1st route. This will cause Camel to fail on startup.

	Two routes sharing the same port, but the 2nd route is misconfigured and will fail on starting
	from("netty-http:http://0.0.0.0:{{port}}/foo") .to("mock:foo") .transform().constant("Bye World"); // we cannot have a 2nd route on same port with SSL enabled, when the 1st route is NOT from("netty-http:http://0.0.0.0:{{port}}/bar?ssl=true") .to("mock:bar") .transform().constant("Bye Camel");

By configuring the common server bootstrap option in an single instance of a org.apache.camel.component.netty.NettyServerBootstrapConfiguration type, we can use the bootstrapConfiguration option on the Netty HTTP consumers to refer and reuse the same options across all consumers.

<bean id="nettyHttpBootstrapOptions" class="org.apache.camel.component.netty.NettyServerBootstrapConfiguration">
  <property name="backlog" value="200"/>
  <property name="connectTimeout" value="20000"/>
  <property name="workerCount" value="16"/>
</bean>

And in the routes you refer to this option as shown below

<route>
  <from uri="netty-http:http://0.0.0.0:{{port}}/foo?bootstrapConfiguration=#nettyHttpBootstrapOptions"/>
  ...
</route>

<route>
  <from uri="netty-http:http://0.0.0.0:{{port}}/bar?bootstrapConfiguration=#nettyHttpBootstrapOptions"/>
  ...
</route>

<route>
  <from uri="netty-http:http://0.0.0.0:{{port}}/beer?bootstrapConfiguration=#nettyHttpBootstrapOptions"/>
  ...
</route>

See the Netty HTTP Server Example for more details and example how to do that.

The Netty HTTP consumer supports HTTP basic authentication by specifying the security realm name to use, as shown below

<route>
   <from uri="netty-http:http://0.0.0.0:{{port}}/foo?securityConfiguration.realm=karaf"/>
   ...
</route>

The realm name is mandatory to enable basic authentication. By default the JAAS based authenticator is used, which will use the realm name specified (karaf in the example above) and use the JAAS realm and the JAAS LoginModules of this realm for authentication.

End user of Apache Karaf / ServiceMix has a karaf realm out of the box, and hence why the example above would work out of the box in these containers.

The org.apache.camel.component.netty.http.SecurityConstraint allows to define constrains on web resources. And the org.apache.camel.component.netty.http.SecurityConstraintMapping is provided out of the box, allowing to easily define inclusions and exclusions with roles.

For example as shown below in the XML DSL, we define the constraint bean:

  <bean id="constraint" class="org.apache.camel.component.netty.http.SecurityConstraintMapping">
    <!-- inclusions defines url -> roles restrictions -->
    <!-- a * should be used for any role accepted (or even no roles) -->
    <property name="inclusions">
      <map>
        <entry key="/*" value="*"/>
        <entry key="/admin/*" value="admin"/>
        <entry key="/guest/*" value="admin,guest"/>
      </map>
    </property>
    <!-- exclusions is used to define public urls, which requires no authentication -->
    <property name="exclusions">
      <set>
        <value>/public/*</value>
      </set>
    </property>
  </bean>

The constraint above is define so that

To use this constraint we just need to refer to the bean id as shown below:

<route>
   <from uri="netty-http:http://0.0.0.0:{{port}}/foo?matchOnUriPrefix=true&ecurityConfiguration.realm=karaf&ecurityConfiguration.securityConstraint=#constraint"/>
   ...
</route>