...
| Anchor | ||||
|---|---|---|---|---|
|
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 is 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.
| Anchor | ||||
|---|---|---|---|---|
|
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.
...
<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-HostX-Forwarded-Proto(required only when proxying to a different protocol)X-Forwarded-For
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 (for example, HTTPS to HTTP), but additional configuration is required to enable HTTPS on the reverse proxy (refer to the comments in the example).
...
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.
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
| Anchor | ||||
|---|---|---|---|---|
|
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 dtp -> <PROTOCOL>://<DTP_HOST>/grs:8080
Data collector
<PROTOCOL>://<PROXY>:8082 /dtp/dc -> <PROTOCOL>://<DTP_HOST>:8082
Enterprise Pack
<PROTOCOL>://<PROXY>:8314 /dtp/ep -> <PROTOCOL>://<DTP_HOST>:8314
...
<PROTOCOL>://<PROXY>/dtp/<WEBAPP> -> <PROTOCOL>://dtp:<PORT>/<WEBAPP>
Requirements
Configure your reverse proxy to send the following headers to DTP:
...
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, that is, 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 (for example, HTTPS to HTTP), but additional configuration is required to enable HTTPS on the reverse proxy (refer to the comments in the example).
...
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.
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
...
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.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
Data Collector is the component that accepts reports from testing and code analysis tools. In order for it to work properly, you will need to configure it to work with your reverse proxy server. See Reverse Proxy Configuration in the Data Collector section for more details.
| Anchor | ||||
|---|---|---|---|---|
|
If your organization uses DTP Enterprise Pack, you will need to configure it to work with your reverse proxy server. See the Reverse Proxy section of the DTP Enterprise Pack Network Settings page for more details.
| Anchor | ||||
|---|---|---|---|---|
|
Issue: 413 error from NGINX - "Entity too large"
...
| Code Block |
|---|
client_max_body_size 512M; |
| Anchor | ||||
|---|---|---|---|---|
|
- JMS Event Broker URLs will not be accessible through the proxy server because the proxy server’s ports are not JMS ports.
...