Dynamic Content
| The most common way to provide dynamic content on websites is with CGI programs. CGI is a specification of communication between server processes (such as programs that generate dynamic documents) and the server itself. SSIs allow output from CGI programs, or other programs, to be inserted into existing HTML pages. Another way to add dynamic content to your website is to use PHP (PHP Hypertext Preprocessor [the name is recursive]). PHP is an HTML-embedded scripting language designed specifically for web usage. The PHP module for Apache is one of the most popular third-party modules available. CGIBy default, you can put any CGI program on your server in the directory defined by the ScriptAlias directive. CGI programs can be written in any language. The most popular languages for CGI programming are Perl and C. Chapter 27, "Using Perl," provides more information about using the Perl scripting language. These programs must be executable by the default Apache user, which means you must change the mode of the files to 555 so the Apache user can execute them. By default, Apache runs in Ubuntu as a user named apache: chmod 555 program.cgi To execute CGI programs outside the ScriptAlias directory, you must enable the ExecCGI option for that directory. This is done either in your httpd.conf file or in an .htaccess file in the directory. To test whether you have CGI configured correctly, try the CGI program in Listing 20.1. This program is written in Perl and displays the values of the HTTP environment variables. Listing 20.1. environment.pl
If you're going to write CGI programs in Perl, take some time to study the CGI modules that come bundled with Perl. An extensive Perl module library, which contains many modules designed to be used when writing CGIs, is accessible at http://www.cpan.org. If you are using many CGIs written in Perl, examine the mod_perl module. It embeds a Perl interpreter within the Apache server. Using this module results in faster execution times for your CGIs because you don't need to start a new Perl interpreter for each request. You will find information about using mod_perl under the /usr/share/doc/_mod_perl-1.99_12/docs/ directory if you install it from this book's CD-ROMs. Note Always check for security updates and bug fixes if you use CGIs developed by other users or outside developers. Poorly updated and improperly implemented or written CGIs can pose significant security threats in your system. SSIServer-side includes are directives written directly into an HTML page, which the server parses when the page is served to the web client. SSIs can be used to include other files, the output from programs, or environment variables. You can enable SSI with the XBitHack directive. XBitHack can be set to a value of on or off and can be set in either your configuration file or .htaccess files. If the XBitHack directive is on, it indicates that all files with the user execute bit set should be parsed for SSI directives. This has two main advantages. One is that you don't need to rename a file and change all links to that file simply because you want to add a little dynamic content to it. The other reason is more cosmetic: Users looking at your web content can't tell by looking at the filename that you're generating a page dynamically, so your wizardry is just a tiny bit more impressive. Another positive side effect of using XBitHack is that it enables you to control how clients should cache your page. Pages containing SSI statements do not usually contain a Lastmodified HTTP header. Therefore, they will not be cached by proxies or web browsers. If you enable XBitHack, the group-execute bit for files control whether a Last-modified header should be generated. It is set to the same value as the last modified time of the file. Be sure to use this only on files that really are supposed to be cached. Another way to enable SSI is to indicate that files with a certain filename extension (typically .shtml) are to be parsed by the server when they're served. This is accomplished with the following lines in your httpd.conf file: # To use server-parsed HTML files # #AddType text/html .shtml #AddHandler server-parsed .shtml If you uncomment the AddType and AddHandler lines, you tell the server to parse all .shtml files for SSI directives. In addition to these directives, the following directive must be specified for directories in which you want to permit SSI: Options Includes This can be set in the server configuration file or in a .htaccess file. Basic SSI DirectivesSSI directives look rather like HTML comment tags. The syntax is as follows: <!--#element attribute=value attribute=value ... --> The element can be one of several directives, including
The following sections describe each of these directives and their uses. configThe config directive enables you to set various configuration options to determine how the document parsing is handled. Because the page is parsed from top to bottom, config directives should appear at the top of the HTML document. Three configurations can be set with this command:
echoThe echo directive displays any one of the include variables in the following list. Times are displayed in the time format specified by timefmt. Use the var attribute to indicate the variable to be displayed:
execThe exec directive executes a shell command or a CGI program, depending on the parameters you provide. Valid attributes are cgi and cmd:
fsizeThe fsize directive displays the size of a file specified by either the file or virtual attribute. Size is displayed as specified with the sizefmt directive:
flastmodDisplays the last modified date of a file. The desired file is specified as with the fsize directive. includeThe include directive includes the contents of a file. The file is specified with the file and virtual attributes, as with fsize and flastmod. If the file specified is a CGI program and IncludesNOEXEC isn't set, the program is executed and the results are displayed. This is to be used in preference to the exec directive. You can pass a QUERY_STRING with this directivesomething you can't do with the exec directive. printenvIt displays all existing variables and has no attributes. For example, <!--#printenv --> setThis sets the value of a variable, and its attributes are var and value. For example, <!--#set var="animal" value="cow" --> Note All defined CGI environment variables are also allowed as include variables. Note In your configuration files (or in .htaccess), you can specify Options IncludesNOEXEC to disallow the exec directive because this is the least secure of the SSI directives. Be especially cautious when web users are able to create content (such as a guest book or discussion board) and these options are enabled! The variables whose attributes have been set by var and value can also be used elsewhere with some of the following directives. Flow ControlUsing the variables set with the set directive and the various environment and include variables, a limited flow control syntax can be used to generate a certain amount of dynamic content on server-parsed pages. The syntax of the if/else functions is as follows: <!--#if expr="test_condition" --> <!--#elif expr="test_condition" --> <!--#else --> <!--#endif --> expr can be a string, which is considered true if nonempty, or a variety of comparisons between two strings. Available comparison operators are =, !=, <, <=, >, and >=. If the second string has the format /string/, the strings are compared with regular expressions. Multiple comparisons can be strung together with && (AND) and || (OR). Any text appearing between the if/elif/else directives are displayed on the resulting page. An example of such a flow structure follows: <!--#set var="agent" value="$HTTP_USER_AGENT" --> <!--#if expr="$agent = /Mozilla/" --> Mozilla! <!--#else --> Something else! <!--#endif --> This code displays Mozilla! if you're using a browser that passes Mozilla as part of its USER_AGENT string, and it displays Something else! otherwise. |
EAN: 2147483647
Pages: 318