Skip to main content

OutSystems Platform configurations in reverse proxy scenarios

These configurations are implemented in several layers through different technologies.These solutions have been internally tested.

Some of these configurations require direct manipulation of OutSystems Platform system database tables. Do not manipulate these tables in any other form not described in this document or indicated by OutSystems offical support. Unexpected changes in these tables may result in service disruption.

A - Request Header Manipulation

This occurs at a reverse proxy level. It translates the Internet exposed address into the internal application address.

To the Internet, your application is known and reachable by the address However, it’s served as server.local/myapp by the application server.

There are several different ways to accomplish this task depending on your reverse proxy. Below is an example configuration using a reverse proxy with Apache HTTP Web Server serving an application. For other technologies, please check the appropriate documentation.

< VirtualHost *:80 >
ProxyRequests off
ProxyPreserveHost off 
ProxyPass / http://server.local/
ProxyPassReverse / http://server.local/
< / VirtualHost > 

B - Referenced Content Exposure

OutSystems applications can reference content outside the application context URL path. An example of this are the resources in RichWidgets. These also need to be exposed by the reverse proxy the same way the main application is.

The image below shows the ‘myapp’ application, and the ‘Richwidgets’ and ‘EPA_Taskbox’ references also exposed.

Depending on the level of URL manipulation, these references may also need the following:

  • Rewrite resource’s URL inside the code
  • Request Header Manipulation

C - End-to-end SSL and SSL Offloading

When serving secure applications through a reverse proxy, OutSystems supports the following setups:

  1. End-to-End SSL
    Encrypting the communication end-to-end. This can be done by installing an SSL certificate in every OutSystems Platform application server, and also in the reverse proxy. It can be the same certificate if it is multi-server or wildcard.
  2. SSL Offload
    Install an SSL certificate in the reverse proxy. This keeps the traffic unencrypted between the reverse proxy and the internal application servers. It also removes the need to manage certificates in each application server. This technique is called SSL offloading.

In SSL Offload scenarios, two configurations need to be applied.

  1. All application screens and web flows must have HTTP Security set to ‘None’ in development time.
  2. Add a custom HTTP header at the reverse proxy level. The header should instruct OutSystems Platform to build the URLs with the HTTPS protocol.

    To do so, first create the ‘OutSystems.HubEdition.HTTPtoHTTPSproxyHeader’ parameter in the OutSystems database:
    insert into OSSYS_PARAMETER (Name,Val) values (‘OutSystems.HubEdition.HTTPtoHTTPSproxyHeader’,’X-Forwarded-Proto: https’)

    Description: It allows you to set a special header that, whenever present, will allow the server to process the request as if it was secure.

    Parameter: OutSystems.HubEdition.HTTPtoHTTPSproxyHeader

    Values: ’X-Forwarded-Proto: https’ (You can use a header [checks for presence of the header] or a header: value [checks for presence of the header with a specific value])

    Default: (none)
  3. OutSystems services and application server have to be restarted for this setting to apply.
  4. Configure a rule in the reverse proxy that adds the parameter X-Forwarded-Proto with the above defined value of https. This way OutSystems Platform knows to which traffic needs HTTPS URLs.
    1. If Apache is being used as a reverse proxy, add the following line to the proxy configuration file:

RequestHeader set X-Forwarded-Proto https

D - Rewrite URLs in resources

Web application resources, like HTML, JavaScript and CSS, include absolute and relative URLs.

Typical reverse proxies only manipulate HTTP headers. They don’t parse web resource code, therefore this code isn’t manipulated. The HTML received by the client will contain absolute URLs based on what OutSystems Platform generates, not considering reverse proxy transformations.

In OutSystems applications, a resource URL like CSS or JavaScript is generated from the request host header plus the application context.

In the example below, the URL for the application is to be changed by adding an extra path “apps” after the request host header. This scenario is used when there is a requirement to serve several applications under a common path.

This change will invalidate all absolute URLs in the resources (HTML, CSS and JavaScript).

To implement this requirement, we need to rewrite all URLs in the resources. This must be done in a request post-processing step before it is sent to the client, preferably at the reverse proxy level.

You can access here the configuration required on an Apache Web Server to implement this scenario.

This configuration covers both application runtime, development, and console administration (Service Center and LifeTime).

E - Disable content compression

Application resources such as CSS, javascript, HTML and others are served compressed by the application servers. This feature reduces the payload and thus, the time to load the application.

In a reverse proxy scenario where the content requires rewrite, the code cannot be compressed at the application server level.

To disable compression, follow these instructions:

Platform Level

Disable Platform own Ajax compression, first create if it doesn't exist, the ‘OutSystems.HubEdition.CompressHttpAjaxResponse’ parameter in the OutSystems database:

insert into OSSYS_PARAMETER (Name,Val) values (‘OutSystems.HubEdition.CompressHttpAjaxResponse’,’False’)

Description: If set to false, the AJAX responses will not be compressed by Outsystems (if IIS is configured to compress, AJAX responses will be compressed).

Parameter: OutSystems.HubEdition.CompressHttpAjaxResponse

Values: True/False Default:True

Application Server Level

Microsoft IIS

  1. To do so, first create if it doesn't exist, the ‘IIS.SetHttpCompression’ parameter in the OutSystems database:

    insert into OSSYS_PARAMETER (Name,Val) values (‘IIS.SetHttpCompression’,’False’)

    Description: If set to "False" instructs ConfigurationTool not to enable IIS compression settings.

    Parameter: IIS.SetHttpCompression

    Values: True/False Default:True

  2. In IIS Management Console, disable the static and dynamic content compression

JBoss AS 7.1.1

  1. In the OutSystems servers, edit the file '/opt/jboss-as-7.1.1.Final/bin/'
  2. Set the 'org.apache.coyote.http11.Http11Protocol.COMPRESSION' to 'off'
  3. Restart Jboss

Wildfly 8.2

  1. In the OutSystems servers, edit the file '/opt/wildfly-8.2.0.Final/standalone/configuration/standalone-outsystems.xml'
  2. Comment the following line to look like this:
    <!--filter-ref name="gzipFilter" predicate="exists['%{o,Content-Type}'] and regex[pattern='(?:text/javascript|text/css|text/html|text/xml|text/json|application/json|application/javascript)(;.*)?', value=%{o,Content-Type}, full-match=true]"/-->
  3. Restart wildfly


More information

To learn more about how to set up your OutSystems Platform with a reverse proxy check the OutSystems Platform in Reverse Proxy scenarios guide.