Home arrow HTML arrow Introduction to Conditional SSI

Introduction to Conditional SSI

Did you know that you could use condition statements in Server Side Includes? If not read this article to read about this useful and somewhat unknown feature.

Author Info:
By: John Miller
Rating: 4 stars4 stars4 stars4 stars4 stars / 5
April 29, 2003

print this article

Did you know that you could use condition statements in Server Side Includes? If not read this article to read about this useful and somewhat unknown feature.

While many of you are familiar with SSI (Server Side Includes) and its tremendous usefulness as a server feature, did you know that the technology supports conditions? Imagine being able to give your SSI code logic, so it executes different commands, depending on variables such as browser type, time of day, referring URL, and whatever else can be accessed and compared in Perl. Something like that would be nothing less than revolutionary, and fortunately, possible!

SSI are "codes" you place on your page that the server picks up and executes. The most common use of SSI is to include a file on the page:

<!--#include file="afile.htm" -->

The above command will cause the file "afile.htm" to be inserted and displayed, as if it were manually added to the page.

Adding Condition to the Mix

This is what we're here for- to learn how to supply SSI with a little intelligence. Time to unveil the four flow-control statements of Server Side Includes:

<!--#if expr="expression"-->
<!--#elif expr="expression"-->

They work as you would expect with any if/else statements. In JavaScript, the above would be equivalent in logic to "if", "else if", and "else", respectively. The last command is an odd ball; it serves no particular purpose except that's it's needed at the end of each conditional SSI definition. Take a look at the following example, which embeds two different files onto the page, depending on whether the user is using Internet Explorer or not:

<!--#if expr="${HTTP_USER_AGENT} = /MSIE/" -->
<!--#include file="iebar.htm" -->
<!--#else -->
<!--#include file="defaultbar.htm" -->
<!--#endif -->

Got your attention now, didn't I? By using conditional SSI, with the environmental variable HTTP_USER_AGENT as the condition to test for, the above example allows us to display browser specific content in such a versatile way that no client side language (such as JavaScript) can match. It's SSI with a brain baby!

Taking things one step further

Let's now build on what we have so far, and create a more refined example that discriminates not only between browser type, but browser version as well. How about a SSI code that differentiates between IE 4, NS 4, and neither?

<!--#if expr="${HTTP_USER_AGENT} = /MSIE [4-9]/"-->
You are using IE 4 or above<BR>
<!--#elif expr="${HTTP_USER_AGENT} = /Mozilla\/[4-9]/"-->
You are using Netscape 4 or above<BR>
<!--#else -->
You are using something other than IE 4+ or NS 4+<BR>
<!--#endif -->

If you're not familiar with Perl programming, then parts of the above code undoubtedly look alien to you. Without this being a Perl tutorial, in a nutshell, regular expressions is used to extract out the relevant browser info in HTTP_USER_AGENT. Assuming you're using IE 6 on Windows, for example, this variable would contain:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

which you can display on your page using the SSI code:

<!--#echo var="HTTP_USER_AGENT"-->

Use a different browser, and the output would be different.

As you can see, SSI is more than just embedding static content, but can do so dynamically as well. The examples shown above are just a peek into the possibilities...how smart your SSI codes are now depends on your knowledge of Perl programming. Either way, it's time to get crackin'!

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

All HTML Tutorials
More By John Miller

blog comments powered by Disqus

- Does HTML5 Need a Main Element?
- Revisiting the HTML5 vs. Native Debate
- HTML5: Not for Phone Apps?
- HTML5 or Native?
- Job Hunting? Freelancer.com Lists This Quart...
- HTML5 in the News
- Report: HTML5 Mobile Performance Lags
- The Top HTML5 Audio Players
- Top HTML5 Video Tutorials
- HTML5: Reasons to Learn and Use It
- More of the Top Tutorials for HTML5 Forms
- MobileAppWizard Releases HTML5 App Builder
- HTML5 Boilerplate: Working with jQuery and M...
- HTML5 Boilerplate Introduction
- New API Platform for HTML5

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials