Qu'est-ce que la Common Gateway Interface (CGI)?

CGI est une interface de passerelle commune. Comme son nom l'indique, il s'agit d'une interface de passerelle «commune» pour tout. C'est si trivial et naïf du nom. Je sens que j'ai compris cela et je l'ai ressenti à chaque fois que j'ai rencontré ce mot. Mais franchement, je ne l'ai pas fait. Je suis encore confus.

Je suis programmeur PHP avec une expérience en développement web.

demande d'utilisateur (client) pour la page ---> serveur Web (-> interpréteur PHP intégré) ----> Script côté serveur (PHP) ---> Serveur MySQL.

Maintenant, disons que mon script PHP peut récupérer les résultats du serveur MySQL et du serveur MATLAB et d'un autre serveur.

Alors maintenant, PHP Script est le CGI? Parce que son interface pour le serveur Web entre tous les autres serveurs? Je ne sais pas. Parfois, ils appellent CGI, une technologie et d'autres fois, ils appellent CGI un programme ou un autre serveur.

• Qu'est-ce que CGI exactement?

• Quel est le gros problème /cgi-bin/*.cgi? Qu'est-ce qui se passe avec ça? Je ne sais pas à quoi sert ce cgi-binrépertoire sur le serveur. Je ne sais pas pourquoi ils ont des extensions * .cgi.

• Pourquoi Perl fait toujours obstacle. CGI & Perl (langue). Je ne sais pas non plus ce qui se passe avec ces deux-là. Presque tout le temps, je continue d'entendre ces deux en combinaison "CGI & Perl". Ce livre est un autre excellent exemple de programmation CGI avec Perl . Pourquoi pas "Programmation CGI avec PHP / JSP / ASP"? Je n'ai jamais vu de telles choses.

• La programmation CGI en C , me confond beaucoup. " en C " ?? Sérieusement?? Je ne sais pas quoi dire. Je suis juste confus. " en C " ?? Cela change tout. Le programme doit être compilé et exécuté. Cela change complètement ma vision de la programmation Web. Quand dois-je compiler? Comment le programme est-il exécuté (car ce sera un code machine, il doit donc s’exécuter en tant que processus indépendant). Comment communique-t-il avec le serveur Web? IPC? et interfacer avec tous les serveurs (dans mon exemple MATLAB & MySQL) en utilisant la programmation de socket? Je suis perdu!!

• Les gens disent que CGI est obsolète et n'est plus utilisé. Est-ce vrai? Quelle est la dernière mise à jour?

Une fois, je me suis retrouvé dans une situation où je devais donner accès à la requête HTTP PUT au serveur Web (Apache HTTPD). C'est un long dos. Donc, si je me souviens bien, c'est ce que j'ai fait:

1. Édité le fichier de configuration d'Apache HTTPD pour dire au serveur Web de passer toutes les requêtes HTTP PUT à certains put.php(j'ai dû écrire ce script PHP)

2. Implémentez put.php pour gérer la demande (enregistrez le fichier à l'emplacement mentionné)

Les gens ont dit que j'avais écrit un script CGI. Sérieusement, je n'avais aucune idée de ce dont ils parlaient.

• Ai-je vraiment écrit un script CGI?

J'espère que vous avez compris ma confusion. (Parce que moi-même je ne sais pas où je suis confus). Je vous demande de garder votre réponse aussi simple que possible. Je ne comprends vraiment aucune terminologie technique sophistiquée. Du moins pas dans ce cas.

ÉDITER:

J'ai trouvé ce tutoriel incroyable "La programmation CGI est simple!" - Tutoriel CGI , qui explique les concepts de la manière la plus simple possible. Après avoir lu cet article, vous voudrez peut-être lire Prise en main de la programmation CGI en C pour compléter votre compréhension avec des exemples de code réels. J'ai également ajouté ces liens vers ce tutoriel à l'article de Wikipedia: http://en.wikipedia.org/wiki/Common_Gateway_Interface

CGI est une interface qui indique au serveur Web comment transmettre des données vers et depuis une application. Plus précisément, il décrit comment les informations de demande sont transmises dans des variables d'environnement (telles que le type de demande, l'adresse IP distante), comment le corps de la demande est transmis via une entrée standard et comment la réponse est transmise via une sortie standard. Vous pouvez vous référer à la spécification CGI pour plus de détails.

Pour utiliser votre image:

user (client) request for page ---> webserver ---[CGI]----> Server side Program ---> MySQL Server.

La plupart, sinon la totalité, des serveurs Web peuvent être configurés pour exécuter un programme en tant que «CGI». Cela signifie que le serveur Web, lors de la réception d'une demande, transmettra les données à un programme spécifique, définissant certaines variables d'environnement et organisant les paramètres via une entrée et une sortie standard afin que le programme puisse savoir où et quoi rechercher.

Le principal avantage est que vous pouvez exécuter N'IMPORTE QUEL code exécutable à partir du Web, étant donné que le serveur Web et le programme savent comment CGI fonctionne. C'est pourquoi vous pouvez écrire des programmes Web en C ou Bash avec un serveur Web standard compatible CGI. Cela, et que la plupart des environnements de programmation peuvent facilement utiliser des variables d'entrée, de sortie et d'environnement standard.

Dans votre cas, vous avez probablement utilisé un autre moyen de communication spécifique à PHP entre vos scripts et le serveur Web, c'est, comme vous le mentionnez bien dans votre question, un interpréteur intégré appelé mod_php.

Donc, répondant à vos questions:

Qu'est-ce que CGI exactement?

Voir au dessus.

Quel est le gros problème avec /cgi-bin/*.cgi? Quoi de neuf avec ça? Je ne sais pas à quoi sert ce répertoire cgi-bin sur le serveur. Je ne sais pas pourquoi ils ont des extensions * .cgi.

C'est l'endroit traditionnel pour les programmes cgi, de nombreux serveurs Web sont livrés avec ce répertoire pré-configuré pour exécuter tous les binaires là-bas en tant que programmes CGI. L'extension .cgi indique un exécutable qui devrait fonctionner via le CGI.

Pourquoi Perl fait toujours obstacle. CGI & Perl (langue). Je ne sais pas non plus ce qui se passe avec ces deux-là. Presque tout le temps, je continue d'entendre ces deux en combinaison "CGI & Perl". Ce livre est un autre excellent exemple de programmation CGI avec Perl Pourquoi pas "Programmation CGI avec PHP / JSP / ASP". Je n'ai jamais vu de telles choses.

Parce que Perl est ancien (plus ancien que PHP, JSP et ASP qui ont tous vu le jour lorsque CGI était déjà vieux, Perl existait lorsque CGI était nouveau) et est devenu assez célèbre pour être un très bon langage pour servir des pages Web dynamiques via le CGI. De nos jours, il existe d'autres alternatives pour exécuter Perl dans un serveur Web, principalement mod_perl .

La programmation CGI en C cela me déroute beaucoup. en C ?? Sérieusement?? Je ne sais pas quoi dire. Je "suis juste confus." En C "?? Cela change tout. Le programme doit être compilé et exécuté. Cela change complètement ma vision de la programmation Web. Quand dois-je compiler? Comment le programme est-il exécuté (car ce sera un code machine, il doit donc s'exécuter en tant que processus indépendant.) Comment communique-t-il avec le serveur Web? IPC? et s'interface avec tous les serveurs (dans mon exemple MATLAB & MySQL) en utilisant la programmation par socket? Je suis perdu !!

Vous compilez l'exécutable une fois, le serveur Web exécute le programme et transmet les données de la demande au programme et sort la réponse reçue. CGI spécifie qu'une instance de programme sera lancée pour chaque demande. C'est pourquoi CGI est de nos jours inefficace et obsolète.

Ils disent que CGI est obsolète. Ce n'est plus utilisé. En est-il ainsi? Quelle est sa dernière mise à jour?

CGI est toujours utilisé lorsque les performances ne sont pas primordiales et qu'un moyen simple d'exécution de code est requis. Il est inefficace pour les raisons susmentionnées et il existe des moyens plus modernes d'exécuter n'importe quel programme dans un environnement Web. Actuellement, le plus célèbre est FastCGI .

Qu'est-ce que CGI exactement?

Un moyen pour un serveur Web d'obtenir ses données à partir d'un programme (au lieu, par exemple, d'un fichier).

Quel est le gros problème avec /cgi-bin/*.cgi?

Pas grave. Ce n'est qu'une convention.

Je ne sais pas à quoi sert ce répertoire cgi-bin sur le serveur. Je ne sais pas pourquoi ils ont des extensions * .cgi.

Le serveur doit savoir quoi faire avec le fichier (c'est-à-dire le traiter comme un programme à exécuter au lieu de quelque chose à simplement servir). Le fait d'avoir une extension .html lui indique d'utiliser un type de contenu texte / html. Avoir une extension .cgi lui dit de l'exécuter en tant que programme.

Garder les exécutables dans un répertoire séparé offre une protection supplémentaire contre l'exécution de fichiers incorrects et / ou le service de programmes CGI en tant que données brutes au cas où le serveur serait mal configuré.

Pourquoi Perl fait toujours obstacle.

Ce n'est pas le cas. Perl était tout simplement grand et populaire en même temps que CGI.

Je n'ai pas utilisé Perl CGI depuis des années. J'utilisais mod_perl depuis longtemps et j'ai tendance vers PSGI / Plack avec FastCGI ces jours-ci.

Ce livre est un autre excellent exemple de programmation CGI avec Perl Pourquoi pas "Programmation CGI avec PHP / JSP / ASP".

CGI n'est pas très efficace. De meilleures méthodes pour parler aux programmes des serveurs Web sont apparues à peu près en même temps que PHP. JSP et ASP sont des méthodes différentes pour parler aux programmes.

La programmation CGI en C cela me déroute beaucoup. en C ?? Sérieusement??

C'est un langage de programmation, pourquoi pas?

Quand dois-je compiler?

1. Écrire du code
2. Compiler
3. URL d'accès
4. Le serveur Web exécute le programme

Comment le programme est-il exécuté (car ce sera un code machine, il doit donc s’exécuter en tant que processus indépendant).

Il n'a pas à s'exécuter en tant que processus indépendant (vous pouvez écrire des modules Apache en C), mais le concept global de CGI est qu'il lance un processus externe.

Comment communique-t-il avec le serveur Web? IPC?

STDIN / STDOUT et variables d'environnement - telles que définies dans la spécification CGI.

et interfacer avec tous les serveurs (dans mon exemple MATLAB & MySQL) en utilisant la programmation de socket?

En utilisant les méthodes que vous aimez et qui sont prises en charge.

Ils disent que CGI est dépréciée. Ce n'est plus utilisé. En est-il ainsi?

CGI est inefficace, lent et simple. Il est rarement utilisé, lorsqu'il est utilisé, c'est parce qu'il est simple. Si la performance n'est pas un gros problème, la simplicité vaut beaucoup.

Quelle est sa dernière mise à jour?

1.1

CGI est une spécification d'interface entre un serveur Web (serveur HTTP) et un programme exécutable d'un certain type qui doit gérer une demande particulière.

Il décrit comment certaines propriétés de cette demande doivent être communiquées à l'environnement de ce programme et comment le programme doit communiquer la réponse au serveur et comment le serveur doit `` compléter '' la réponse pour former une réponse valide à la demande HTTP d'origine.

Pendant un certain temps, CGI était un projet Internet de l'IETF et avait donc une date d'expiration. Il a expiré sans mise à jour, il n'y avait donc pas de «norme» CGI. C'est maintenant un RFC informatif, mais en tant que tel, il documente la pratique courante et n'est pas une norme en soi. rfc3875.txt , rfc3875.html

Les programmes implémentant une interface CGI peuvent être écrits dans n'importe quel langage exécutable sur la machine cible. Ils doivent pouvoir accéder aux variables d'environnement et généralement à l'entrée standard et générer leur sortie sur la sortie standard .

Les langages compilés tels que C étaient couramment utilisés, tout comme les langages de script comme perl, utilisant souvent des bibliothèques pour faciliter l'accès à l'environnement CGI.

L'un des gros inconvénients de CGI est qu'un nouveau programme est généré pour chaque demande, donc le maintien de l'état entre les demandes pourrait être un problème de performance majeur. L'état peut être géré dans des cookies ou encodé dans une URL, mais s'il devient trop volumineux, il doit être stocké ailleurs et saisi à partir des informations d'URL encodées ou d'un cookie. Chaque appel CGI devrait alors recharger l'état stocké à partir d'un magasin quelque part.

Pour cette raison, et pour une interface très simple avec les requêtes et les sessions, des environnements mieux intégrés entre les serveurs Web et les applications sont beaucoup plus populaires. Des environnements comme une implémentation php moderne avec apache intègrent beaucoup mieux la langue cible avec le serveur Web et fournissent un accès aux requêtes et aux objets de session nécessaires pour traiter efficacement les requêtes http. Ils offrent un moyen beaucoup plus simple et plus riche d'écrire des «programmes» pour gérer les requêtes HTTP.

Que vous ayez écrit un script CGI dépend plutôt de l'interprétation. Il a certainement fait le travail d'un, mais il est beaucoup plus courant d'exécuter php en tant que module où l'interface entre le script et le serveur n'est pas strictement une interface CGI.

Le CGI est spécifié dans la RFC 3875 , bien qu'il s'agisse d' une codification "officielle" ultérieure du document NCSA d' origine . Fondamentalement, CGI définit un protocole pour transmettre des données sur une requête HTTP d'un serveur Web à un programme à traiter - n'importe quel programme, dans n'importe quelle langue. Au moment où la spécification a été écrite (1993), la plupart des serveurs Web ne contenaient que des pages statiques, les "applications Web" étaient une chose rare et nouvelle, il semblait donc naturel de les tenir à l'écart du contenu statique "normal", comme dans un cgi-binrépertoire en dehors du contenu statique, et les faire se terminer .cgi.

À cette époque, il n'y avait pas non plus de "langages de programmation Web" dédiés comme PHP, et C était le langage de programmation portable dominant - donc beaucoup de gens ont écrit leurs scripts CGI en C. Mais Perl s'est rapidement avéré être un meilleur choix pour ce type de chose, et CGI est devenu presque synonyme de Perl pendant un certain temps. Ensuite, il y a eu les Java Servlets, PHP et un tas d'autres et a repris une grande partie de la part de marché de Perl.

Jetez un œil à CGI sur Wikipedia. CGI est un protocole entre le serveur Web et un programme externe ou un script qui gère l'entrée et génère une sortie envoyée au navigateur.

CGI est simplement un moyen pour un serveur Web et un programme de communiquer, rien de plus, rien de moins. Ici, le serveur gère la connexion réseau et le protocole HTTP et le programme gère les entrées et génère des sorties envoyées au navigateur. Le script CGI peut être essentiellement n'importe quel programme qui peut être exécuté par le serveur Web et suit le protocole CGI. Ainsi, un programme CGI peut être implémenté, par exemple, en C. Cependant, cela est extrêmement rare, car C n'est pas très bien adapté à la tâche.

/cgi-bin/*.cgiest simplement un chemin où les gens mettent généralement leur script CGI. Les serveurs Web sont généralement configurés par défaut pour extraire les scripts CGI de ce chemin.

un script CGI peut également être implémenté en PHP, mais tous les programmes PHP ne sont pas des scripts CGI. Si le serveur Web a intégré un interpréteur PHP (par exemple mod_php dans Apache), la phase CGI est ignorée par un protocole direct plus efficace entre le serveur Web et l'interpréteur.

Que vous ayez implémenté ou non un script CGI dépend de la façon dont votre script est exécuté par le serveur Web.

CGI transmet essentiellement la demande à tout interpréteur configuré avec le serveur Web - Il peut s'agir de Perl, Python, PHP, Ruby, C à peu près n'importe quoi. Perl était le plus courant à l'époque, c'est pourquoi vous le voyez souvent en référence à CGI.

CGI n'est pas mort. En fait, la plupart des grandes sociétés d'hébergement exécutent PHP en tant que CGI par opposition à mod_php car il offre une configuration de niveau utilisateur et d'autres choses alors qu'il est plus lent que mod_php. Ruby et Python sont également généralement exécutés en tant que CGI. La principale différence ici est qu'un module serveur s'exécute dans le cadre du logiciel serveur réel - où, comme avec CGI, il est totalement extérieur au serveur Le serveur utilise simplement le module CGI pour déterminer comment transmettre et recevoir des données à l'interpréteur extérieur.

CGI est un mécanisme par lequel un programme externe est appelé par le serveur Web afin de traiter une demande, avec des variables d'environnement et une entrée standard utilisées pour alimenter les données de demande au programme. La langue exacte dans laquelle le programme externe est écrit n'a pas d'importance, bien qu'il soit plus facile d'écrire des programmes CGI dans certaines langues que dans d'autres.

Étant donné que les scripts CGI ont besoin d'autorisations d'exécution, httpd par défaut permet uniquement aux programmes CGI du cgi-binrépertoire d'être exécutés à des fins de sécurité (peut-être maintenant erronées).

La plupart des scripts PHP s'exécutent dans le processus du serveur Web via mod_php. Ce n'est pas CGI.

CGI est lent car le programme (et l'interpréteur associé) doit être démarré par demande. Les alternatives modernes sont l'exécution intégrée, utilisée par mod_php, et les processus de longue durée, utilisés par FastCGI. Un langage donné peut avoir sa propre façon de mettre en œuvre ces mécanismes, alors assurez-vous de demander autour avant de recourir à CGI.

Vous voulez peut-être savoir ce qui n'est pas CGI, et la réponse est un MODULE pour votre serveur Web (si je suppose que vous exécutez Apache). ET C'EST LA GRANDE DIFFÉRENCE, car CGI a besoin d'un programme externe, d'un thread, quel qu'il soit pour instancier un serveur d'application PERL, PHP, C où lorsque vous exécutez en tant que MODULE, ce programme est le serveur Web (apache) en soi.

En raison de tout cela, de nombreux problèmes de performances, de sécurité et de portabilité entrent en jeu. Mais il est bon de savoir ce qui n'est pas CGI en premier, de comprendre ce que c'est.

Un exemple concret: une base de données compliquée qui doit être affichée sur un site Web. Depuis que la base de données a été conçue vers 1986 (!), De nombreuses données ont été regroupées de différentes manières pour économiser de l'espace disque.

Au fur et à mesure du développement, les développeurs ne pouvaient plus résoudre seules les demandes de données compliquées en SQL, par exemple parce que les algorithmes de tri étaient inhabituels.

Il existe trois solutions judicieuses:

1. rapide et sale: envoyez les données non enregistrées à PHP, triez-les là. Évidemment, une solution très coûteuse, car elle serait répétée à chaque appel de la page
2. écrire un plugin dans le moteur de base de données - mais l'administrateur n'était pas prêt à autoriser l'exécution de code étranger sur son serveur, ou
3. vous pouvez traiter les données dans un programme (C, Perl, etc.) et sortir du HTML. Le programme lui-même va dans / cgi-bin, et est appelé directement par le serveur web (par exemple Apache), pas via PHP.

CGI exécute votre script dans la solution n ° 3 et renvoie l'effet au navigateur. Vous avez la vitesse du programme compilé, la flexibilité d'un langage meilleur que SQL, et pas besoin d'écrire des plugins sur le serveur SQL. (Encore une fois, ceci est un exemple spécifique à SQL et C)

Un script CGI est un programme console / shell. Sous Windows, lorsque vous utilisez une fenêtre "Invite de commandes", vous exécutez des programmes de console. Lorsqu'un serveur Web exécute un script CGI, il fournit une entrée au programme console / shell à l'aide de variables d'environnement ou «entrée standard». L'entrée standard est comme taper des données dans un programme console / shell; dans le cas d'un script CGI, le serveur Web effectue la saisie. Le script CGI écrit les données dans une "sortie standard" et cette sortie est envoyée au client (le navigateur Web) sous forme de page HTML. La sortie standard est comme la sortie que vous voyez dans un programme console / shell, sauf que le serveur Web la lit et l'envoie.

Un script CGI peut être exécuté à partir d'un navigateur. L'URI comprend généralement une chaîne de requête fournie au script CGI. Si la méthode est "get", la chaîne de requête est fournie au script CGI dans une variable d'environnement appelée QUERY_STRING. Si la méthode est "post", la chaîne de requête est fournie au script CGI à l'aide d'une entrée standard (le script CGI lit la chaîne de requête à partir de l'entrée standard).

Une des premières utilisations des scripts CGI consistait à traiter les formulaires. Au début du HTML, les formulaires HTML avaient généralement un attribut "action" et un bouton désigné comme bouton "soumettre". Lorsque le bouton d'envoi est enfoncé, l'URI spécifié dans l'attribut "action" est envoyé au serveur avec les données du formulaire envoyées sous forme de chaîne de requête. Si l '"action" spécifie un script CGI, le script CGI sera exécuté et produira ensuite une page HTML.

RFC 3875 "L'interface de passerelle commune (CGI)" définit partiellement CGI en utilisant C, comme en disant que les variables d'environnement "sont accessibles par la routine de bibliothèque C getenv () ou variable environ".

Si vous développez un script CGI à l'aide de C / C ++ et utilisez Microsoft Visual Studio pour ce faire, vous développerez un programme de console.

Un CGI est un programme (ou une API Web) que vous écrivez et enregistrez-le sur le site Web Server. CGI est un fichier.

Ce fichier se trouve et attend sur le serveur Web. Lorsque le navigateur client envoie une demande au serveur Web pour exécuter votre fichier CGI, le serveur Web exécute votre fichier CGI sur le site du serveur. Les entrées de ce programme CGI, le cas échéant, proviennent du navigateur client. Les sorties de ce programme CGI sont envoyées au navigateur.

Quelle langue utilisez-vous pour écrire un programme CGI? D'autres articles mentionnent déjà c, java, php, perl, etc.

L'idée derrière CGI est qu'un programme / script (qu'il s'agisse de Perl ou même de C) reçoit une entrée via STDIN(les données de requête) et génère des données via STDOUT(écho, printfinstructions).

La plupart des scripts PHP ne sont pas éligibles car ils sont exécutés sous le module PHP Apache.