Using Server-Side Includes on Both Apache and Nginx

See also:

I recently received an email about my SSI posts in this blog, which finally inspired me to start work on that project again. And what I realized is that for a few months at least, I'm going to have to maintain the same website using SSIs on two servers - one using Apache, the other using Nginx. So how can I do that?:

<!--#set var="SERVERTEST" value="${NGINX_VERSION}y" -->
<!--#if expr="${SERVERTEST} = y" -->
    <!--#include virtual="/" -->
<!--#else -->
    <!--#include virtual="/" -->
<!--#endif -->

This isn't an ideal solution for a couple reasons: first, Apache throws an SSI error (usually seen as "[an error occurred while processing this directive]"), and second, this can only choose between Nginx and Apache - there are other web servers out there that support SSIs. But in the end, the correct footer is displayed on both Apache and Nginx (and we can suppress the SSI error messages).

The idea of trying to solve the multi-server problem when I have only a two-server problem smacks a bit of pre-mature optimization, but I'd really have preferred to have a third clause for an unrecognized server type. I want this in part in case Nginx's support breaks on an upgrade - because if it does, this if-then-else declares the server Apache even if it isn't. But every three-way logic attempt I tested resulted in A) more errors, and B) the wrong footer being displayed in some contexts. This works, so I'm going to call it done.

Getting Rid of SSI Error Messages

This message can be over-ridden two ways. In an individual file, use <!--#config errmsg="<!-- an error occurred while processing this directive -->" -->. This will allow you to see the errors in the source code in your browser without mangling the appearance of your web page. Or get rid of them entirely across the entire server, by adding SSIErrorMsg "" to your server configuration, or as above, make it SSIErrorMsg "<!-- SSI error -->".

In Nginx, add ssi_silent_errors on; to your configuration.

Making the errors entirely invisible is a good idea on public-facing web servers. Making them highly visible is a good idea on test servers ... because you're only debugging on the test server, right? Not on your public servers?