SSI interface apache scripts SSI include include description tutorial SSI example support for SSI directives. What is SSI

#set var value Sets the value of a variable if there is no variable creates. Command Format set var=" VARIABLE_NAME " value=" ITS_VALUE !}"

For example, this code:

SERVER_NAME variable value=" " » Change the value: Now the value of the variable SERVER_NAME=" »

Will output the following lines:

The value of the variable SERVER_NAME = “site” Let’s change the value: Now the value of the variable SERVER_NAME = “discoverer.by.ru”

Of course, replace the standard ones environment variables It may not make sense at all, but it can be convenient to assign your own variables, for example:

To apply the command at the right place on the page

It looks like this: This is the most visual aid to SSI(note, Special symbols V old version The SSIs will be recoded to appear on the page rather than work as expected.

Naturally, you need to define a variable before using it on the page.

The ability to work with variables is one of the most important features of SSI. Without it, this technology would not be so widespread.

SSI operations and operators.

SSI does not support math calculations and string operations. However, SSI technology supports substitutions, which can be regarded as an analogue of concatenation. Substitution allows you to use environment variables as parameters of SSI directives and combine the values ​​of variables and strings (concatenate). When substituting, variables are enclosed in curly braces " {} ", and are preceded by a dollar sign " $ " (sometimes the parentheses can be omitted).

For example:

Places the full path and name of this page into the NEW_VAR variable and displays it in text:

Http://site/docs/ssi.html

If necessary, include dollar signs, slashes, curly braces and quotation marks, they are preceded by a slash:

#if, #elif, #else and #endif – Conditional statements. Allow you to execute code or display text on the page depending on the result of a logical comparison. Code that does not meet the condition will not appear in any way, even when viewing the “source”.

Operator format:

A condition is either a string that is true if it is not empty, or a set of string comparison operators. Operators can be:

Equality = Inequality != Less < Less than or equal to <= More > Greater than or equal to >= Denial (not true) !

If the second line is enclosed in slashes ("/"), it is a regular expression. For example, the condition is true if the first line contains at least one occurrence of the second line.

You can combine multiple comparison operators using the operators && (“logical AND”) and || (“logical OR”). Parentheses are used to group conditions. To include variables in a condition, they are preceded by a dollar sign. For example:

Page requestedOpera browserbrowser Microsoft Internet ExplorerNetscape Navigator browsersearch robot

Result:

Page requested by Netscape Navigator browser

Attention: Any SSI directive must begin with the characters (end of comment). In this case, between the end of the SSI directive and the hyphens of the end of the comment there must be, according to at least, one space otherwise the server may not correctly recognize the directive, mistaking the hyphens and angle brackets for the end of the command.

Features of SSI scripts

• SSI Server Side Includes is translated as server side inclusion. The name itself reflects the main features of SSI:
• SSI instructions do not work on local computers, they are processed only by WEB servers and what the page will look like in the end can only be seen by placing it on the server and loading it from there in the browser. Before issuing a page, the server reads it line by line, and, finding SSI instructions, processes it, inserting the execution result instead. The instructions themselves are not saved on the page received by the visitor.
• SSI cannot include files from another domain.
• SSI is not supported by all servers and server owners must indicate its support in the host description.
• SSI is not processed in all files. In many files, the content is simply not analyzed for the content of SSI instructions; this is done so as not to slow down the server with unnecessary processing. The file types processed are specified in the host description. You can also view them in httpd.conf or srm.conf (if you have access to them). The following lines indicate the analysis of SSI instructions: AddType text/html .shtml AddHandler server-parsed .shtml Typically these are HTM, HTML and SHTML files.
• Sometimes processing SSI directives requires placing a .htaccess file (the name begins with a dot) in the root of the site, with instructions like AddHandler server-parsed .shtml AddHandler server-parsed .html This can be the only way affect the operation of the server if you are not its administrator.
• Sometimes unkind admins prohibit the execution of PHP scripts in SSI directives, and instead of the result of the script execution, a message like
  ""
  In this case, you need to add the Options + Includes directive to .htaccess More information about the .htaccess file, you can look at “Setting up the .htaccess file”
• SSI is not processed in all directories. In order for a directory to process SSI directives, the directory must be described in the access.conf file as Options Indexes Includes (or Options Includes), subdirectories inherit the option and do not require a separate entry. Not everyone has access to this file, however, there is a general unwritten rule: on many hosts the content is divided into 2 root directories: cgi-bin and WWW. In files in the cgi-bin directory, no files are (usually) checked for SSI instructions and no files (even those included by ) are displayed in browsers. Therefore, a file that is a fragment of a page and included in it by the SSI directive should NOT be located in the cgi-bin directory cgi-bin can only contain cgi scripts, since they are not included in the page directly (only the result of their execution is included).
• SSI directives are processed not only in the files requested by the visitor, but also in the fragments included in them, if they have an extension for which checking for the presence of SSI directives is allowed. This can be used in a variety of ways, particularly to handle variables set on the page that includes these fragments.
• Typically, any files in the WWW directory can be included using the SSI include directive, so the fragments themselves can be stored in files with any extension. However, please note that HTM and HTML files are indexed search engines, which means they can send the visitor to an incomplete fragment of the page (this, of course, is unlikely, since for this there must be an indexed link to this fragment), which, in turn, can disappoint him and push him away from the site. There are several ways to avoid this annoying curiosity:

Scope of SSI.

Typically, SSI is used in the same places where Frame, Object, Script src=, etc., for example, to include repeating fragments (menus, banner codes, headers) in a WEB page. However, the activation mechanism is completely different. If in Frame, Object, Script src=, etc. the included file is simply issued by the server and is already inserted in place by the user agent (browser), then in the case of SSI the browser receives the page already finished form. Enabling occurs directly on the server, and this creates the following differences:

• When you enable the type Frame, Object, Script src=, etc., the visitor can find out the source code of the page, but when SSI-enabled, the visitor cannot. Concealment source code may be useful to the author.
• When including the type Frame, Object, Script src=, etc., the logical completeness of the included objects is required, but with SSI embedding it is not. This can also be convenient, as it allows you to split the page into arbitrary fragments and allocate a larger number of common spaces into separate files.
• When enabling the type Frame, Object, etc., the object located in the included fragment can be accessed as FRAGMENT_NAME.OBJECT_NAME, and the object embedded by the SSI instruction can be accessed as a regular page element - this is simpler.
• When enabling the Frame, Object, etc. type, you can allow the user to change the contents of objects, but with SSI injection, this is not the case. This significantly narrows the scope of SSI.
• When you enable the type Frame, Object, Script src=, etc., processing of conditions and other directives occurs on the visitor’s computer, and with SSI on the server. Thus, SSI technology slows down the loading: the gain is achieved only if large fragments are either included or not included, depending on specific conditions (then, although the load on the server processor increases, the load on the communication line decreases).
• Since SSI is executed by the server, the true appearance of the page can only be seen there, which is not convenient. Programs that allow you to receive SSI for local computer, do not give exactly the same option, at least due to the difference in type variables DOCUMENT_URI. And taking into account the immediate settings of each specific server, the difference can be of fundamental importance.
• When enabling the type Frame, Object, Script src=, etc., the included object is loaded only once and, the next time it is enabled, is taken from the cache. With SSI injection, a fragment is loaded with each new page, SIGNIFICANTLY slowing down loading: This is already really bad.
• When you enable the type Frame, Object, Script src=, etc., the menu is in one file, and with SSI, it is embedded in each page, thereby dispersing the internal referential significance, and spoiling the whole thing when you need to concentrate all link weight on the home page.

What to use: Frame, Object, Script src= or SSI is a personal matter for everyone.

Include file foot.htm:

The practical difference between the same page built using different technologies is only that each page of IFRAME technology objects looks more complete and is completely independent. This slightly increases the loading time of the first page, but due to caching, repeated fragments do not have to be loaded with the next page and further loading is significantly faster (for more information about the advantages of Frame, see “If you don’t like frames, then you don’t know how to prepare them”) . The combination of two switching technologies gives the highest quality results. It is used on all professional sites and, if Frame and Object may not meet somewhere, then at least Script src= and (same inclusion of code contained in separate file and loaded only once) is used everywhere.

The use of IFRAME cannot completely replace SSI, since SSI allows you not only to load fragments by condition (which can be solved with a script), but also, as shown in the example, to pass any parameters to them through variables. Without SSI this can only be done POST method or via HTTP_REFERER (continuation of the file name, after the question mark), for further processing by some script. But the capabilities of such transmission cannot be compared with the capabilities of transmitting the values ​​of SSI variables. Therefore, SSI may be required even on frame-based pages than more tools available to us, the better and faster the result is.

I want to tell you the basics server technologies side includes or ssi.
ssi translates to "server side inclusions". This technology helps save a lot of time when creating a website and uploading it to the server. In general, ssi is designed to make the work of a webmaster as easy as possible.

Here, for example, is a very real situation:
You have a site, which, of course, does not use ssi, with a number of pages close to:, let's take at least 50 pages. So, on each page you, as a good webmaster who cares about his visitors, have placed a text menu. And suddenly, for some reason, the name of some section changed, or perhaps you wanted to add a new one. What now to re-open all fifty pages and rewrite everything again and again?! In our case, this is, unfortunately, the only solution, although some good editors will be able to ease this overwhelming burden (and how to make it easier!, homesite, for example).

So, you wouldn’t have such a problem if you used ssi technology. Let me explain: if instead of a text menu on all pages something like

And in the file "(www)/ssi/menu_txt.html" there would be the contents of this menu, then in order to add or change a section you would only need to change the contents of just one file menu_txt.html. As you probably already guessed, all pages instead of “comment”

The code from menu_txt.html will be inserted.

Syntax of ssi directives.

The syntax of ssi directives is:
All directives are enclosed in a comment

The main difference between an ssi directive and a comment is the "#" symbol immediately(!) after "

and nothing else!

Here is a list of some ssi "functions" (they are written immediately after the "#" symbol)

include

Includes the text (code, content) of the specified document/file in this document. The location of files on the server is indicated using the following attributes:

file - you must specify the path relative to this document, that is, the included document/file must be located either in the same directory as this document, or in directories lower/higher (some_catalog/, ../some_catalog).
virtual - you can specify both a relative (as in the case of file) and absolute path (may contain /some_catolog or ../some_catalog).

include allows you to include the result of cgi scripts, as well as access them with a given query string. For example,

Sets the value of a variable. A variable is declared using the var attribute, and its value is specified using the value attribute.

variable a will have the value variable.
Or you can do this:

Variable a will be equal to varia$(c)
In order to substitute a variable, you need to enclose it in curly braces and put $ in front of it all. If you want the dollar sign ($) to be displayed simply as a symbol and not to denote a variable, then put a slash () in front of it

echo

prints the value of the variable specified in the var attribute.

that is, instead of this code, the value of the variable a is inserted

Examples of using ssi.

"> , html"> !}

