In this section:

Introduction

Reverse proxies are intermediaries between backend servers and clients. They accept incoming requests from a client, modify the request per the proxy's configuration, and send the modified request to the server. As a result, reverse proxies can improve server performance and increase infrastructure security.

There are several ways to configure a reverse proxy, but DTP supports port-to-port and path-to-port configurations. The "path" in path-to-port configurations are referred to as "context paths." In either method, the reverse proxy server is configured to forward user requests to the port where the applications are hosted. Additionally, you must either configure the reverse proxy server to send the required headers to DTP or update the DTP Tomcat server configuration.

Port-to-Port Configuration

In a port-to-port configuration, the reverse proxy is configured to accept client traffic on one port, and direct them to one of the DTP application ports. This type of configuration limits the implementation to the number of available ports on the proxy server. The following formats demonstrate how the port-to-port configuration may be applied for DTP applications.

DTP Report Center:

<PROTOCOL>://<PROXY>:8080 -> <PROTOCOL>://<DTP_HOST>:8080

Data Collector:

<PROTOCOL>://<PROXY>:8082 -> <PROTOCOL>:// <DTP_HOST>:8082

Enterprise Pack:

<PROTOCOL>://<PROXY>:8314 -> <PROTOCOL>:// <DTP_HOST>:8314

Requirements

The reverse proxy must be configured to add X-Forwarded- headers to the request directed to DTP so that the application can properly generate URLs. The X-Forwarded- headers affect HTTP redirects for login, navigation, and links sent to third-party applications, such as ALM systems. The following X-Forwarded- headers are required:

X-Forwarded-Host
X-Forwarded-Proto (required only when proxying to a different protocol)

Forwarding Requests

Refer to your reverse proxy server documentation for details on how to forward requests. The following examples are intended to provide basic guidance on reverse proxy server configuration.

Forwarding Configuration with NGINX

In the following configuration, all underlying services/webapps should be running on the local machine over HTTP (Data Collector uses HTTPS by default). The configuration supports protocol redirection (e.g., HTTPS to HTTP), but additional configuration is required to enable HTTPS on the reverse proxy (refer to the comments in the example).

http {

  # Simplifies setting the "Connection" header.
  # Required by Enterprise Pack application.
  map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
  }

  # Add necessary headers for WebSocket proxying.
  # Required by Enterprise Pack application.
  proxy_http_version 1.1;
  proxy_set_header Upgrade    $http_upgrade;
  proxy_set_header Connection $connection_upgrade;

  # Add necessary "X-Forwarded-" proxy headers.
  proxy_set_header X-Forwarded-Proto  $scheme;
  proxy_set_header X-Forwarded-Host   $http_host;

  # ssl_certificate     /path/to/cert;
  # ssl_certificate_key /path/to/key;

  server {
    listen 9080;
    # listen 9443 ssl;
    location / {
      # Proxy incoming requests to DTP.
      proxy_pass http://localhost:8080/;
    }
  }

  server {
    listen 9082;
    # listen 9082 ssl;
    location / {
      # Proxy incoming requests to Data Collector.
      proxy_pass http://localhost:8082/;
    }
  }

  server {
    listen 9314;
    # listen 9314 ssl;
    location / {
      # Proxy incoming requests to Enterprise Pack.
      proxy_pass http://localhost:8314/;
    }
  }
  
}

The configuration should be saved with LF line endings. The comments nested in configuration blocks can cause parsing issues when CRLF line endings are used.

See Network Settings for additional information about using DTP Enterprise Pack in a reverse proxy environment.

See Configuring Data Collector for additional information about using Data Collector in a reverse proxy environment.

Reverse Proxy Support for WebSockets

Refer to the following documentation if you are configuring your NGINX reverse proxy server for WebSockets communication: http://nginx.org/en/docs/http/websocket.html

Path-to-Port Configurations (Context Paths)

In a path-to-port configuration, client traffic is sent to the proxy at a specific context path and is directed to one of the DTP application ports. The path-to-port configuration is not limited to the number of ports available on the proxy server, which can direct requests to many different backend servers based on the context path in the request. For this reason, the standard HTTP ports (80 for HTTP and 433 for HTTPS) are often used in the configuration.

The following formats demonstrate how the context path configuration may be applied for DTP applications.

DTP Report Center

<PROTOCOL>://<PROXY>:8080/grs -> <PROTOCOL>://<DTP_HOST>/grs

Data collector

<PROTOCOL>://<PROXY>:8082 -> <PROTOCOL>:// <DTP_HOST>:8082

Enterprise Pack

<PROTOCOL>://<PROXY>:8314 -> <PROTOCOL>:// <DTP_HOST>:8314

It's not required, but all DTP and Enterprise Pack servers are generally configured under a common context path with individual services/webapps served on a sub-context path:

Requirements

Configure your reverse proxy to send the following headers to DTP:

X-Forwarded-Host
X-Forwarded-Prefix
X-Forwarded-Proto (required only when proxying to a different protocol)

The header values should match the context path field in the Enterprise Pack network configuration settings (see to Network Settings) and/or the value of the <dc-reverse-proxy-path> element in the Data Collector configuration file (see Configuring Data Collector). The Host header should be the host of the original request, i.e., the reverse proxy host.

Forwarding Requests

Refer to your reverse proxy server documentation for details on how to forward requests. The following examples are intended to provide basic guidance on reverse proxy server configuration.

Forwarding Request for Context Path Configurations on NGINX

