Production use - Proxying eXist-db behind a Web Server

From a security perspective it is recognised best practice to proxy Web Application Servers behind dedicated Web Servers. eXist-db is no exception. This article will provide you with some examples on how to do this.

Introduction

Interesting side-effects of proxying eXist-db behind a Web Server:

Unified web namespace

You can map eXist-db, or an application build on eXist-db, into an existing web namespace. If your website is - http://www.mywebsite.com, then your eXist-db application could be mapped into http://www.mywebsite.com/myapplication/. However, if you are tempted to shorten the URL of WebDAV resources with such a mapping, you will not succeed, due to the specifications of WebDAV that are not designed to handle such cases.

Virtual Hosting

Providing your Web Server supports Virtual Hosting, you should be able to proxy many URLs from different domains onto different eXist-db REST URLs, which may belong to one or more eXist-db instances. This allows a single eXist-db instance to perform virtual hosting.

Examples are provided for:

Nginx

A very small but extremely powerful Web Server which is also simple to configure. It powers some of the biggest sites on the Web. See Using Nginx.

Apache HTTPD

Likely the most prolific Web Server used on the web. See Using Apache HTTPD.

Be aware that many proxies by default limit the maximum size of request bodies, eg. client_max_body_size 1m;. When working with large xml files in eXist-db such a limitation will intefere with its normal operations. To fix this increase the value in line with your application's demands.

Example: Proxying a Web Domain Name to an eXist-db Collection

In this example we look at how to proxy a web domain name onto an eXist-db Collection. We make the following assumptions:

  1. http://www.mywebsite.com is our website domain name address

  2. eXist-db is running in standalone mode (i.e. http://localhost:8088/) on the same host as the Web Server (i.e. http://localhost:80/)

  3. /db/apps/mywebsite.com is the eXist-db collection we want to proxy

  4. Web Server access logging will be written to /srv/www/vhosts/mywebsite.com/logs/access.log

Using Nginx

This needs to be added to the http section of the nginx.conf file:

# header helpers for reverse proxied servers
proxy_set_header        Host                    $host;                          # Ensures the actual hostname is sent to eXist-db and not 'localhost' (needed in eXist-db for server-name in controller-config.xml)
proxy_set_header        X-Real-IP               $remote_addr;                   # The Real IP of the client and not the IP of nginx proxy
proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;
proxy_set_header        nginx-request-uri       $request_uri;                   # The original URI before proxying

# virtual host configuration, reverse proxy to eXist-db
server {
    listen 80;
    server_name *.mywebsite.com;
    charset utf-8;
    access_log /srv/www/vhosts/mywebsite.com/logs/access.log;

    location / {
        proxy_pass http://localhost:8088/exist/apps/mywebsite.com/;
    }
}

Using Apache HTTPD

This needs to be added to your httpd.conf:

<VirtualHost *:80>
    ProxyRequests	    off
    ServerName	    www.mywebsite.com
    ServerAlias     *.mywebsite.com
    ProxyPass	    /	http://localhost:8088/exist/apps/mywebsite.com
    ProxyPassReverse	/	http://localhost:8088/exist/apps/mywebsite.com
    ProxyPassReverseCookieDomain localhost mywebsite.com
    ProxyPassReverseCookiePath /exist /

    RewriteEngine       on
    RewriteRule         ^/(.*)$     /$1   [PT]
</VirtualHost>