Document body

As you can see from this example, using ssi is not so difficult, and moreover, it is very useful.

Technical aspects of using ssi.

It is worth saying a few words about the technical support that is necessary to use ssi. If you simply create a file on your local disk with the correct ssi commands and open it in your browser, then no inclusions will occur, since all expressions are likefor the browser they are pure comments. The so-called “inclusions” occur at the stage of processing the document by the server, before sending it to the user. In our case, there is no such stage (processing of the document by the server) at all. So, in order for you to fully experience all the benefits of ssi on your local computer, you need a “home” web server.
And here's another thing: not every hosting provider supports ssi. This is usually a problem with free hosting. But some of them, even if they allow you to use ssi, require some kind of payment for this, for example, placing advertising on the site.

Almost every non-professional website begins its existence as several HTML documents interconnected by cross-references. Many people go into information eternity in this state. But some amateur sites still become popular, acquire more information content, and increase in volume. Sometimes they grow to tens or even hundreds of pages. But in essence they remain a set of documents formed once and for all.

Maintaining and updating such a site is a real torment for its owner. A page, as a rule, consists of several blocks, and some of them are unchanged for all pages of the site. This is the header, navigation menu, ad unit, page footer. If you want to change something in one of these permanent blocks, you will have to do it manually on each page of the site. The pleasure is very doubtful. Often interesting ideas remain unrealized precisely because of the large amount of editing of dozens of individual pages. SSI makes this job much easier. In addition, SSI technology allows you to do something else that is fundamentally impossible to do using HTML. Using SSI is simple, although knowledge of HTML will help a lot. If you're not scared, then go ahead!