In the following configuration, underlying services/webapps should be running on the local machine over HTTP (Data Collector uses HTTPS by default). The configuration supports protocol redirection (e.g., HTTPS to HTTP), but additional configuration is required to enable HTTPS on the reverse proxy (refer to the comments in the example).

 http {

  # Simplifies setting the "Connection" header.
  # Required by Enterprise Pack application.
  map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
  }

  # Simplifies setting the "X-Forwarded-Prefix" header.
  map $request_uri $x_forwarded_prefix {
    ~^/dtp/(dc|ep|grs|licenseserver|pstsec|pst|tcm)/?   /dtp/$1;
    ~^/dtp/?.*                                          /dtp;
  }

  server {
    listen 80;
    
    # listen 443 ssl;
    # ssl_certificate     /path/to/cert;
    # ssl_certificate_key /path/to/key;

    location /dtp/ {

      # Redirect to app with a trailing slash if not present.
      if ($request_uri = $x_forwarded_prefix) {
        return 301 $request_uri/;
      }

      # Add necessary headers for WebSocket proxying.
      # Required by Enterprise Pack application.
      proxy_http_version 1.1;
      proxy_set_header Upgrade    $http_upgrade;
      proxy_set_header Connection $connection_upgrade;

      # Add necessary "X-Forwarded-" proxy headers.
      proxy_set_header X-Forwarded-Proto  $scheme;
      proxy_set_header X-Forwarded-Host   $http_host;
      proxy_set_header X-Forwarded-Prefix $x_forwarded_prefix;

      # Proxy incoming requests to the DTP server by default.
      proxy_pass http://localhost:8080/;

      location /dtp/dc/ {
        # Proxy incoming requests to Data Collector.
        proxy_pass http://localhost:8082/;
      }

      location /dtp/ep/ {
        # Proxy incoming requests to Enterprise Pack.
        proxy_pass http://localhost:8314/;
      }
      
    }
  }
}

The configuration should be saved with LF line endings. The comments nested in configuration blocks can cause parsing issues when CRLF line endings are used.

See Network Settings for additional information about using DTP Enterprise Pack in a reverse proxy environment.

See Configuring Data Collector for additional information about using Data Collector in a reverse proxy environment.

Reverse Proxy Support for WebSockets

Refer to the following documentation if you are configuring your NGINX reverse proxy server for WebSockets communication: http://nginx.org/en/docs/http/websocket.html

Forwarding Request for Context Path Configurations on Apache HTTPD

In the following configuration, DTP_HOSTNAME should be provided as an environment variable and the underlying services/webapps should be running on HTTP (Data Collector uses HTTPS by default). The configuration supports protocol redirection (e.g., HTTPS to HTTP), but additional configuration is required to enable HTTPS on the reverse proxy (refer to the comments in example).

 Listen 80
 
# Listen 443 https
# SSLEngine on
# SSLVerifyClient none
# SSLProxyCheckPeerCN off
# SSLCertificateFile /path/to/cert
# SSLCertificateKeyFile /path/to/key
 
# Automatically add the following headers to proxied requests.
# - X-Forwarded-For
# - X-Forwarded-Host
# - X-Forwarded-Server
ProxyAddHeaders on
 
# Enable the "RewriteRule" directive used for WebSocket proxying.
RewriteEngine on  

# Redirect to app with a trailing slash if not present.
<LocationMatch "^/dtp/(grs|licenseserver|pstsec|pst|tcm)$">
    RewriteRule .* "%{REQUEST_URI}/" [L]
</LocationMatch> 

<Location /dtp>
    RequestHeader set X-Forwarded-Prefix /dtp
    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME} 
    ProxyPass "http://${DTP_HOSTNAME}:8080"
    ProxyPassReverse "http://${DTP_HOSTNAME}:8080"
</Location>
 
<LocationMatch "^/dtp/(?<app>dc|ep|grs|licenseserver|pstsec|pst|tcm)">
    RequestHeader set X-Forwarded-Prefix "/dtp/%{MATCH_APP}e"
</LocationMatch>
 
<Location /dtp/dc>
    ProxyPass "http://${DTP_HOSTNAME}:8082"
    ProxyPassReverse "http://${DTP_HOSTNAME}:8082"
</Location>
 
<Location /dtp/ep>
    ProxyPass "http://${DTP_HOSTNAME}:8314"
    ProxyPassReverse "http://${DTP_HOSTNAME}:8314"
 
    # mod_proxy_wstunnel is required for WebSocket proxying.
 
    # Rewrite for Enterprise Pack WebSockets.
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]
    RewriteCond %{REQUEST_URI} ^/dtp/ep/(socket\.io/.*) [NC]
    RewriteRule .* "ws://${DTP_HOSTNAME}:8314/%1" [P,L]
 
    # Rewrite for Node-RED WebSockets.
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]
    RewriteRule .* "ws://${DTP_HOSTNAME}:8314%{REQUEST_URI}" [P,L]
</Location>

The order of the <Location> and <LocationMatch> directives is important. All of the <Location> and <LocationMatch> directives that match the incoming request are merged at runtime.

Known Issues and Constraints

JMS Event Broker URLs will not be accessible through the proxy server because the proxy server’s ports are not JMS ports.

Page tree

Reverse Proxy Support

Introduction

Port-to-Port Configuration

Requirements

Forwarding Requests

Forwarding Configuration with NGINX

Reverse Proxy Support for WebSockets

Path-to-Port Configurations (Context Paths)

DTP Report Center

Data collector

Enterprise Pack

Requirements

Forwarding Requests

Forwarding Request for Context Path Configurations on NGINX

Reverse Proxy Support for WebSockets

Forwarding Request for Context Path Configurations on Apache HTTPD

Known Issues and Constraints