Feature Launch: Reverse Proxy

We are very excited to announce the launch of our newest feature: reverse proxies!

There are times when you will want to host content on another provider, but have it nested under your main domain (instead of a subdomain). A prime example of this is having a WordPress blog. For SEO reasons, it’s generally preferable to host your blog as path in your root domain rather than at blog.domain.com.

And this is now possible with reverse proxies!

In fact, this blog itself is managed by WordPress. Our WordPress server is only available via VPN, and we use the very wonderful Simply Static plugin to export the content into an S3 bucket. For performance reasons, we then put a CDN in front of that. This means that our WordPress install is basically a static site generator (reducing our hosting costs, improving performance, and reducing security risks).

As always, you can manage Reverse Proxies via the API.

We’ve said it before, and we’ll say it again: we eat our own dog food at Revenue HQ. Revenue HQ hosts Revenue HQ, and we use a reverse proxy to map https://revenuehq.com/blog to our CDN (which is hosted at https://blog.revenuehq.org).

Features:

• Visitor and Session IDs will be enforced (as for any other page view).
• All requests to reverse proxied endpoints will be logged and tracked (as for any other page view).
• Standard referral tracking works out of the gate, including an ability to define explicit referral parameters that should be applied for anyone viewing proxied data.
• You can define any path prefix that should be prepended to the request made to the proxy host. By default, the matching path_prefix is used as the proxy_prefix. In our example, we host the content of this blog in a folder on S3 bucket called “blog” — so we use the default. If, instead, we were to host this content on a root directory, we would change proxy_prefix to be “/”.
  • If set, the proxy_prefix completely replaces path_prefix in the request made to the proxy server.
• You can send arbitrary / custom headers to the proxied endpoint. All header names will be stripped of leading and trailing whitespace, and will be converted to all lowercase. Header values will be left untouched.

If there are path collisions, reverse proxies take precedence over redirects and landing pages. Furthermore, if multiple proxies share part of a path prefix, the most specific matching path prefix will be chosen.

That is, you can have a reverse proxy set up to connect /blog to Server A, and /blog/legal to Server B. Requests to /blog/legal/privacy will route to Server B, whereas requests to /blog/privacy will route to Server A.