Dans notre présentation des atouts des Server Side Includes (SSI), nous avons évoqué la directive #exec, qui permet notamment d'exécuter des commandes ou des scripts CGI. Il s'agit, plus précisément, de récupérer le contenu envoyé en sortie (résultat de la commande ou contenu HTML produit par le script CGI) au sein de la page HTML appelante (la page qui contiendra l'instruction SSI).

Dans quel but ?
L'avantage le plus immédiat de cette méthode est d'abord une meilleure maîtrise de la présentation: pour prendre un exemple concret, imaginons que nous disposons d'un script CGI écrit par exemple en Perl, disons un script de recherche qui renvoie en sortie le code HTML donnant les liens trouvés et diverses informations associées.
Pour que cette page de résultat s'intègre harmonieusement "aux couleurs" du site, nous avons trois méthodes.

- Soit nous modifions le script lui-même (la partie produisant du code HTML) pour que la page renvoyée corresponde dans sa présentation aux autres pages de notre site; outre que cette méthode prend du temps et s'avère, dans le cas du Perl, peu pratique, un problème apparaît immédiatement si notre site est construit à partir de directives SSI (#include, notamment): suivant la configuration du serveur, la page produite ne sera peut-être pas analysée (parsed) pour tenir compte de ces directives, et sa présentation ne correspondra pas à ce que l'on attend. Il faudra en plus effectuer les modifications de configuration nécessaires, quand cela est possible.

- Soit le script nous facilite un peu la vie en incluant un système d'en-tête (header) et pied de page (footer), ou encore un système de modèle de page; alors les modifications de présentation, détachées du script, seront apportées plus facilement, mais le problème des directives SSI incluses dans l'en-tête, le pied de page, ou le modèle, reste entier, sauf si ces différents fichiers sont suffixés en .shtml (mais il est possible de configurer le serveur pour que des documents .html et autres soient analysés pour y traduire des directives SSI, avec l'alourdissement de charge du serveur que cela suppose), et situés dans des répertoires ou la traduction des SSI est bien effectuée. Bien souvent, il faudra donc modifier le script lui-même.

- Soit, enfin, on laisse le script tel qu'il est (avec éventuellement des modifications mineures pour changer la police ou les couleurs), et on s'arrange pour que le code HTML produit soit incorporé dans les pages HTML voulues via une opération analogue à un #include. Nous verrons que la directive #include peut être effectivement utilisée pour cela, mais que la directive #exec est plus puissante, quoiqu'elle même limitée.

Bien sûr, dans notre exemple (page de résultats d'un script de recherche), si nous choisissons tout de même de modifier le script "en dur" avec le code HTML voulu, nous pouvons le faire, malgré l'aspect fastidueux de la chose. Mais dans le cas d'un compteur de page, par exemple, ou autre outil statistique, l'appel CGI concerne chaque page: il n'est plus possible de procéder ainsi à moins de basculer l'intégralité du site en dynamique. On mettre alors à profit les SSI.

#exec et QUERY_STRING
L'utilisation de la directive #exec est simple: dans le cas qui nous occupe (script CGI), on écrira:

<!--#exec cgi="/chemin/virtuel/vers/script.cgi" -->

Comme toutes les directives SSI, celle-ci est insérée dans un commentaire HTML (<!-- et -->), l'espace entre cgi="..." et --> pouvant s'avérer indispensable, suivant la configuration de certains serveurs, pour l'interprétation correcte de la directive.
Par ailleurs, #exec demande un chemin virtuel (depuis la racine du site) et peut nécessiter le renommage des fichiers .pl en .cgi (toujours suivant la configuration de certains serveurs).
Notons que l'on peut aussi utiliser #exec pour lancer des commandes (telle la commande Unix date: <!--#exec cmd="/usr/bin/date" -->).

La première question qui vient à l'esprit concernant #exec est sans doute la suivante: comment faire passer des données de formulaire au script CGI appelé? Contrairement à #include, en effet, on ne peut écrire:

<!--#exec cgi="/chemin/virtuel/vers/script.cgi?param1=valeur1&param2=valeur2" -->

Même si l'équivalent:

<!--#include virtual="/chemin/virtuel/vers/script.cgi?param1=valeur1&param2=valeur2" -->

est valable. On peut d'ailleurs toujours remplacer un #exec par un #include
(<!--#include virtual="/chemin/virtuel/vers/script.cgi" -->) à condition d'utiliser un chemin virtuel et donc l'argument virtual. Mais bien sûr, cela impose, en cas de passage de paramètres au script CGI, de préciser ceux-ci "en dur" au sein de la directive (ou d'utiliser la variable d'environnement QUERY_STRING, récupérable par ${'QUERY_STRING'} au sein d'une directive SSI).

Avec #exec, on peut facilement contourner ce problème. Si l'on ne peut faire figurer dans l'appel CGI les paramètres à transmettre (tout ce qui suit, et incluant, le "?"), on peut par contre transmettre ces paramètres (via la méthode GET) au fichier SHTML qui contient la directive #exec. En pratique, on écrira:

"<form action="/chemin/vers/fichier.shtml">

et on placera la directive #exec au sein de fichier.shtml.
Une restriction toutefois: suivant la configuration de certains serveurs, la méthode GET n'est pas toujours le meilleur choix, car le contenu de QUERY_STRING ("?param1=valeur1&param2=valeur2" par exemple) est parfois tronqué...

A vous de choisir parmi toutes ces méthodes.