First of all, let's decipher the abbreviation SSI - Server Side Includes. In Russian, “server-side inclusions.” All clear? Then let's end this... Although it would be better to explain. SSI are directives inserted into HTML code that control the web server. When encountering such SSI inserts in a file, the web server performs certain actions. For example, adding HTML code from another file, generating pages on the fly depending on the browser type, and much more.

In order for the server to know that a page contains SSI inserts, it must have a special extension: *.shtml or *.shtm, although this is determined by the server configuration. Most often it is *.shtml that is used. The fact that the server supports SSI is usually indicated in the hosting or tariff description. But it doesn't hurt to check. To do this, we will create two files - first. shtml and second.html. In the file first. shtml copy six lines:

laquo;-//W3C//DTD HTML 4.01 Transitional//EN">

In the file second. html we will write just one line:

Works!

Now let’s upload these pages to the server and write “www.your_site/first.shtml” in the address bar of the browser. If the server supports SSI, then after opening the file we will see the message “Working!” If it says instead, congratulations too! SSI works, but the SSI insert cannot be processed. For example, you might have inserted extra spaces into the code or named the files differently. Most likely, the server is running a Unix system, and for it second. html and Second. html - two big differences.

If nothing is displayed at all, but SSI support is declared, then the easiest way is to contact technical support. Maybe something else is used instead of the *.shtml extension, or SSI needs to be explicitly allowed in the site settings. In any case, hosting specialists will try to help you.

