...
Netty
...
HTTP
...
Component
...
Available
...
as
...
of
...
Camel
...
2.12
...
The
...
netty-http
...
component
...
is
...
an
...
extension
...
to
...
...
component
...
to
...
facilitiate
...
HTTP
...
transport
...
with
...
...
.
...
This
...
camel
...
component
...
supports
...
both
...
producer
...
and
...
consumer
...
endpoints.
Warning |
---|
This component is deprecated. You should use Netty4 HTTP. |
Info | ||
---|---|---|
| ||
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. Notice Netty4 HTTP reads the entire stream into memory using |
Maven users will need to add the following dependency to their pom.xml
for this component:
Code Block | ||||
---|---|---|---|---|
| ||||
{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} |
URI format
The URI scheme for a netty component is as follows
Code Block |
---|
netty-http:http://localhost:8080[?options] {code} |
You
...
can
...
append
...
query
...
options
...
to
...
the
...
URI
...
in
...
the
...
following
...
format,
...
?option=value&option=value&...
Info | ||
---|---|---|
| ||
You may be wondering how Camel recognizes URI query parameters and endpoint options. For example you might create endpoint URI as follows - Keep also in mind that you cannot specify endpoint options using dynamic headers (like |
HTTP Options
Info | ||
---|---|---|
| ||
Important: This component inherits all the options from Netty. So make sure to look at the Netty documentation as well. |
Div | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
}}
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 {{
|
The NettyHttpSecurityConfiguration
has the following options:
Div | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||
|
Message Headers
The following headers can be used on the producer to control the HTTP request.
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 | |||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||
}}
{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}
|
Access to Netty types
This component uses the org.apache.camel.component.netty.http.NettyHttpMessage
...
as
...
the
...
message
...
implementation
...
on
...
the
...
...
.
...
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.
Code Block |
---|
below: {code} org.jboss.netty.handler.codec.http.HttpRequest request = exchange.getIn(NettyHttpMessage.class).getHttpRequest(); |
Examples
In the route below we use Netty HTTP as a HTTP server, which returns back a hardcoded "Bye World" message.
Code Block |
---|
{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
...
...
as
...
shown
...
below:
Code Block |
---|
} 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.
...
How
...
do
...
I
...
let
...
Netty
...
match
...
wildcards
...
By
...
default
...
...
...
will
...
only
...
match
...
on
...
exact
...
uri's.
...
But
...
you
...
can
...
instruct
...
Netty
...
to
...
match
...
prefixes.
...
For
...
example
Code Block |
---|
} from("netty-http:http://0.0.0.0:8123/foo").to("mock:foo"); {code} |
In
...
the
...
route
...
above
...
...
...
will
...
only
...
match
...
if
...
the
...
uri
...
is
...
an
...
exact
...
match,
...
so
...
it
...
will
...
match
...
if
...
you
...
enter
...
...
but
...
not
...
match
...
if
...
you
...
do
...
...
.
...
So
...
if
...
you
...
want
...
to
...
enable
...
wildcard
...
matching
...
you
...
do
...
as
...
follows:
Code Block |
---|
{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 Block |
---|
} 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 {{ |
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 Block | ||||||
---|---|---|---|---|---|---|
| ||||||
{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 Block | ||||||
---|---|---|---|---|---|---|
| ||||||
{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 {{ |
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
...
...
...
consumers
...
to
...
refer
...
and
...
reuse
...
the
...
same
...
options
...
across
...
all
...
consumers.
Code Block | ||||
---|---|---|---|---|
| ||||
{code:xml} <bean id="nettyHttpBootstrapOptions" class="org.apache.camel.component.netty.NettyServerBootstrapConfiguration"> <property name="backlog" value="200"/> <property name="connectionTimeoutconnectTimeout" value="20000"/> <property name="workerCount" value="16"/> </bean> {code} |
And
...
in
...
the
...
routes
...
you
...
refer
...
to
...
this
...
option
...
as
...
shown
...
below
Code Block | ||||
---|---|---|---|---|
| ||||
{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>
|
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.
Using HTTP Basic Authentication
The Netty HTTP consumer supports HTTP basic authentication by specifying the security realm name to use, as shown below
Code Block |
---|
{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. h3. Using HTTP Basic Authentication The [Netty HTTP] consumer supports HTTP basic authentication by specifying the security realm name to use, as shown below {code} <route> <from uri="netty-http:http://0.0.0.0:{{port}}/foo?securityConfiguration.realm=karaf"/> ... </route> {code} |
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
...
{{LoginModule}}s
...
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.
...
Specifying
...
ACL
...
on
...
web
...
resources
...
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:
Code Block | ||||
---|---|---|---|---|
| ||||
{code:xml} <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="/foo/*" value="*"/> <entry key="/foo/admin/*" value="admin"/> <entry key="/foo/guest/*" value="admin,guest"/> </map> </property> <!-- exclusions is used to define public urls, which requires no authentication --> <property name="exclusions"> <set> <value>/foo/public/*</value> </set> </property> </bean> {code} |
The
...
constraint
...
above
...
is
...
define
...
so
...
that
...
- access
...
- to
...
- /
...
- *
...
- is
...
- restricted
...
- and
...
- any
...
- roles
...
- is
...
- accepted
...
- (also
...
- if
...
- user
...
- has
...
- no
...
- roles)
...
- access
...
- to
...
- /admin/*
...
- requires
...
- the
...
- admin
...
- role
...
- access
...
- to
...
- /
...
- guest/
...
- *
...
- requires
...
- the
...
- admin
...
- or
...
- guest
...
- role
...
- access
...
- to
...
- /public/*
...
- is
...
- an
...
- exclusion
...
- which
...
- means
...
- no
...
- authentication
...
- is
...
- needed,
...
- and
...
- is
...
- therefore
...
- public
...
- for
...
- everyone
...
- without
...
- logging
...
- in
...
To
...
use
...
this
...
constraint
...
we
...
just
...
need
...
to
...
refer
...
to
...
the
...
bean
...
id
...
as
...
shown
...
below:
Code Block | ||||
---|---|---|---|---|
| ||||
{code:xml} <route> <from uri="netty-http:http://0.0.0.0:{{port}}/foo?matchOnUriPrefix=true&securityConfiguration.realm=karaf&securityConfiguration.securityConstraint=#constraint"/> ... </route> {code} {include:Endpoint See Also} - [Netty] - [Netty HTTP Server Example] - [Jetty] |
Include Page | ||||
---|---|---|---|---|
|