A reverse proxy is usually used to have a single point of access for the front end - or client facing - side of a service. Reverse proxies are typically implemented in a way to increase security, performance and reliability. They also allow to have the same service on multiple origin servers - or nodes - without the web client knowing about this architecture and complexity.
Using INETAPP with a reverse proxy is required in a multi-node environment when using additional servers to scale up the available workforce and provide better performance for parallel access of many users. A reverse proxy can also be used to simply provide a static, client facing access point to the INETAPP server in a DMZ.
It is recommended to forward the following headers to the original server:
X-Forwarded-Proto
X-Forwarded-Host
X-Forwarded-Port
X-Forwarded-Context
The HAProxy requires the following options:
# if the application is running using standard https ports http-request set-header X-Forwarded-Port 443 http-request set-header X-Forwarded-Proto https if { ssl_fc } # if the application is available at a specific subcontext # e.g. https://mycompany.com/subcontext http-request set-header X-Forwarded-Context /subcontext # Setting the host is non standard http-request set-header X-Forwarded-Host %[req.hdr(Host)]
The NGinx requires the following options/*, which are also documented here*/:
# if the application is running using standard https ports proxy_set_header X-Forwarded-Port 443; proxy_set_header X-Forwarded-Proto https; # if the application is available at a specific subcontext # e.g. https://mycompany.com/subcontext proxy_set_header X-Forwarded-Context /subcontext; # Setting the host is non standard proxy_set_header X-Forwarded-Host $remote_addr;
The Apache requires the following options:
# if the application is running using standard https ports Header set X-Forwarded-Port 443 Header set X-Forwarded-Proto https # if the application is available at a specific subcontext # e.g. https://mycompany.com/subcontext Header set X-Forwared-Context /subcontext
The IIS has a process that requires multiple steps to enable forwarding the headers.
URL rewrite > Manage Server Variables... > Add
and add the following headers:HTTP_X_FORWARDED_PROTO
HTTP_X_FORWARDED_HOST
HTTP_X_FORWARDED_PORT
HTTP_X_FORWARDED_CONTEXT
Server variable name | Value | Replace |
---|---|---|
HTTP_X_FORWARDED_PORT | {SERVER_PORT} | True |
HTTP_X_FORWARDED_CONTEXT | {URL} | True |
HTTP_X_FORWARDED_HOST | {HTTP_HOST} | True |
HTTP_X_FORWARDED_PROTO | https (only if HTTPS is enabled) | True |
The resulting web.config
should look like this:
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="ReverseProxyInboundRule1" stopProcessing="true"> <match url="^api/v1/inet(.*)" /> <action type="Rewrite" url="http://localhost:9000{R:1}" /> <serverVariables> <set name="HTTP_X_FORWARDED_PORT" value="{SERVER_PORT}" /> <set name="HTTP_X_FORWARDED_CONTEXT" value="{URL}" /> <set name="HTTP_X_FORWARDED_HOST" value="{HTTP_HOST}" /> <set name="HTTP_X_FORWARDED_PROTO" value="https" /> </serverVariables> </rule> </rules> </rewrite> </system.webServer> </configuration>
Note: The IIS requires the header fields to be uppercase and combined by underscore instead of a hyphen.