Destinations

A "Destination" is one or more web/application servers that requests can be forwarded/proxied to.

Target Servers

A destination has one or more target servers, which can be sticky or not - i sticky, requests from the same user/client will always be routed to the same server unless that server is down, in which case another target server will be selected instead.

Target servers can be either added to the configuration manually, or they can be retrieved from an application cluster or dynamically from a Consul service registry which allows you to dynamically scale target servers up and down, e.g. in a Docker or cloud environment.

SSL / Transport Settings

A destination has its own SSL settings, meaning traffic between the gateway and the target servers can be encrypted if needed - additionally, you have the option to allow HTTP/2 request toward the application server, or to use HTTP1.1 Keepalive or not.

Cookiesnapper

Cookies originating from the servers, such as HTTP session cookies - e.g. JSESSIONID, ASP.NET_SessionId or PHPSESSID can be intercepted and removed from the response and instead placed in the Ceptor session. It will then be added for future requests before being sent to the server.
This has the advantage that towards the client/browser only a single session cookie exists, so there is no risk of session content getting out of sync in case a user logs off another user logs in. Also, it ensures that all HTTP sessions can be removed at once.

Limits

You can set up limits for the destination (and override them for individually configured target servers) to limit the number of concurrent connections, connection queues, timeouts etc.

Authentication

You can configure different authentication methods used for the communication between the gateway and the server, e.g. basic auth, SSL client certificate, SPNEGO or Bearer Tokens or you can add custom plugins for even more fine-grained control.

Ping

You can configure pinging - decide which URL to requests and which HTTP method to use for it, how often to do it, and what HTTP response codes are considered as valid. You can also create a small script which gets access to the response contents, and this can then verify the actual response returned to check that it contains the expected data - this script then decides if the individual target server should be considered in working state or not.