| Relación de Módulos mod_include mod_cgi mod_expires |
Relación de Directivas Options XBitHack AddType AddHandler BrowserMatchNoCase |
Este CÓMO (HOWTO) apareció primero en Apache Today (http://www.apachetoday.com/) como una serie de tres artículos.
Este artículo trata de las instrucciones Server Side Includes, denominadas normalmente SSI. En este artículo se explica la configuración del servidor para permitir SSI e introduce algunas técnicas básicas para añadir contenido dinámico en las páginas HTML, utilizando SSI.
En la última parte del artículo, trataremos sobre algunos aspectos más avanzados que se pueden hacer con SSI como, por ejemplo, declaraciones condicionales en las directivas SSI.
SSI (Server Side Includes) son directivas que se pueden incluir en las páginas HTML y que son evaluadas por el servidor mientras las páginas son servidas. Permiten generar contenido dinámicamente en una página HTML sin tener que enviar la página completa al servidor mediante una interfaz común de acceso (CGI) o con alguna otra tecnología dinámica.
La decisión de cuándo usar SSI o cuándo tener las páginas generadas completamente por medio de otro programa depende, normalmente, de la cantidad de elementos estáticos que forman la página y de cuánto se necesita recalcular cada vez que la página es procesada. SSI es una buena fórmula de añadir pequeñas piezas de información. Pero si la mayor parte de la página es generada al mismo tiempo que se procesa, se recomienda buscar alguna otra solución.
Para permitir las instrucciones SSI en tu servidor debes
tener la siguiente directiva, bien en el fichero httpd.conf o bien en .htaccess:
Options +Includes
Con esto el servidor Apache procesa ficheros con las directivas SSI.
No se procesa cualquier fichero. Se debe codificar en Apache
qué ficheros serán procesados. Hay dos maneras de proceder. Se puede configurar el
servidor Apache para procesar los ficheros que tengan una extensión particular como, por
ejemplo, .shtml, con las directivas:
AddType text/html .shtml
AddHandler server-parsed .shtml
La desventaja de esta aproximación es que si se quieren
añadir directivas SSI a páginas ya creadas, se deberán cambiar los nombre de estas
páginas y, consecuentemente, todos los enlaces a las mismas, dándoles la extensión .shtml,
para que las directivas puedan ser procesadas.
El otro método es usar la directiva XBitHack:
XBitHack on
La directiva XBitHack provoca que el servidor
Apache procese ficheros con las directivas SSI si son ejecutable. Así pues, para añadir
las directivas SSI en páginas ya creadas, en vez de tener que cambiar el nombre del
fichero, solamente se necesita hacer el fichero ejecutable usando el comando chmod.
chmod +x pagename.html
Un pequeño comentario sobre lo que no se debería hacer.
Algunas personas recomiendan configurar Apache para que procese todos los ficheros .html
mediante SSI, así no habrá confunsión con los ficheros con extensión .shtml.
Estas personas quizás no han oído nada sobre la directiva XBitHack. Se debe
tener en cuenta que con esta manera de proceder se está requiriendo que el servidor
apache lea a lo largo de cada línea de los ficheros que se envían al cliente, incluso si
no contienen ninguna directiva SSI. Esto puede provocar lentitud en los procesos y no es
la mejor manera de actuar.
Por supuesto, en Windows, no existe la posibilidad de hacer ejecutable un fichero lo que limita un poco las posibilidades de configuración.
En su configuración por defecto, Apache no envía la última fecha de modificación o el tamaño del contenido de la cabecera HTTP en las páginas SSI, porque estos valores son difíciles de calcular para contenidos dinámicos. Esto puede impedir que el documento se almacene en la memoria caché, provocando una mayor lentitud en su presentación por el cliente. Hay dos formas de solucionar esto:
XBitHack Full. Esto
provoca que Apache determine la última fecha de modificación mirando únicamente la
fecha del fichero original devuelto, ignorando la fecha de modificación de cualquier otro
fichero incluido.Las directivas SSI tienen la siguiente sintaxis:
<!--#elemento atributo=valor atributo=valor ... -->
Su formato es el mismo que el de un comentario en HTML, de esta forma si no están bien formadas, el navegador las ignorará, pero permanecerán visibles en el formato fuente de HTML. Si la directiva SSI está correctamente configurada será reemplazada por su resultado correspondiente.
El elemento puede ser uno de un número determinado, veremos algo más sobre esto en el próximo apartado de esta serie. Por ahora, aquí están algunos ejemplos de lo que se puede hacer con SSI.
<!--#echo var="DATE_LOCAL" -->
El elemento echo presenta el valor de una
variable. Hay un número determinado de variables estándar, que incluyen todo el conjunto
de variables de entorno que son accesibles mediante programas CGI. También se pueden
definir variables específicas mediante el elemento set.
Si el formato en el que se presenta la fecha no es el
preferido se puede usar el elemento config, con el atributo timefmt,
para modificar este formato.
<!--#config timefmt="%A %B %d, %Y" -->
Fecha actual <!--#echo var="DATE_LOCAL" -->
Última fecha de modificación del fichero <!--#flastmod file="index.html" -->
Este elemento está también sujeto a configuración con el
formato timefmt.
Presentar los resultados de una interfaz común de acceso (CGI) es uno de los usos más comunes de SSI, como, por ejemplo, el favorito de la mayoría, presentar el resultado de un contador de visitas.
<!--#include virtual="/cgi-bin/counter.pl" -->
A continuación se presentan algunos ejemplos específicos de otros usos que se pueden presentar en documentos HTML con SSI.
Earlier, we mentioned that you could use SSI to inform the user when the document was most recently modified. However, the actual method for doing that was left somewhat in question. The following code, placed in your HTML document, will put such a time stamp on your page. Of course, you will have to have SSI correctly enabled, as discussed above.
<!--#config timefmt="%A %B %d, %Y" -->
This file last modified <!--#flastmod file="ssi.shtml" -->
Of course, you will need to replace the ssi.shtml
with the actual name of the file that you're referring to. This can be inconvenient if
you're just looking for a generic piece of code that you can paste into any file, so you
probably want to use the LAST_MODIFIED variable instead:
<!--#config timefmt="%D" -->
This file last modified <!--#echo var="LAST_MODIFIED" -->
Para saber más detalles sobre el formato timefmt,
puede acceder a su buscador favorito y buscar ctime. La sintaxis es la misma.
If you are managing any site that is more than a few pages, you may find that making changes to all those pages can be a real pain, particularly if you are trying to maintain some kind of standard look across all those pages.
Using an include file for a header and/or a footer can reduce
the burden of these updates. You just have to make one footer file, and then include it
into each page with the include SSI command. The include element
can determine what file to include with either the file attribute, or the virtual
attribute. The file attribute is a file path, relative to the current
directory. That means that it cannot be an absolute file path (starting with /), nor
can it contain ../ as part of that path. The virtual attribute is probably
more useful, and should specify a URL relative to the document being served. It can start
with a /, but must be on the same server as the file being served.
<!--#include virtual="/footer.html" -->
Frecuentemente combinaremos las dos cosas, colocando la
directiva LAST_MODIFIED inside a footer file to be included. SSI directives
can be contained in the included file, and includes can be nested - that is, the included
file can include another file, and so on.
In addition to being able to config the time
format, you can also config two other things.
Usually, when something goes wrong with your SSI directive, you get the message
[se ha producido un error mientras se procesaba esta directiva]
If you want to change that message to something else, you can
do so with the errmsg attribute to the config element:
<!--#config errmsg="[It appears that you don't know how to use SSI]" -->
Hopefully, end users will never see this message, because you will have resolved all the problems with your SSI directives before your site goes live. (Right?)
And you can config the format in which file
sizes are returned with the sizefmt attribute. You can specify bytes
for a full count in bytes, or abbrev for an abbreviated number in Kb or Mb,
as appropriate.
I expect that I'll have an article some time in the coming
months about using SSI with small CGI programs. For now, here's something else that you
can do with the exec element. You can actually have SSI execute a command
using the shell (/bin/sh, to be precise - or the DOS shell, if you're on
Win32). The following, for example, will give you a directory listing.
<pre>
<!--#exec cmd="ls" -->
</pre>
o, en Windows
<pre>
<!--#exec cmd="dir" -->
</pre>
You might notice some strange formatting with this directive
on Windows, because the output from dir contains the string ``<dir>''
in it, which confuses browsers.
Note that this feature is exceedingly dangerous, as it will
execute whatever code happens to be embedded in the exec tag. If you have any
situation where users can edit content on your web pages, such as with a ``guestbook'',
for example, make sure that you have this feature disabled. You can allow SSI, but not the
exec feature, with the IncludesNOEXEC argument to the Options
directive.
In addition to spitting out content, Apache SSI gives you the option of setting variables, and using those variables in comparisons and conditionals.
La mayor parte de los aspectos presentados en este artículo solamente son válidos para la versión 1.2 o posteriores de Apache. Naturalmente, se recomienda actualizar cuanto antes mejor. Adelante, este es un buen momento. Esperaremos.
Usando la directiva set, se pueden fijar
variable para usarlas posteriormente. We'll need this later in the discussion, so we'll
talk about it here. La sintaxis para esto es la siguiente:
<!--#set var="name" value="Rich" -->
In addition to merely setting values literally like that, you
can use any other variable, including, for example, environment variables, or some of the
variables we discussed in the last article (like LAST_MODIFIED, for example)
to give values to your variables. You will specify that something is a variable, rather
than a literal string, by using the dollar sign ($) before the name of the variable.
<!--#set var="modified" value="$LAST_MODIFIED" -->
Para colocar el signo del dolar como valor dentro de una variable, es necesario escaparlo con el backslash.
<!--#set var="cost" value="\$100" -->
Por último, if you want to put a variable in the midst of a longer string, and there's a chance that the name of the variable will run up against some other characters, and thus be confused with those characters, you can place the name of the variable in braces, to remove this confusion. (It's hard to come up with a really good example of this, but hopefully you'll get the point.)
<!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
Now that we have variables, and are able to set and compare
their values, we can use them to express conditionals. This lets SSI be a tiny programming
language of sorts. mod_include provides an if, elif,
else, endif structure for building conditional statements. This
allows you to effectively generate multiple logical pages out of one actual page.
La estructura de las construcciones condicionales es:
<!--#if expr="test_condition" -->
<!--#elif expr="test_condition" -->
<!--#else -->
<!--#endif -->
Una test_condition (condición de prueba) puede ser
alguna clase de comparación lógica - comparando un valor dado con otro o probando el
"valor de verdad" de un valor particular. (Una cadena dada es verdadera si no
está vacía). Para poder consultar una lista completa de los operadores de comparación
disponibles, se puede consultar la documentación de mod_include. A
continuación se presentan algunos ejemplos de cómo se pueden usar estas construcciones.
En el fichero de configuración se puede poner la siguiente línea:
BrowserMatchNoCase macintosh Mac
BrowserMatchNoCase MSIE InternetExplorer
This will set environment variables ``Mac'' and ``InternetExplorer'' to true, if the client is running Internet Explorer on a Macintosh.
Then, in your SSI-enabled document, you might do the following:
<!--#if expr="${Mac} && ${InternetExplorer}" -->
Apologetic text goes here
<!--#else -->
Cool JavaScript code goes here
<!--#endif -->
Not that I have anything against IE on Macs - I just struggled for a few hours last week trying to get some JavaScript working on IE on a Mac, when it was working everywhere else. The above was the interim workaround.
Any other variable (either ones that you define, or normal
environment variables) can be used in conditional statements. With Apache's ability to set
environment variables with the SetEnvIf directives, and other related
directives, this functionality can let you do some pretty involved dynamic stuff without
ever resorting to CGI.
Ciertamente, SSI no pretende reemplazar a los programas CGI o a otras tecnologías usadas para generar páginas dinámicamente, pero es una manera cómoda y sencilla de añadir pequeñas cantidades de contenido dinámico en las páginas HTML, sin realizar mucho trabajo extra.