Page History

h2. Netty HTTP Component
*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.

{info:title=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.
{info}

Maven users will need to add the following dependency to their {{pom.xml}} for this component:
{code:xml}
<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>
{code}

h3. URI format

The URI scheme for a netty component is as follows

{code}
netty-http:http://localhost:8080[?options]
{code}

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

h3. HTTP Options

{info:title=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.
{info}

{div:class=confluenceTableSmall}
|| Name || Default Value || Description ||
| {{chunked}} | {{true}} | Allow using chunked transfer if the client supports it from the HTTP headers. |
| {{compression}} | {{false}} | Allow using gzip/deflate for compression if the client supports it from the HTTP headers. |
| {{headerFilterStrategy}} | | To use a custom  {{org.apache.camel.spi.HeaderFilterStrategy}} to filter headers. |
| {{httpMethodRestrict}} | | To disable HTTP methods on the Netty HTTP consumer. You can specify multiple separated by comma. |
| {{mapHeaders}} | {{true}} | If this option is enabled, then during binding from Netty to Camel [Message] then the headers will be mapped as well (eg added as header to the Camel [Message] as well). You can turn off this option to disable this. The headers can still be accessed from the {{org.apache.camel.component.netty.http.NettyHttpMessage}} message with the method {{getHttpRequest()}} that returns the Netty HTTP request {{org.jboss.netty.handler.codec.http.HttpRequest}} instance. |
| {{matchOnUriPrefix}} | {{false}} | Whether or not Camel should try to find a target consumer by matching the URI prefix if no exact match is found. See further below for more details. |
| {{nettyHttpBinding}} | | To use a custom {{org.apache.camel.component.netty.http.NettyHttpBinding}} for binding to/from Netty and Camel Message API. |
| {{bridgeEndpoint}} | {{false}} | If the option is {{true}}, the producer will ignore the {{Exchange.HTTP_URI}} header, and use the endpoint's URI for request. You may also set the {{throwExceptionOnFailure}} to be {{false}} to let the producer send all the fault response back. |
| {{throwExceptionOnFailure}} | {{true}} | Option to disable throwing the {{HttpOperationFailedException}} in case of failed responses from the remote server. This allows you to get all responses regardles of the HTTP status code. |
| {{traceEnabled}} | {{false}} | Specifies whether to enable HTTP TRACE for this Netty HTTP consumer. By default TRACE is turned off. |
| {{transferException}} | {{false}} | If enabled and an [Exchange] failed processing on the consumer side, and if the caused Exception was send back serialized in the response as a {{application/x-java-serialized-object}} content type. On the producer side the exception will be deserialized and thrown as is, instead of the {{HttpOperationFailedException}}. The caused exception is required to be serialized. |
| {{urlDecodeHeaders}} | {{true}} | If this option is enabled, then during binding from Netty to Camel [Message] then the header values will be URL decoded (eg %20 will be a space character. Notice this option is used by the default {{org.apache.camel.component.netty.http.NettyHttpBinding}} and therefore if you implement a custom {{org.apache.camel.component.netty.http.NettyHttpBinding}} then you would need to decode the headers accordingly to this option. |
| {{nettySharedHttpServer}} | {{null}} | To use a shared [Netty HTTP] server. See [Netty HTTP Server Example] for more details. |
{div}

h3. Message Headers

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

{div:class=confluenceTableSmall}
|| Name || Type || Description ||
| {{CamelHttpMethod}} | {{String}} | Allow to control what HTTP method to use such as GET, POST, TRACE etc. The type can also be a {{org.jboss.netty.handler.codec.http.HttpMethod}} instance. |
| {{CamelHttpQuery}} | {{String}} | Allows to provide URI query parameters as a {{String}} value that overrides the endpoint configuration. Separate multiple parameters using the & sign. For example: {{foo=bar&beer=yes}}. |
| {{Content-Type}} | {{String}} | To set the content-type of the HTTP body. For example: {{text/plain; charset="UTF-8"}}. |
{div}

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")...}} 

{div:class=confluenceTableSmall}
|| Name || Type || Description ||
| {{CamelHttpMethod}} | {{String}} | The HTTP method used, such as GET, POST, TRACE etc. |
| {{CamelHttpUrl}} | {{String}} | The URL including protocol, host and port, etc: {code}http://0.0.0.0:8080/myapp{code} |
| {{CamelHttpUri}} | {{String}} | The URI without protocol, host and port, etc: {code}/myapp{code} |
| {{CamelHttpQuery}} | {{String}} | Any query parameters, such as {{foo=bar&beer=yes}} |
| {{CamelHttpPath}} | {{String}} | Additional context-path. This value is empty if the client called the context-path {{/myapp}}. If the client calls {{/myapp/mystuff}}, then this header value is {{/mystuff}}. In other words its the value after the context-path configured on the route endpoint. |
| {{Content-Type}} | {{String}} | The content type if provided. For example: {{text/plain; charset="UTF-8"}}. |
{div}


h3. Access to Netty types

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:

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

h3. Examples

In the route below we use [Netty HTTP] as a HTTP server, which returns back a hardcoded "Bye World" message. 
{code}
    from("netty-http:http://0.0.0.0:8080/foo")
      .transform().constant("Bye World");
{code}

And we can call this HTTP server using Camel also, with the [ProducerTemplate] as shown below:
{code}
    String out = template.requestBody("netty-http:http://localhost:8080/foo", "Hello World", String.class);
    System.out.println(out);
{code}

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

h3. How do I let Netty match wildcards

By default [Netty HTTP] will only match on exact uri's. But you can instruct Netty to match prefixes. For example
{code}
from("netty-http:http://0.0.0.0:8123/foo").to("mock:foo");
{code}

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: 
{code}
from("netty-http:http://0.0.0.0:8123/foo?matchOnUriPrefix=true").to("mock:foo");
{code}
So now Netty matches any endpoints with starts with {{foo}}.

To match *any* endpoint you can do:
{code}
from("netty-http:http://0.0.0.0:8123?matchOnUriPrefix=true").to("mock:foo");
{code}

h3. Using multiple routes with same port

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.
{code:java|title=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");
{code}

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.
{code:java|title=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");
{code}

h4. Reusing same server bootstrap configuration with multiple routes

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.

{code:xml}
<bean id="nettyHttpBootstrapOptions" class="org.apache.camel.component.netty.NettyServerBootstrapConfiguration">
  <property name="backlog" value="200"/>
  <property name="connectionTimeout" value="20000"/>
  <property name="workerCount" value="16"/>
</bean>
{code}

And in the routes you refer to this option as shown below
{code:xml}
<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>
{code}

h4. Reusing same server bootstrap configuration with multiple routes across multiple bundles in OSGi container

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


{include:Endpoint See Also}
- [Netty]
- [Netty HTTP Server Example]
- [Jetty]