So, how can SSI help with website maintenance? The main delicacy is as follows. We can store any fragment that is repeated on several pages on the server in a single copy! To do this, let's place this fragment in a separate file, for example fragment.html. This file is not needed,

And other attributes of a “full-fledged” html document. There should only be a fragment of the code itself, which will then be inserted into place.

Now, anywhere on any page of the site where this fragment is needed, we write an SSI insert:

The file must be in the same directory as the main file. If you want to move all the insert files into a separate directory, you will have to use another command, which specifies the full path to the fragment file relative to the current directory:

Thus, in the main file you can leave only the “skeleton” of the page, for example, a wireframe table and the main text, and add all permanent blocks through SSI inserts. The full page will be generated by the web server “on the fly”, as if from individual bricks. However, the user will receive a full page on their computer, without the slightest sign of SSI being used. If you change something in a snippet, it will automatically appear on all pages where it is used.

Are you still thinking? Then, especially for you in this article, we will look at such goodies that there will be no doubt about using SSI.

SSI (Server Side Includes) is a technology that allows you to conveniently “assemble” web pages from parts, insert the results of executing CGI scripts into them, and add other elements of dynamics to the pages.

What files are processed as SSI, how to add your files

By default, the web server only checks files with the *.shtml extension for SSI instructions. For example, put the SSI commands in the index.shtml file and it will work immediately. If there is a need to check other files for the presence of SSI, the corresponding extensions for checking can be added by placing the following instruction in the .htaccess file:

.ext1 here is the extension of files that should be checked for the presence of SSI. It is not recommended to add the .html and .htm extensions, since in this case the server will check all html files for the presence of SSI inserts. This can lead to a completely pointless load on the server.

Restrictions

All SSI directives are available to hosting users, with the exception of one restriction for subscribers who use a tariff that does not provide for running their own CGI scripts. For these clients, running scripts is also not available through SSI instructions. That is, in Apache terms, the NoExec option applies to them.

How does SSI work and what is it used for?

Novice users can mainly use SSI technology for two purposes: to “glue together” a page from parts of html code and to run scripts in order to place the results of their work on the created html page. In the first case, the corresponding files are read from the server disk and inserted into the code of the page from which the SSI code was called. In the second case, the web server, having found the SSI instruction, runs a script located on disk and inserts the result of the script into the final page.

Let's take a closer look:

“Gluing together” a page from parts of html code. It is used to avoid duplicating the same html code in multiple web pages. For example, you can include the entire design in SSI inclusions, which are included in a specific html file, which will contain only the text of a specific page.

Let’s place the “header” of the web page (design elements, menus, necessary links and other elements that are present on all pages) into the header.inc file, and place the bottom of the web page (the final part of the design) into the footer.inc file. Next, let's create a file called index.shtml, which will look like this:

And here we will have the main text of the page;

It is assumed that we have placed html code in the inclusion files, at least like start/end tags , , and so on. As a result, the user will receive a page that will first include the contents of the header.inc file, then the words “And here we will have the main text of the page” and then the contents of the footer.inc file.

This use of SSI is convenient from the point of view of not having to constantly insert the same html code into newly created pages, as well as from the point of view of the convenience of changing the main elements of the site - we change the html code in one place, which immediately changes on all pages according to throughout the site.

Running scripts and placing the results of their work on the created html page. Thus, you can place almost any functionality on the page, for example, in Perl (or another programming language supported by the hosting).

For example, you have a script counter that shows how many visitors visited your page and it is located at /cgi-bin/count.pl. Let's include the result of his work in a web page. To do this, we will place the following SSI code in the code of the html page:

As a result, the counter that the script displayed will be placed on the page that the user sees /cgi-bin/count.pl.

A complete list of SSI commands can be found in the description of the Apache module mod_include

More examples of using SSI

SSI instructions can be used for more than just running scripts and including files. SSI also allows you to work with web server environment variables, manipulate dates, execute commands based on conditions, and so on. You will find a good description of the most popular uses of SSI commands on the CIT Forum server.

Diagnosing errors when using SSI

If, when using SSI commands on your html pages, you see the message "", this indicates an error occurred when processing the SSI instruction by the web server.

Possible reasons for this error.