Fundamentals of Server Side Includes or SSI technology. SSI interface scripts apache SSI include include description tutorial SSI example support SSI directives

#set var value Sets the value of the variable, if the variable does not exist creates. Command format set var=" VARIABLE_NAME "value="(!LANG: ITS_VALUE !}"

For example, this code:

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

Will output the following lines:

The value of the variable SERVER_NAME="site" Change the value: Now the value of the variable SERVER_NAME="discoverer.by.ru"

Of course, replacing standard environment variables may not make sense at all, but assigning your own variables can be convenient, for example:

To use the command at the right place on the page

It looks like this: This is the most visual guide to SSI(Note that special characters in the old version of SSI will be re-encoded to display on the page and not work as expected.

Naturally, you need to define a variable before it is applied 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 or string operations. However, SSI technology supports substitutions, which can be regarded as analogous to 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 brackets can be omitted).

For example:

Put the full path and name of the given page into the NEW_VAR variable and output it to text:

http://website/docs/ssi.html

If it is necessary to include dollar signs, slashes, curly braces and quotation marks in the substitution, they are preceded by a slash:

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

Operator format:

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

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

If the second line is enclosed in a slash ("/"), 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). At the same time, there must be at least one space between the end of the SSI directive and the hyphens of the end of the comment otherwise the server may not correctly recognize the directive, mistaking hyphens and an angle bracket for the end of the command.

Features of SSI scripts

• SSI Server Side Includes translates as server-side inclusion. The name itself displays the main features of SSI:
• SSI instructions do not work on local computers, they are processed only by WEB servers, and how 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 result of execution instead of them. The instructions themselves are not saved in 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 parsed for the content of SSI instructions this is done so as not to slow down the server with unnecessary processing. The file types to be processed are specified in the description of the host. Also, they can be viewed in httpd.conf or srm.conf (if you have access to them). The following lines indicate the parsing of SSI instructions: AddType text/html .shtml AddHandler server-parsed .shtml Usually these are HTM, HTML and SHTML files.
• Sometimes processing SSI directives requires placing an .htaccess file (the name starts with a dot) at the root of the site, with instructions like AddHandler server-parsed .shtml AddHandler server-parsed .html This may be the only way to affect the operation of the server if you are not its administrator.
• Sometimes bad admins forbid the execution of PHP scripts in SSI directives, and instead of the result of the script execution, an inscription like
  ""
  In this case, you need to add the Options +Includes directive to .htaccess. For more information about the .htaccess file, see "Configuring the .htaccess file"
• SSI is not processed in all directories. In order for SSI directives to be processed in a directory, the directory must be described in the access.conf file as Options Indexes Includes (or Options Includes), nested directories 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 page fragment and included in it by the SSI directive should NOT be located in the cgi-bin directory cgi-bin can contain only 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 various ways, in particular to handle the variables set on the page that includes these fragments.
• Usually, 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, it should be borne in mind that HTM and HTML files are indexed by search engines, which means that they can send the visitor to an incomplete fragment of the page (this, of course, is unlikely, since this fragment must have an indexed link), which, in turn, may disappoint him and push him away from the site. There are several ways to avoid such an annoying curiosity:

Scope of SSI.

Usually SSI is used where Frame, Object, Script src=, etc., for example, to include repeating fragments (menus, banner codes, headings) 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 inserted in place by the user agent (browser), then in the case of SSI, the browser receives the page in a ready-made form. The inclusion occurs directly on the server, and this gives rise to the following differences:

• When including the Frame type, Object, Script src=, etc., the visitor can find out the source code of the page, but when SSI-enabling not. Hiding the 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 not with SSI injection. It can also be convenient, as it allows you to split the page into arbitrary fragments and allocate more common places to separate files.
• When including the type Frame, Object, etc., an object in the included fragment can be referred to as FRAGMENT_NAME.OBJECT_NAME, and an object embedded by an SSI instruction as a normal page element so much easier.
• When including the type Frame, Object, etc., you can allow the user to change the contents of objects, but not with SSI injection. This significantly narrows the scope of SSI.
• When you include the Frame type, Object, Script src=, etc., the processing of conditions and other directives occurs on the visitor's computer, and with SSI on the server. Thus, the SSI technology slows down loading: the gain is achieved only if large fragments are either turned on or not turned on, depending on specific conditions (then, although the load on the server processor increases, the load on the communication line decreases).
• Since SSI is performed by the server, the true appearance of the page can only be seen there, which is not convenient. Programs that allow you to get SSI on a 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 direct settings of each specific server, the difference can be of fundamental importance.
• When including the type Frame, Object, Script src=, etc., the included object is loaded only once and, on subsequent inclusion, is taken from the cache. With SSI injection, the fragment is loaded with each new page, slowing down the loading SIGNIFICANTLY: This is already quite bad.
• When including the Frame type, Object, Script src=, etc., the menu is in one file, and with SSI, it is embedded in every page, thereby dispersing the internal link value, and spoiling the whole thing when you want to focus all the link weight on main page.

What to use: Frame, Object, Script src= or SSI is up to you.

Include file foot.htm:

The practical difference between the same page built using different technologies is that each page of IFRAME technology objects looks more complete and is completely independent. This slightly increases the load 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 accelerated (for more on the benefits 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 result. It applies to all professional sites and, if Frame and Object may not meet somewhere, then at least Script src= and (the same inclusion of code contained in a separate file and loaded only once) is used everywhere.

The use of IFRAME cannot completely replace SSI, since SSI allows not only loading fragments by condition (which can be solved with a script), but also, as shown in the example, passing any parameters to them through variables. Without SSI, this can only be done using the POST method or via HTTP_REFERER (the continuation of the file name, after the question mark), for further processing by some script. But the possibilities of such transfer do not go to any comparison with the possibilities of transferring the values ​​of SSI variables. Therefore, the use of SSI may be required even on pages based on frames the more tools available to us, the better and faster the result.

What ssi and what do they eat it with?

Server Side Include (SSI).This thing in WWW-design is extremely necessary and useful, as it greatly facilitates the work of creating and maintaining a Web site.

Server Side Include is translated from English as "included on the server side". This technology allows the Web server to include any other text in the text of your HTML pages: the contents of text files or, for example, the result of CGI scripts (which, as you know, usually formatted as HTML). This "switching on" occurs just before the HTML page text is passed to the user's browser, so that the page visitor is not even aware of this server "fuss".

What is the use of SSI? The benefit is huge. Suppose, on each page of your site, you have placed a list of available sections of the site. Your creation, as it should be, is constantly evolving, and so you decided to add another section. What now, open all the pages in the editor and stupidly add the same thing to the text? A Soviet pioneer (who loves challenges) would do just that, and a smart Web designer would use SSI. To do this, it is enough to create a separate text file (for example, menu.html) and enter the HTML code of the sections list there. Directly into the pages of the site, in the place where the list of sections should be, you need to insert the following instruction:
Note that the syntax of the SSI directives must be followed verbatim. Forget, for example, to put two dashes at the end of the directive - and the server will literally "choke" on it, stopping parsing the page.

When someone wants to view this page, the server will replace the instruction<#include>the contents of the menu.html file. If you change the menu.html file, then all the pages where you used<#include>will update automatically. Note that nothing changes in the HTML files on the Web server's disk - the server inserts the text on the fly before sending the WWW page to the visitor's browser.

Instead of a plain text file name in the instruction<#include>you can specify the name of the CGI script. In this case, the server will first execute the CGI script, and then insert the result of the script into the text of the WWW page. This means that you can implement things like a text-based hit counter or displaying a randomly selected phrase on the page.

There is another indirect benefit of using SSI: because of the use of templates like menu.html mentioned above, WWW pages will be smaller in size, and you can save a lot of time by transferring files to a Web server via FTP.

But not everything is so great. For example, you won't be able to experiment with the SSI mechanism on a machine that doesn't have a Web server installed. SSI functionality is provided by the server, so when viewing HTML files from a local hard drive (for example, C:), your browser will ignore SSI directives - after all, they are ordinary comments from the HTML point of view.

In addition, the server must be configured to support SSI. And there are such greedy providers who begin to demand money for such a setting. It is best not to use their services, since SSI support is enabled by adding a couple of lines to the Apache Web server configuration files and some other simple administrator actions, for which it is a sin to charge money, in my opinion.

Fortunately, there are not very many such providers. Most offer SSI support by default. But keep in mind that on free servers such as Hoom, Tripod, Geocities, Chat.ru SSI is not allowed. Nothing can be done about it :-(

Speaking of server settings. When SSI support is enabled, the server starts to scan all pages for the presence of SSI directives, which increases the load on the server. Therefore, very often system administrators enable SSI only for files with a specific extension - usually .shtml. So if SSI does not work in .html files, try renaming them to .shtml, or better ask your system administrator about it :-)

All in all, SSI is a really useful tool that should not be ignored if you value your time (and money).

What is SSI and what is it eaten with II

With this article I would like to open a new subsection on DVK URL CLUB. "Your column" is designed to collect materials and opinions of our visitors. The first article was written by our moderator of the "Smoke Break" section based on one of the topics on "Smoke Break", in which Alexander explains some of the features of using SSI directives. The author also wants to remind you that SSI instructions can only be used on a server that supports them. Most of the free web hosts don't have this feature and simply don't support SSI.

Preamble
The essence and the simplest techniques in SSI have already been described on this site. As a rule, at the collapse of articles on mastering, you rarely find anything other than a description of a single "include" function in the simplest version.

However, SSI can be safely called a programming language, if not a full-fledged one, but a language. SSI allows you to define conditions and variables, and also knows how to work with so-called environment variables, one of which is $QUERY_STRING, which is actively used when programming in Perl, PHP, and other server scripting languages. This is where the fun begins.

The essence of the phenomenon or the result that the Webmaster has.
By and large, we will now talk about templates. At the next update, it will be enough for the person maintaining the site to add a link to the new page in the table of contents and create a file with plain formatted text without any markup. Agree that it is very convenient :)

