Skip to content

Handling Multiple Apps at the Same Domain

What happens if you have a non-WordPress site at the same domain as your QUIC-Cloud-enabled WordPress site? Or you have a WordPress site that you don't want to use with QUIC.cloud?

For example, let's say you have a forum at www.example.com/forum, and your WordPress site at www.example.com.

This may or may not be problematic. Because the whole domain must be pointed to QUIC.cloud, the WordPress site will be fine, but the forum could potentially experience caching issues, especially if it is powered by forum software that uses LSCache, or there are special rules in the .htaccess file that must be followed.

But why?

There are a few places where the non-WordPress, non-QUIC-Cloud site could encounter problems. For simplicity, let's continue to use www.example.com/forum as an example.

  • In order to use QUIC.cloud, the DNS for the WordPress domain (in this case www.example.com) must be pointed to QUIC.cloud. As a result, any web app that shares the same domain will also be routed through QUIC.cloud.
  • A domain's .htaccess file is not read or processed by QUIC.cloud. Instead, QUIC.cloud gets everything it needs from the WordPress and LSCache plugin configuration. That means, any rewrite rules that might be in the .htaccess file for www.example.com/forum will be ignored.

Here's what happens with caching in this scenario:

  • Static cache: All static content from the domain, regardless of which web app it is from, will be cached by QUIC.cloud. And if there were special .htaccess rules for caching the forum's static content, QUIC.cloud won't know about them.
  • Dynamic cache with LSCache: If www.example.com/forum is using LSCache, QUIC.cloud may cache the forum's dynamic content if there is a x-litespeed-cache-control header present. But this is not really desired behavior, since QUIC.cloud doesn't have any of the corresponding .htaccess rules, and unpredictable things may happen.
  • Dynamic cache without LSCache: If the forum is not using LSCache, then QUIC.cloud will always return a cache miss, and the request will be forwarded to the origin server.

In a nutshell

At best, requests for the non-WordPress application will be forwarded on to the origin server, resulting in extra travel time for the request, and slowing down access to the app.

At worst, some of the non-WordPress app's content may be incorrectly cached, allowing the site's visitors to see content that was not meant for them.

So, what do I do?

If possible, we recommend putting each site in its own subdomain (for example, the forum could be moved to forum.example.com).

This way, you can point the DNS for your WordPress site (www.example.com) to QUIC.cloud. The forum at forum.example.com, could remain pointing to your hosting provider, and QUIC.cloud would have no impact on it whatsoever.


Last update: February 3, 2024