diff --git a/docs/manual/bind.html.fr b/docs/manual/bind.html.fr index 5bdd25ce4c786a40842a8c0be398064a31c77007..2fd5dbf97fa87054983a465a279c15d84cfe2bd9 100644 --- a/docs/manual/bind.html.fr +++ b/docs/manual/bind.html.fr @@ -7,7 +7,7 @@ This file is generated from xml source: DO NOT EDIT XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --> -
Configuration du serveur HTTP Apache pour l'écoute - sur un port et une adresse IP spécifiques.
+Configuration du serveur HTTP Apache pour l'écoute + sur un port et une adresse IP spécifiques.
Modules Apparentés | Directives Apparentées |
---|---|
Modules Apparentés | Directives Apparentées |
---|---|
Au démarrage de httpd, un port et une adresse lui sont associés sur - l'hôte local et le serveur se met en attente de l'arrivée d'une requête. - Par défaut, le serveur écoute toutes les adresses de l'hôte local. - Cependant, on peut lui préciser des ports et des adresses spécifiques à écouter, +
Au démarrage de httpd, un port et une adresse lui sont associés sur
+ l'hôte local et le serveur se met en attente de l'arrivée d'une requête.
+ Par défaut, le serveur écoute toutes les adresses de l'hôte local.
+ Cependant, on peut lui préciser des ports et des adresses spécifiques à écouter,
ou une combinaison des deux.
- Tout ceci est souvent associé avec la fonctionnalité
- des hôtes virtuels
- qui détermine la manière dont httpd
répond aux différents ports,
- noms d'hôtes et adresses IP.
httpd
répond aux différents ports,
+ noms d'hôtes et adresses IP.
La directive Listen
- enjoint le serveur de n'accepter des requêtes que sur le(s)
- port(s) spécifiés ou
- une combinaison adresse/port. Si seul un numéro de port est spécifié
+ enjoint le serveur de n'accepter des requêtes que sur le(s)
+ port(s) spécifiés ou
+ une combinaison adresse/port. Si seul un numéro de port est spécifié
dans la directive Listen
,
- le serveur se met à l'écoute sur ce port, sur toutes les interfaces réseau.
- Si une adresse IP est spécifiée en plus du port, le serveur va écouter
- sur ce port, uniquement sur l'interface réseau correspondante. On peut utiliser
+ le serveur se met à l'écoute sur ce port, sur toutes les interfaces réseau.
+ Si une adresse IP est spécifiée en plus du port, le serveur va écouter
+ sur ce port, uniquement sur l'interface réseau correspondante. On peut utiliser
de multiples directives
Listen
pour
- spécifier plusieurs adresses et ports à écouter. Le serveur répondra alors
- aux requêtes sur ces ports et adresses spécifiés.
Par exemple, pour faire en sorte que le serveur accepte des connexions sur les ports 80 et 8000, sur toutes les interfaces, utilisez :
@@ -86,88 +86,88 @@ Listen 8000 Listen 192.0.2.5:8000Les adresses IPv6 doivent être mises entre crochets, comme dans +
Les adresses IPv6 doivent être mises entre crochets, comme dans l'exemple suivant :
Listen [2001:db8::a00:20ff:fea7:ccea]:80
Des directives Listen
- imbriquées provoqueront une erreur fatale qui
- empêchera le serveur de démarrer.
(48)Address already in use: make_sock: could not bind to address [::]:80
Voir cette - discussion dans le wiki pour plus de conseils pour résoudre ce - problème.
+ discussion dans le wiki pour plus de conseils pour résoudre ce + problème.Lorsque httpd est redémarré, certaines remarques sont à prendre en compte
- quant aux modifications apportées aux directives Listen
. Au cours du redémarrage, httpd
- conserve la liaison avec les ports de la configuration précédente afin
- d'éviter l'obtention d'un message d'erreur "Connection refused" lors d'une
- tentative ultérieure de connexion au serveur. Si les modifications apportées au jeu de
- directives Listen
utilisé entrent
- en conflit avec ce dernier, le serveur refusera de redémarrer.
Lorsque httpd est redémarré, certaines remarques sont à prendre en compte
+ quant aux modifications apportées aux directives Listen
. Au cours du redémarrage, httpd
+ conserve la liaison avec les ports de la configuration précédente afin
+ d'éviter l'obtention d'un message d'erreur "Connection refused" lors d'une
+ tentative ultérieure de connexion au serveur. Si les modifications apportées au jeu de
+ directives Listen
utilisé entrent
+ en conflit avec ce dernier, le serveur refusera de redémarrer.
Par exemple, modifier la configuration suivante :
Listen 127.0.0.1:80
pour utiliser la suivante pourra échouer car écouter le port 80 sur - toutes les adresses IP entre en conflit avec une écoute sélective du port 80 +
pour utiliser la suivante pourra échouer car écouter le port 80 sur + toutes les adresses IP entre en conflit avec une écoute sélective du port 80 sur la seule adresse IP 127.0.0.1.
Listen 80
Pour qu'une telle modification de configuration soit prise en compte avec - succès, il est nécessaire d'arrêter, puis de démarrer le serveur.
+ succès, il est nécessaire d'arrêter, puis de démarrer le serveur.Un nombre croissant de plateformes implémentent IPv6, et +
Un nombre croissant de plateformes implémentent IPv6, et APR supporte IPv6 sur la plupart d'entre elles, - ce qui permet à httpd d'allouer des points de connexion (sockets) IPv6 - et de traiter des requêtes envoyées sur IPv6.
+ ce qui permet à httpd d'allouer des points de connexion (sockets) IPv6 + et de traiter des requêtes envoyées sur IPv6. -Les administrateurs de httpd doivent se préoccuper de la possibilité - pour un point de connexion IPv6 de traiter à la fois des connexions IPv4 +
Les administrateurs de httpd doivent se préoccuper de la possibilité
+ pour un point de connexion IPv6 de traiter à la fois des connexions IPv4
et des connexions IPv6.
Le traitement de connexions IPv4 avec un point de connexion IPv6 utilise
- des adresses IPv6 traduites en IPv4, qui sont autorisées par défaut sur la
- plupart des plateformes, mais sont interdites par défaut sous FreeBSD, NetBSD,
- et OpenBSD, afin de respecter la politique de sécurité du système sur ces plateformes.
- Sur les systèmes où ces adresses sont interdites par défaut, un
- paramètre spécial du script configure
permet de modifier
+ des adresses IPv6 traduites en IPv4, qui sont autorisées par défaut sur la
+ plupart des plateformes, mais sont interdites par défaut sous FreeBSD, NetBSD,
+ et OpenBSD, afin de respecter la politique de sécurité du système sur ces plateformes.
+ Sur les systèmes où ces adresses sont interdites par défaut, un
+ paramètre spécial du script configure
permet de modifier
ce comportement pour httpd.
En revanche, sur certaines plateformes comme Linux et Tru64, la
- seule manière de gérer à la fois IPv6 et IPv4 passe
- par l'utilisation d'adresses traduites. Si vous voulez que httpd
gère
+ seule manière de gérer à la fois IPv6 et IPv4 passe
+ par l'utilisation d'adresses traduites. Si vous voulez que httpd
gère
des connexions IPv4 et IPv6 avec un minimum de points de connexion,
- ce qui nécessite l'utilisation d'adresses IPv6 traduites en IPv4,
+ ce qui nécessite l'utilisation d'adresses IPv6 traduites en IPv4,
utilisez l'option --enable-v4-mapped
du script configure
.
L'option --enable-v4-mapped
est utilisée par défaut sur
+
L'option --enable-v4-mapped
est utilisée par défaut sur
toutes les plateformes sauf FreeBSD, NetBSD, et OpenBSD;
- votre httpd a donc probablement été construit avec cette option.
Si vous souhaitez que httpd ne gère que des connexions IPv4, sans se - soucier de ce que vos plateforme et APR supportent, spécifiez une adresse +
Si vous souhaitez que httpd ne gère que des connexions IPv4, sans se
+ soucier de ce que vos plateforme et APR supportent, spécifiez une adresse
IPv4 dans toutes les directives
Listen
, comme dans l'exemple
suivant :
Si votre plateforme le supporte et si vous souhaitez que httpd gère - des connexions IPv4 et IPv6 sur des points de connexion séparés - (c'est à dire désactiver la traduction des adresses IPv6 au format IPv4), +
Si votre plateforme le supporte et si vous souhaitez que httpd gère
+ des connexions IPv4 et IPv6 sur des points de connexion séparés
+ (c'est à dire désactiver la traduction des adresses IPv6 au format IPv4),
utilisez l'option --disable-v4-mapped
du script
configure
. --disable-v4-mapped
est
- utilisé par défaut sur FreeBSD, NetBSD, et OpenBSD.
Dans la plupart des configurations, le second paramètre optionnel +
Dans la plupart des configurations, le second paramètre optionnel
protocol de la directive Listen
n'est pas obligatoire. S'il
- n'est pas spécifié, les protocoles par défaut
+ n'est pas spécifié, les protocoles par défaut
sont https
pour le port 443, et http
pour
- tous les autres ports. Le protocole sert à déterminer quel module
- doit traiter une requête, et à appliquer les optimisations
- spécifiques au protocole via la directive AcceptFilter
.
AcceptFilter
.
- Vous ne devez définir le protocole que si vous travaillez avec +
Vous ne devez définir le protocole que si vous travaillez avec
des ports non standards. Par exemple, pour travailler en
https
sur le port 8443 :
La directive Listen
n'implémente pas les hôtes virtuels.
+
La directive Listen
n'implémente pas les hôtes virtuels.
Elle indique simplement au serveur principal sur quels adresses et ports
- il doit écouter. Si aucune directive
+ il doit écouter. Si aucune directive
<VirtualHost>
- n'est présente, le serveur se comportera de la même façon pour toutes
- les requêtes acceptées. En revanche, la directive
+ n'est présente, le serveur se comportera de la même façon pour toutes
+ les requêtes acceptées. En revanche, la directive
<VirtualHost>
- peut être utilisée pour provoquer une réaction différente du serveur
- pour un ou plusieurs adresses ou ports. Pour implémenter un hôte virtuel,
- on doit d'abord indiquer au serveur sur quels adresses et ports il doit écouter.
+ peut être utilisée pour provoquer une réaction différente du serveur
+ pour un ou plusieurs adresses ou ports. Pour implémenter un hôte virtuel,
+ on doit d'abord indiquer au serveur sur quels adresses et ports il doit écouter.
Ensuite, une section
<VirtualHost>
- doit être créée pour le couple adresse+port spécifié afin de définir le
- comportement de cet hôte virtuel. Notez que si la directive
+ doit être créée pour le couple adresse+port spécifié afin de définir le
+ comportement de cet hôte virtuel. Notez que si la directive
<VirtualHost>
- est définie pour une adresse et un port sur lesquels le serveur n'est pas censé
- écouter, cet hôte virtuel ne sera pas accessible.
Versión 2.4 del Servidor HTTP Apache
-Los Server Side Includes (Inclusiones en la parte Servidor) facilitan un método para añadir contenido dinámico a documentos HTML existentes.
-Módulos Relacionados | Directivas Relacionadas |
---|---|
Este artículo trata sobre los Server Side Includes, generalmente llamados SSI. - En este artículo, hablaremos sobre cómo configurar su servidor para permitir SSI, - y de técnicas básicas de SSI para añadir contenido dinámico a sus páginas - HTML existentes.
- -Más adelante también hablaremos de algunas técnicas más avanzadas que - pueden usarse con SSI, tales como declaraciones condicionales en sus directivas SSI.
- -SSI (Server Side Includes) son directivas que se introducen en páginas HTML y son - evaluadas por el servidor mientras éste las sirve. Le permiten añadir - contenido generado de manera dinámica a sus páginas HTML existentes sin tener - que servir una página entera a través de un programa CGI, u otra tecnología - para generar contenido dinámico.
- -Por ejemplo, podría colocar una directiva en una página existente de HTML - de esta manera:
- -
- <!--#echo var="DATE_LOCAL" -->
-
Y, cuando se sirve la página, este fragmento será evaluado y sustituido con su resultado:
- -
- Tuesday, 15-Jan-2013 19:28:54 EST
-
La decisión sobre cuándo usar SSI, o de cuándo generar una página al completo con algún programa, suele depender generalmente de la cantidad de contenido estático que contiene, y cuánto de esa página tiene que ser recalculado cada vez que ésta se sirve. SSI es un buen método para añadir pequeñas partes de información, tales como la hora actual - como se ha mostrado más arriba. Pero si la mayoría de su página se tiene que generar en el momento en el que se está sirviendo, necesita buscar otra opción más adecuada que no sea SSI.
-Para permitir SSI en su servidor, debe tener la siguiente directiva en su fichero httpd.conf
, o en un fichero
- .htaccess
:
Options +Includes- - -
Esto le dice a Apache que quiere permitir que se examinen los ficheros buscando directivas SSI. Tenga en cuenta que la mayoría de las configuraciones contienen múltiples directivas Options
que pueden sobreescribirse las unas a las otras. Probablemente necesitará aplicar Options
al directorio específico donde quiere SSI activado para asegurarse de que se evalúa en último lugar y por tanto se acabará aplicando.
No todos los ficheros se examinan buscando directivas SSI. Usted Le tiene que indicar a Apache qué ficheros se tienen que examinar. Hay dos formas de hacer esto. Puede decirle a Apache que examine cualquier fichero con una extensión determinada, como por ejemplo .shtml
, con las siguientes directivas:
AddType text/html .shtml -AddOutputFilter INCLUDES .shtml- - -
Una desventaja de este método es que si quisiera añadir directivas SSI a una página ya existente, tendría que cambiar el nombre de la página, y todos los enlaces que apuntasen a esa página, todo para poder darle la extensión .shtml
y que esas directivas sean interpretadas.
El otro método es usar la directiva XBitHack
:
XBitHack on- - -
XBitHack
le dice a Apache que examine ficheros buscando directivas SSI si los ficheros tienen el bit de ejecución configurado. Asi que para añadir directivas SSI a una página existente, en lugar de tener que cambiarle el nombre, solo tendría que convertirla en ejecutable usando chmod
.
- chmod +x pagename.html
-
Una breve recomendación de qué no hay que hacer. Ocasionalmente vemos gente recomendar que le diga a Apache que examine todos los ficheros
- .html
para activar SSI, para no tener que lidiar renombrando los ficheros a .shtml
. Quizás estas personas no hayan oido hablar de XBitHack
. Lo que hay que tener en cuenta, es que haciendo eso, está pidiendo al Apache que lea cada uno de los ficheros que manda al cliente, incluso si no contenien directivas SSI. Esto puede ralentizar bastante el servidor, y no es una buena idea.
Por supuesto, en Windows, no hay tal cosa como la configuración del bit de ejecución, así que esto limita las opciones un poco.
- -En su configuración por defecto, Apache no envía la fecha de última modificación o la longitud de contenido de páginas SSI porque es dificil calcular estos valores para contenido dinámico. Esto puede impedir que se cachee un documento, y dar como resultado en apareciencia un rendimiento más lento del cliente. Hay dos maneras de solucionar esto:
- -XBitHack Full
. Esto le indica a apache que determine la fecha de última modificación mirando sólo la fecha del fichero que se ha solicitado originalmente, obviando la modificación de cualquier otro fichero al que se hace referencia mediante SSI.mod_expires
para configurar una expiración específica de tiempo en sus ficheros, y así hacer saber a proxies o navegadores web que es aceptable cachearlos.Las directivas SSI tienen la sintaxis siguiente:
-
- <!--#function attribute=value attribute=value ... -->
-
Se formatean como comentarios HTML, así si no tiene SSI habilitado correctamente, el navegador las obviará, pero todavía serán visibles en el fichero HTML. Si tiene SSI configurado correctamente, la directiva será reemplazada con su propio resultado.
- -Esta función es una de tantas, y hablaremos de algunas de ellas más adelante. Por ahora, aquí mostramos unos ejemplos de lo que puede hacer con SSI.
- -
- <!--#echo var="DATE_LOCAL" -->
-
La función echo
sencillamente muestra el valor de una variable. Hay muchas variables estándar que incluyen un conjunto de variables de entorno disponibles para programas CGI. También puede definir sus propias variables con la función set
.
Si no le gusta el formato en el que se imprime la fecha, puede usar la función config
, con un atributo
- timefmt
para modificar ese formato.
- <!--#config timefmt="%A %B %d, %Y" -->
- Today is <!--#echo var="DATE_LOCAL" -->
-
- La última modificación de este documento <!--#flastmod file="index.html" -->
-
Esta función también está sujeta a configuraciones de formato de
- timefmt
.
Este es uno de los usos más comunes de SSI - para sacar el resultado de un programa CGI, tal y como ocurre con el que fuera el programa favorito de todos, un ``contador de visitas.''
- -
- <!--#include virtual="/cgi-bin/counter.pl" -->
-
A continuación hay algunos ejemplos específicos de cosas que puede hacer con SSI en sus documentos HTML.
- -Antes mencionamos que puede usar SSI para informar al usuario cuando el documento ha sido modificado por última vez. Aun así, el método actual para hacerlo se dejó en cuestión. El código que se muestra a continuación, puesto en un documento HTML, pondrá ese sello de tiempo en su página. Por descontado, tendrá que tener SSI habilitado correctamente, como se indicó más arriba.
-
- <!--#config timefmt="%A %B %d, %Y" -->
- Ultima modificación de este fichero <!--#flastmod file="ssi.shtml" -->
-
Obviamente, necesitará sustituir el nombre de fichero
- ssi.shtml
con el nombre real del fichero al que usted hace referencia. Esto puede ser inconveniente si solo está buscando un trozo genérico de código que pueda copiar y pegar en cualquier fichero, asi que probablemente necesite usar la variable LAST_MODIFIED
en su lugar:
- <!--#config timefmt="%D" -->
- Última modificación de este fichero <!--#echo var="LAST_MODIFIED" -->
-
Para más detalles sobre el formato timefmt
, vaya a su buscador favorito y busque strftime
. La sintaxis es la misma.
Si gestiona un sitio que tiene más de unas cuantas páginas, probablemente se de cuenta de que modificar todas esa páginas es un auténtico engorro, especialmente si trata de mantener una apareciencia homogénea en todas ellas.
- -Si usa un Include de fichero para la cabecera y/o pie de página puede reducir la carga de trabajo de estas actualizaciones. Solo tiene que hacer un sólo pie de página, y después incluirlo en cada página con el comando SSI include
. La función include
- puede determinar qué fichero incluir cuando usa el atributo
- file
, o el atributo virtual
. El atributo file
es una ruta de fichero, relativa al directorio actual. Eso significa que no puede ser una ruta de fichero absoluta (que comienza con /), ni tampoco puede contener ../ como parte de la ruta. El atributo virtual
es probablemente más útil, y debería especificar una URL relativa al documento que se está sirviendo. Puede empezar con una /, pero debe estar en el mismo servidor que el fichero que se está sirviendo.
- <!--#include virtual="/footer.html" -->
-
Frecuentemente combinaremos las dos últimas, poniendo una directiva
- LAST_MODIFIED
dentro de un fichero de pie de página que va a ser incluido. Se pueden encontrar directivas SSI en el fichero que se incluye, las inclusiones pueden anidarse - lo que quiere decir, que el fichero incluido puede incluir otro fichero, y así sucesivamente.
Además de poder configurar el formato de la hora, también puede configurar dos cosas más.
- -Generalmente, cuando algo sale mal con sus directivas SSI, obtiene el mensaje (ha ocurrido un error procesando esta directiva)
-
- [an error occurred while processing this directive]
-
Si quiere cambiar ese mensaje por otra cosa, puede hacerlo con el atributo errmsg
para la función
- config
:
- <!--#config errmsg="[Parece que no sabe cómo usar SSI]" -->
-
Afortunadamente, los usuarios finales nunca verán este mensaje, porque habrá resuelto todos los problemas con sus directivas SSI antes de publicar su página web. (¿Verdad?)
- -Y puede configurar el formato en el que los tamaños de fichero se muestran con el formato sizefmt
. Puede especificar
- bytes
para un recuento total en bytes, o
- abbrev
para un número abreviado en Kb o Mb, según sea necesario.
Puede usar la función exec
para ejecutar comandos. Y SSI puede ejecutar un comando usando la shell (/bin/sh
, para ser más precisos - o la shell de DOS , si está en Win32). Lo siguiente, por ejemplo, le dará un listado de ficheros en un directorio.
- <pre>
- <!--#exec cmd="ls" -->
- </pre>
-
o, en Windows
-
- <pre>
- <!--#exec cmd="dir" -->
- </pre>
-
Notará un formato estraño con esta directiva en Windows, porque el resultado de dir
contiene la cadena de caracterers ``<dir
>'' ,que confunde a los navegadores.
Tenga en cuenta de que esta característica es muy peligrosa, puesto que ejecutará cualquier código que esté especificado con la etiqueta
- exec
. Si tiene una situación en la que los usuarios pueden editar contenido en sus páginas web, tales como por ejemplo un ``registro de visitas'', asegúrese de tener esta característica deshabilitada. Puede permitir SSI, pero no la característica exec
, con el argumento IncludesNOEXEC
en la directiva Options
.
Además de mostrar contenido, SSI en Apache da la opción de configurar variables y usar esas variables en comparaciones y condicionales.
- -Usando la directiva set
, puede configurar variables para su uso posterior. La sintaxis es como sigue:
- <!--#set var="name" value="Rich" -->
-
Además de configurar valores literales como esto, puede usar cualquier otra variable, incluyendo variables de entorno o las variables que se han mencionado antes (como por ejemplo LAST_MODIFIED
) para dar valores a sus variables. Podrá especificar que algo es una vaiable, en lugar de una cadena de caracters literal, usando el símbolo del dolar ($) antes del nombre de la variable.
<!--#set var="modified" value="$LAST_MODIFIED" -->
-
Para poner el símbolo del dolar de manera literal en un valor de su variable tendrá que escapar el símbolo del dolar con una barra "\".
-
- <!--#set var="cost" value="\$100" -->
-
Por último, si quiere poner una variable entre medias de una cadena de caracteres más larga, y se da la coincidencia de que el nombre de la variable se encontrará con otros caracteres, y de esta manera se confundirá con otros caracteres, puedes poner el nombre de la variable entre llaves, y así eliminar la confusión. (Es dificil encontrar un buen ejemplo para esto, pero con éste a lo mejor entiende lo que tratamos de transmitir.)
-
- <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
-
Ahora que tenemos variables, y somos capaces de comparar sus valores, podemos usarlas para expresar condicionales. Esto permite a SSI ser un cierto tipo de lenguaje de programación diminuto.
- mod_include
provee una estrucura if
,
- elif
, else
, endif
- para construir declaraciones condicionales. Esto le permite generar de manera efectiva multitud de páginas lógicas desde tan solo una página.
La estructura de este sistema condicional es:
-
- <!--#if expr="test_condition" -->
- <!--#elif expr="test_condition" -->
- <!--#else -->
- <!--#endif -->
-
Una test_condition puede ser cualquier tipo de comparación lógica - o bien comparando valores entre ellos, o probando la ``verdad'' (o falsedad) de un valor en particular. (Una cadena de caracteres cualquiera es verdadera si no está vacía.) Para una lista completa de operadores de comparación, vea la documentación de mod_include
.
Por ejemplo, si quiere personalizar el texto en su página web basado en la hora actual, puede usar la siguiente receta, colocada en su página HTML:
- -
- Good
- <!--#if expr="%{TIME_HOUR} <12" -->
- morning!
- <!--#else -->
- afternoon!
- <!--#endif -->
-
Cualquier otra variable (o bien las que defina usted, o variables de entorno normales) puede usarse en declaraciones condicionales. - Vea Expresiones en el Servidor Apache HTTP para más información sobre el motor de evaluación de expresiones.
- -Con la habilidad de Apache de configurar variables de entorno con directivas SetEnvIf
, y otras directivas relacionadas,
- esta funcionalidad puede llevarle a hacer una gran variedad de contenido dinámico en la parte de servidor sin tener que depender de una aplicación web al completo.
Desde luego SSI no es un reemplazo para CGI u otras tecnologías que se usen para generar páginas web dinámicas. Pero es un gran método para añadir pequeñas cantidaddes de contenido dinámico a páginas web, sin hacer mucho más trabajo extra.
-Versión 2.4 del Servidor HTTP Apache
+Los Server Side Includes (Inclusiones en la parte Servidor) facilitan un método para añadir contenido dinámico a documentos HTML existentes.
+Módulos Relacionados | Directivas Relacionadas |
---|---|
Este artículo trata sobre los Server Side Includes, generalmente llamados SSI. + En este artículo, hablaremos sobre cómo configurar su servidor para permitir SSI, + y de técnicas básicas de SSI para añadir contenido dinámico a sus páginas + HTML existentes.
+ +Más adelante también hablaremos de algunas técnicas más avanzadas que + pueden usarse con SSI, tales como declaraciones condicionales en sus directivas SSI.
+ +SSI (Server Side Includes) son directivas que se introducen en páginas HTML y son + evaluadas por el servidor mientras éste las sirve. Le permiten añadir + contenido generado de manera dinámica a sus páginas HTML existentes sin tener + que servir una página entera a través de un programa CGI, u otra tecnología + para generar contenido dinámico.
+ +Por ejemplo, podría colocar una directiva en una página existente de HTML + de esta manera:
+ +
+ <!--#echo var="DATE_LOCAL" -->
+
Y, cuando se sirve la página, este fragmento será evaluado y sustituido con su resultado:
+ +
+ Tuesday, 15-Jan-2013 19:28:54 EST
+
La decisión sobre cuándo usar SSI, o de cuándo generar una página al completo con algún programa, suele depender generalmente de la cantidad de contenido estático que contiene, y cuánto de esa página tiene que ser recalculado cada vez que ésta se sirve. SSI es un buen método para añadir pequeñas partes de información, tales como la hora actual - como se ha mostrado más arriba. Pero si la mayoría de su página se tiene que generar en el momento en el que se está sirviendo, necesita buscar otra opción más adecuada que no sea SSI.
+Para permitir SSI en su servidor, debe tener la siguiente directiva en su fichero httpd.conf
, o en un fichero
+ .htaccess
:
Options +Includes+ + +
Esto le dice a Apache que quiere permitir que se examinen los ficheros buscando directivas SSI. Tenga en cuenta que la mayoría de las configuraciones contienen múltiples directivas Options
que pueden sobreescribirse las unas a las otras. Probablemente necesitará aplicar Options
al directorio específico donde quiere SSI activado para asegurarse de que se evalúa en último lugar y por tanto se acabará aplicando.
No todos los ficheros se examinan buscando directivas SSI. Usted Le tiene que indicar a Apache qué ficheros se tienen que examinar. Hay dos formas de hacer esto. Puede decirle a Apache que examine cualquier fichero con una extensión determinada, como por ejemplo .shtml
, con las siguientes directivas:
AddType text/html .shtml +AddOutputFilter INCLUDES .shtml+ + +
Una desventaja de este método es que si quisiera añadir directivas SSI a una página ya existente, tendría que cambiar el nombre de la página, y todos los enlaces que apuntasen a esa página, todo para poder darle la extensión .shtml
y que esas directivas sean interpretadas.
El otro método es usar la directiva XBitHack
:
XBitHack on+ + +
XBitHack
le dice a Apache que examine ficheros buscando directivas SSI si los ficheros tienen el bit de ejecución configurado. Asi que para añadir directivas SSI a una página existente, en lugar de tener que cambiarle el nombre, solo tendría que convertirla en ejecutable usando chmod
.
+ chmod +x pagename.html
+
Una breve recomendación de qué no hay que hacer. Ocasionalmente vemos gente recomendar que le diga a Apache que examine todos los ficheros
+ .html
para activar SSI, para no tener que lidiar renombrando los ficheros a .shtml
. Quizás estas personas no hayan oido hablar de XBitHack
. Lo que hay que tener en cuenta, es que haciendo eso, está pidiendo al Apache que lea cada uno de los ficheros que manda al cliente, incluso si no contenien directivas SSI. Esto puede ralentizar bastante el servidor, y no es una buena idea.
Por supuesto, en Windows, no hay tal cosa como la configuración del bit de ejecución, así que esto limita las opciones un poco.
+ +En su configuración por defecto, Apache no envía la fecha de última modificación o la longitud de contenido de páginas SSI porque es dificil calcular estos valores para contenido dinámico. Esto puede impedir que se cachee un documento, y dar como resultado en apareciencia un rendimiento más lento del cliente. Hay dos maneras de solucionar esto:
+ +XBitHack Full
. Esto le indica a apache que determine la fecha de última modificación mirando sólo la fecha del fichero que se ha solicitado originalmente, obviando la modificación de cualquier otro fichero al que se hace referencia mediante SSI.mod_expires
para configurar una expiración específica de tiempo en sus ficheros, y así hacer saber a proxies o navegadores web que es aceptable cachearlos.Las directivas SSI tienen la sintaxis siguiente:
+
+ <!--#function attribute=value attribute=value ... -->
+
Se formatean como comentarios HTML, así si no tiene SSI habilitado correctamente, el navegador las obviará, pero todavía serán visibles en el fichero HTML. Si tiene SSI configurado correctamente, la directiva será reemplazada con su propio resultado.
+ +Esta función es una de tantas, y hablaremos de algunas de ellas más adelante. Por ahora, aquí mostramos unos ejemplos de lo que puede hacer con SSI.
+ +
+ <!--#echo var="DATE_LOCAL" -->
+
La función echo
sencillamente muestra el valor de una variable. Hay muchas variables estándar que incluyen un conjunto de variables de entorno disponibles para programas CGI. También puede definir sus propias variables con la función set
.
Si no le gusta el formato en el que se imprime la fecha, puede usar la función config
, con un atributo
+ timefmt
para modificar ese formato.
+ <!--#config timefmt="%A %B %d, %Y" -->
+ Today is <!--#echo var="DATE_LOCAL" -->
+
+ La última modificación de este documento <!--#flastmod file="index.html" -->
+
Esta función también está sujeta a configuraciones de formato de
+ timefmt
.
Este es uno de los usos más comunes de SSI - para sacar el resultado de un programa CGI, tal y como ocurre con el que fuera el programa favorito de todos, un ``contador de visitas.''
+ +
+ <!--#include virtual="/cgi-bin/counter.pl" -->
+
A continuación hay algunos ejemplos específicos de cosas que puede hacer con SSI en sus documentos HTML.
+ +Antes mencionamos que puede usar SSI para informar al usuario cuando el documento ha sido modificado por última vez. Aun así, el método actual para hacerlo se dejó en cuestión. El código que se muestra a continuación, puesto en un documento HTML, pondrá ese sello de tiempo en su página. Por descontado, tendrá que tener SSI habilitado correctamente, como se indicó más arriba.
+
+ <!--#config timefmt="%A %B %d, %Y" -->
+ Ultima modificación de este fichero <!--#flastmod file="ssi.shtml" -->
+
Obviamente, necesitará sustituir el nombre de fichero
+ ssi.shtml
con el nombre real del fichero al que usted hace referencia. Esto puede ser inconveniente si solo está buscando un trozo genérico de código que pueda copiar y pegar en cualquier fichero, asi que probablemente necesite usar la variable LAST_MODIFIED
en su lugar:
+ <!--#config timefmt="%D" -->
+ Última modificación de este fichero <!--#echo var="LAST_MODIFIED" -->
+
Para más detalles sobre el formato timefmt
, vaya a su buscador favorito y busque strftime
. La sintaxis es la misma.
Si gestiona un sitio que tiene más de unas cuantas páginas, probablemente se de cuenta de que modificar todas esa páginas es un auténtico engorro, especialmente si trata de mantener una apareciencia homogénea en todas ellas.
+ +Si usa un Include de fichero para la cabecera y/o pie de página puede reducir la carga de trabajo de estas actualizaciones. Solo tiene que hacer un sólo pie de página, y después incluirlo en cada página con el comando SSI include
. La función include
+ puede determinar qué fichero incluir cuando usa el atributo
+ file
, o el atributo virtual
. El atributo file
es una ruta de fichero, relativa al directorio actual. Eso significa que no puede ser una ruta de fichero absoluta (que comienza con /), ni tampoco puede contener ../ como parte de la ruta. El atributo virtual
es probablemente más útil, y debería especificar una URL relativa al documento que se está sirviendo. Puede empezar con una /, pero debe estar en el mismo servidor que el fichero que se está sirviendo.
+ <!--#include virtual="/footer.html" -->
+
Frecuentemente combinaremos las dos últimas, poniendo una directiva
+ LAST_MODIFIED
dentro de un fichero de pie de página que va a ser incluido. Se pueden encontrar directivas SSI en el fichero que se incluye, las inclusiones pueden anidarse - lo que quiere decir, que el fichero incluido puede incluir otro fichero, y así sucesivamente.
Además de poder configurar el formato de la hora, también puede configurar dos cosas más.
+ +Generalmente, cuando algo sale mal con sus directivas SSI, obtiene el mensaje (ha ocurrido un error procesando esta directiva)
+
+ [an error occurred while processing this directive]
+
Si quiere cambiar ese mensaje por otra cosa, puede hacerlo con el atributo errmsg
para la función
+ config
:
+ <!--#config errmsg="[Parece que no sabe cómo usar SSI]" -->
+
Afortunadamente, los usuarios finales nunca verán este mensaje, porque habrá resuelto todos los problemas con sus directivas SSI antes de publicar su página web. (¿Verdad?)
+ +Y puede configurar el formato en el que los tamaños de fichero se muestran con el formato sizefmt
. Puede especificar
+ bytes
para un recuento total en bytes, o
+ abbrev
para un número abreviado en Kb o Mb, según sea necesario.
Puede usar la función exec
para ejecutar comandos. Y SSI puede ejecutar un comando usando la shell (/bin/sh
, para ser más precisos - o la shell de DOS , si está en Win32). Lo siguiente, por ejemplo, le dará un listado de ficheros en un directorio.
+ <pre>
+ <!--#exec cmd="ls" -->
+ </pre>
+
o, en Windows
+
+ <pre>
+ <!--#exec cmd="dir" -->
+ </pre>
+
Notará un formato estraño con esta directiva en Windows, porque el resultado de dir
contiene la cadena de caracterers ``<dir
>'' ,que confunde a los navegadores.
Tenga en cuenta de que esta característica es muy peligrosa, puesto que ejecutará cualquier código que esté especificado con la etiqueta
+ exec
. Si tiene una situación en la que los usuarios pueden editar contenido en sus páginas web, tales como por ejemplo un ``registro de visitas'', asegúrese de tener esta característica deshabilitada. Puede permitir SSI, pero no la característica exec
, con el argumento IncludesNOEXEC
en la directiva Options
.
Además de mostrar contenido, SSI en Apache da la opción de configurar variables y usar esas variables en comparaciones y condicionales.
+ +Usando la directiva set
, puede configurar variables para su uso posterior. La sintaxis es como sigue:
+ <!--#set var="name" value="Rich" -->
+
Además de configurar valores literales como esto, puede usar cualquier otra variable, incluyendo variables de entorno o las variables que se han mencionado antes (como por ejemplo LAST_MODIFIED
) para dar valores a sus variables. Podrá especificar que algo es una vaiable, en lugar de una cadena de caracters literal, usando el símbolo del dolar ($) antes del nombre de la variable.
<!--#set var="modified" value="$LAST_MODIFIED" -->
+
Para poner el símbolo del dolar de manera literal en un valor de su variable tendrá que escapar el símbolo del dolar con una barra "\".
+
+ <!--#set var="cost" value="\$100" -->
+
Por último, si quiere poner una variable entre medias de una cadena de caracteres más larga, y se da la coincidencia de que el nombre de la variable se encontrará con otros caracteres, y de esta manera se confundirá con otros caracteres, puedes poner el nombre de la variable entre llaves, y así eliminar la confusión. (Es dificil encontrar un buen ejemplo para esto, pero con éste a lo mejor entiende lo que tratamos de transmitir.)
+
+ <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
+
Ahora que tenemos variables, y somos capaces de comparar sus valores, podemos usarlas para expresar condicionales. Esto permite a SSI ser un cierto tipo de lenguaje de programación diminuto.
+ mod_include
provee una estrucura if
,
+ elif
, else
, endif
+ para construir declaraciones condicionales. Esto le permite generar de manera efectiva multitud de páginas lógicas desde tan solo una página.
La estructura de este sistema condicional es:
+
+ <!--#if expr="test_condition" -->
+ <!--#elif expr="test_condition" -->
+ <!--#else -->
+ <!--#endif -->
+
Una test_condition puede ser cualquier tipo de comparación lógica - o bien comparando valores entre ellos, o probando la ``verdad'' (o falsedad) de un valor en particular. (Una cadena de caracteres cualquiera es verdadera si no está vacía.) Para una lista completa de operadores de comparación, vea la documentación de mod_include
.
Por ejemplo, si quiere personalizar el texto en su página web basado en la hora actual, puede usar la siguiente receta, colocada en su página HTML:
+ +
+ Good
+ <!--#if expr="%{TIME_HOUR} <12" -->
+ morning!
+ <!--#else -->
+ afternoon!
+ <!--#endif -->
+
Cualquier otra variable (o bien las que defina usted, o variables de entorno normales) puede usarse en declaraciones condicionales. + Vea Expresiones en el Servidor Apache HTTP para más información sobre el motor de evaluación de expresiones.
+ +Con la habilidad de Apache de configurar variables de entorno con directivas SetEnvIf
, y otras directivas relacionadas,
+ esta funcionalidad puede llevarle a hacer una gran variedad de contenido dinámico en la parte de servidor sin tener que depender de una aplicación web al completo.
Desde luego SSI no es un reemplazo para CGI u otras tecnologías que se usen para generar páginas web dinámicas. Pero es un gran método para añadir pequeñas cantidaddes de contenido dinámico a páginas web, sin hacer mucho más trabajo extra.
+