Chapter 357. Undertow Component

undertow:http://hostname[:port][/resourceUri][?options]
undertow:https://hostname[:port][/resourceUri][?options]
undertow:ws://hostname[:port][/resourceUri][?options]
undertow:wss://hostname[:port][/resourceUri][?options]

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

The Undertow component supports 5 options which are listed below.

The Undertow endpoint is configured using URI syntax:

undertow:httpURI

with the following path and query parameters:

The component supports 10 options, which are listed below.

Camel uses the same message headers as the HTTP component. From Camel 2.2, it also uses Exchange.HTTP_CHUNKED,CamelHttpChunked header to turn on or turn off the chuched encoding on the camel-undertow consumer.

Camel also populates all request.parameter and request.headers. For example, given a client request with the URL, http://myserver/myserver?orderid=123, the exchange will contain a header named orderid with the value 123.

The following is a basic example of how to send an HTTP request to an existing HTTP endpoint.

in Java DSL

from("direct:start")
    .to("undertow:http://www.google.com");

or in XML

<route>
    <from uri="direct:start"/>
    <to uri="undertow:http://www.google.com"/>
<route>

In this sample we define a route that exposes a HTTP service at http://localhost:8080/myapp/myservice:

<route>
  <from uri="undertow:http://localhost:8080/myapp/myservice"/>
  <to uri="bean:myBean"/>
</route>

In this sample we define a route that exposes a WebSocket service at http://localhost:8080/myapp/mysocket and returns back a response to the same channel:

<route>
  <from uri="undertow:ws://localhost:8080/myapp/mysocket"/>
  <transform><simple>Echo ${body}</simple></transform>
  <to uri="undertow:ws://localhost:8080/myapp/mysocket"/>
</route>

In this sample, we configure the camel-undertow component to support the HTTP/2 protocol and expose a HTTP service at http://localhost:7766/foo/bar.

The directory structure of this sample is as follows:

├── pom.xml 1
├── README.md
└── src
    └── main
        └── resources
            └── META-INF
                └── spring
                    └── camel-context.xml 2

The following files are important for configuring the camel-undertow component to support the HTTP/2 protocol:

In this example, by using the camel-maven-plugin in the pom.xml file, we can expose a HTTP service at http://localhost:7766/foo/bar when we execute the Maven command mvn camel:run.

We can test this example using the curl command as follows:

$ curl -v --http2 http://localhost:7766/foo/bar
* Trying ::1...
* TCP_NODELAY set
* connect to ::1 port 7766 failed: Connection refused
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 7766 (#0)
> GET /foo/bar HTTP/1.1
> Host: localhost:7766
> User-Agent: curl/7.53.1
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
>
< HTTP/1.1 101 Switching Protocols
< Connection: Upgrade
< Upgrade: h2c
< Date: Sun, 10 Dec 2017 08:43:58 GMT
* Received 101
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< accept: */*
< http2-settings: AAMAAABkAARAAAAAAAIAAAAA
< breadcrumbid: ID-dhcppc1-1512886066149-0-25
< content-length: 16
< user-agent: curl/7.53.1
< date: Sun, 10 Dec 2017 08:43:58 GMT
<
* Connection #0 to host localhost left intact
Sending Response

When you specify localhost in a URL, Camel exposes the endpoint only on the local TCP/IP network interface, so it cannot be accessed from outside the machine it operates on.

If you need to expose a Jetty endpoint on a specific network interface, the numerical IP address of this interface should be used as the host. If you need to expose a Jetty endpoint on all network interfaces, the 0.0.0.0 address should be used.

To listen across an entire URI prefix, see How do I let Jetty match wildcards.

If you actually want to expose routes by HTTP and already have a Servlet, you should instead refer to the Servlet Transport.

The configuration of camel-undertow consumers on WildFly is different to that of standalone Camel. Producer endpoints work as per normal.

On WildFly, camel-undertow consumers leverage the default Undertow HTTP server provided by the container. The server is defined within the undertow subsystem configuration. Here’s an excerpt of the default configuration from standalone.xml:

<subsystem xmlns="urn:jboss:domain:undertow:4.0">
    <buffer-cache name="default" />
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true" />
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true" />
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content" />
            <filter-ref name="server-header" />
            <filter-ref name="x-powered-by-header" />
            <http-invoker security-realm="ApplicationRealm" />
        </host>
    </server>
</subsystem>

In this instance, Undertow is configured to listen on interfaces / ports specified by the http and https socket-binding. By default this is port 8080 for http and 8443 for https.

This has the following implications:

For example, if you configure an endpoint consumer using different host or port combinations, a warning will appear within the server log file. For example the following host & port configurations would be ignored:

from("undertow:http://somehost:1234/path/to/resource")

[org.wildfly.extension.camel] (pool-2-thread-1) Ignoring configured host: http://somehost:1234/path/to/resource

However, the consumer is still available on the default host & port localhost:8080 or localhost:8443.