Technology: Conditional directives and $QUERY_STRING environment variable.
In general, there is some kind of index.shtml template, which is the following:





... Cool tags and cool graphics...

Here, in principle, problems with understanding should not arise, but further - the most interesting. Let me explain that the value of the $QUERY_STRING variable is determined by the content of the query string after the "?" sign, i.e. http://maste.ru/section/index.shtml?page1.
second and key part:

I think decryption is needed. We have five directives, of which three are conditional and two are normal includes:
The contents of the query string are checked for the presence of the "?something" construct, and if the result is positive, the second directive is executed.
A file with a name identical to the contents of the string is connected, for example, if the query string looks like this: "http://maste.ru/razdel/index.shtml?page1", then the file "page1.txt" is connected, which lies in the same directory as the index file.
It is executed if there is no content like "?something" in the string, and the URL looks like this: "http://maste.ru/razdel/index.shtml" or like this: "http://maste.ru/razdel/ ", and proceeds to the execution of the fourth directive.
The file is connected by default, containing, as a rule, the table of contents of the section, i.e. links to section files, which should look like this: link to page number 1, etc.
Completion of the condition.
Next comes the count of the bottom of the html code:
... some more Cool tags and cool graphics...

How will it work?
The following files are dumped into the folder:
index.shtml (terminal type);
default.txt (list of links page 1 and te de and te pe and hetetepe:);
files page1.txt, ..., page571756.txt until you get bored (in principle, the name can be anything, the main thing is that it matches the content after the "?" in the corresponding link).
If you intend to use SSI directives inside ordinary files, then it is better to do them in the same way .shtm, .shtml, and do not forget to correct the extensions in the code of the index.shtml file.

Here! Use on health :)