„Common Gateway Interface“ – Versionsunterschied

Versionsgeschichte interaktiv durchsuchen

[gesichtete Version]

[ungesichtete Version]

← Zum vorherigen Versionsunterschied Zum nächsten Versionsunterschied →

Inhalt gelöscht Inhalt hinzugefügt

Inline

Version vom 13. Mai 2023, 18:16 Uhr

Das Common Gateway Interface (CGI) ist eine Schnittstelle für den Datenaustausch zwischen einem Webserver (Anwendungsprogramm) und dritter Software, die Anfragen bearbeitet.^[1] CGI ist eine Variante, Webseiten dynamisch bzw. interaktiv zu machen. Die erste Nutzung im World Wide Web war im Jahr 1993.

Funktionsweise

Ein Webserver mit CGI stellt entsprechenden Subroutinen, Bibliotheken, Scripts oder Programmen einige Umgebungsvariablen zur Verfügung. Zwingend existieren diese neun Umgebungsvariablen:

GATEWAY_INTERFACE
QUERY_STRING
REMOTE_ADDR
REQUEST_METHOD
SCRIPT_NAME
SERVER_NAME
SERVER_PORT
SERVER_PROTOCOL
SERVER_SOFTWARE

Der Webserver setzt HTTP auf CGI um, startet die entsprechende Software und setzt letztlich umgekehrt von CGI in HTTP um.

Optional stellt die Spezifikation frei anders als per Standardeingabe und Standardausgabe zu kommunizieren.

Vorteile

Statt nur statische Seiten von einem Webserver zu laden, die dort als fertige Ressource zur Verfügung stehen, ist es mit CGI auch möglich, HTML-Seiten dynamisch zu erzeugen. D. h. diese müssen zur Zeit der Anfrage noch nicht auf dem Server existieren, sondern können vom CGI-Programm erzeugt werden.

Außerdem können CGI-Programme in jeder Programmiersprache geschrieben sein, die das Betriebssystem unterstützt, da die Anforderungen nicht über o. g. hinausgehen.^[2]

Nachteile

Ein Nachteil der CGI-Ausführung ist neben dem Sicherheitsrisiko, sofern kein entsprechender Schutz eingerichtet ist, ihre relativ geringe Geschwindigkeit, da für jeden CGI-Aufruf ein neuer Prozess gestartet wird. Zudem unterstützen viele Server nur eine limitierte Anzahl an CGI-Anfragen, weshalb viele Anfragen in Warteschlangen bleiben oder sogar abgewiesen werden.

Alternativen, die auf CGI aufbauen, jedoch das Bootstrapping der Prozesse umgehen können, sind z. B. FastCGI, ASP, PHP (welches in neueren Versionen FastCGI verwendet) und ColdFusion.^[3]

Daneben gibt es Module, z. B. für den Apache-Webserver, die den Interpreter für verschiedene Scriptsprachen (z. B. mod_perl für Perl, mod_python für Python etc.) direkt in den Webserver-Prozess einbinden. Dieser wird so nur einmal beim Start des Webservers geladen, anstatt bei jeder Anfrage neu. Doch auch diese Ausführung bringt Nachteile mit sich, etwa weil die Verlässlichkeit des Servers sich durch zusätzliche, teilweise separat vom Server gepflegte Module, verringern kann.

Die Programme weiterhin als externe Prozesse laufen zu lassen, ihnen die Anfragen jedoch per FastCGI zu übergeben, ist der Lösungsweg, der dem CGI-Prinzip am ehesten treu bleibt. Hierbei kann, anders als bei der o. g. Einbindung als Apache-Modul, nicht nur der Interpreter der Programmiersprache dauerhaft laufen. Auch die Anwendung selbst kann die ganze Zeit geladen bleiben und so die eingehenden Anfragen noch effizienter bearbeiten.

Sicherheit

Dass Programme, die ein Dritter erstellt hat, auf dem Webserver ausgeführt werden können, ist in höchstem Maße sicherheitsrelevant. Daher muss sichergestellt sein, dass ein über CGI gestartetes Programm nur bestimmte, eingeschränkte Typen von Programmroutinen ausführen darf (z. B. kein Löschen von Dateien des Webservers u. ä.).

Bei dem Apache-Webserver wird die Ausführung von CGI-Programmen mit Hilfe des Modules mod_suexec gegen solche Cracker-Angriffe gesichert, die das Eindringen als Root-User zum Ziel haben. Die Sicherheitsmaßnahmen sind dabei mehrstufig aufgebaut und so streng, dass viele Server-Administratoren dazu übergegangen sind, auch andere serverseitige Sprachen über CGI laufen zu lassen.

Siehe auch

Weitere serverseitige Technologien

Weblinks

Glossar:CGI im SELFHTML-Wiki

Einzelnachweise

↑ The Common Gateway Interface (CGI) Version 1.1. RFC 3875. Internet Society, Oktober 2004, abgerufen am 23. Oktober 2022.
↑ Common Gateway Interface. National Center for Supercomputing Applications, archiviert vom Original am 9. April 2009; abgerufen am 24. Oktober 2022.
↑ Was ist ein CGI? Abgerufen am 16. Februar 2022.

[RFC-1] The Common Gateway Interface (CGI) Version 1.1. RFC 3875. Internet Society, Oktober 2004, abgerufen am 23. Oktober 2022.

[NCSA-2] Common Gateway Interface. National Center for Supercomputing Applications, archiviert vom Original am 9. April 2009; abgerufen am 24. Oktober 2022.

[3] Was ist ein CGI? Abgerufen am 16. Februar 2022.

[1]

[2]

[3]

@@ Zeile 22: / Zeile 22: @@
 == Nachteile ==
+Ein Nachteil der CGI-Ausführung ist neben dem Sicherheitsrisiko, sofern kein entsprechender Schutz eingerichtet ist, ihre relativ geringe Geschwindigkeit, da für jeden CGI-Aufruf ein neuer [[Prozess (Informatik)|Prozess]] gestartet wird. Zudem unterstützen viele Server nur eine limitierte Anzahl an CGI-Anfragen, weshalb viele Anfragen in [[Warteschlange (Datenstruktur)|Warteschlange]]n bleiben oder sogar abgewiesen werden.
-{{Überarbeiten|grund=Zuerst wird ausgedrückt, dass FastCGI sich nicht auf breiter Front durchsetzen konnte (was ich schon nicht glaube, da die meiste Literatur die ich finde eher empfiehlt, FastCGI statt Webserver-Module zu benutzen), danach wird aber erwähnt, dass FastCGI eine Alternative für Webserver-Module darstellt und dabei noch effizienter ist.|2=Dieser Abschnitt}}
+Alternativen, die auf&nbsp;CGI aufbauen, jedoch das Bootstrapping der Prozesse umgehen können, sind z.&nbsp;B. [[FastCGI]], [[Active Server Pages|ASP]], [[PHP]] (welches in neueren Versionen ''FastCGI'' verwendet) und [[ColdFusion]].<ref>{{Internetquelle |url=https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-ein-cgi/ |titel=Was ist ein CGI? |sprache=de |abruf=2022-02-16}}</ref>
-Ein Nachteil der CGI-Ausführung ist neben dem Sicherheitsrisiko, sofern kein entsprechender Schutz eingerichtet ist, ihre relativ geringe Geschwindigkeit, da für jeden CGI-Aufruf ein neuer [[Prozess (Informatik)|Prozess]] ausgeführt wird. Zudem unterstützen viele Server nur eine limitierte Anzahl an CGI-Anfragen, weshalb viele Anfragen in [[Warteschlange (Datenstruktur)|Warteschlange]]n bleiben oder sogar abgewiesen werden.
+Daneben gibt es [[Modul (Software)|Modul]]e, z.&nbsp;B. für den [[Apache HTTP Server|Apache-Webserver]], die den [[Interpreter]] für verschiedene [[Scriptsprache]]n (z.&nbsp;B. [[mod&#95;perl]] für [[Perl (Programmiersprache)|Perl]], [[mod&#95;python]] für [[Python (Programmiersprache)|Python]] etc.) direkt in den Webserver-Prozess einbinden. Dieser wird so nur einmal beim Start des Webservers geladen, anstatt bei jeder Anfrage neu. Doch auch diese Ausführung bringt Nachteile mit sich, etwa weil die Verlässlichkeit des Servers sich durch zusätzliche, teilweise separat vom Server gepflegte Module, verringern kann.
-Alternativen, die auf&nbsp;CGI aufbauen, jedoch die wiederkehrende Prozessausführung umgehen können, sind z.&nbsp;B. [[FastCGI]], [[Active Server Pages|ASP]], [[PHP]] und [[ColdFusion]].<ref>{{Internetquelle |url=https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-ein-cgi/ |titel=Was ist ein CGI? |sprache=de |abruf=2022-02-16}}</ref>
+Die Programme weiterhin als externe Prozesse laufen zu lassen, ihnen die Anfragen jedoch per [[FastCGI]] zu übergeben, ist der Lösungsweg, der dem CGI-Prinzip am ehesten treu bleibt. Hierbei kann, anders als bei der o.&nbsp;g. Einbindung als Apache-Modul, nicht nur der Interpreter der Programmiersprache dauerhaft laufen. Auch die Anwendung selbst kann die ganze Zeit geladen bleiben und so die eingehenden Anfragen noch effizienter bearbeiten.
-Auch gibt es [[Modul (Software)|Modul]]e, z.&nbsp;B. für den [[Apache HTTP Server|Apache-Webserver]], die den [[Interpreter]] für verschiedene [[Scriptsprache]]n (z.&nbsp;B. [[mod&#95;perl]] für [[Perl (Programmiersprache)|Perl]], [[mod&#95;python]] für [[Python (Programmiersprache)|Python]] etc.) direkt in den Webserver-Prozess einbinden. Dieser wird so nur einmal beim Start des Webservers geladen, anstatt bei jeder Anfrage neu.
-Eine andere, oft sogar effizientere Möglichkeit ist, die Programme weiterhin als externe Prozesse laufen zu lassen, ihnen die Requests des Browsers jedoch per [[FastCGI]] zu übergeben. Hierbei kann, anders als bei der o.&nbsp;g. Einbindung als Apache-Modul, nicht nur der Interpreter der Programmiersprache dauerhaft laufen, auch die Anwendung selbst kann die ganze Zeit geladen sein und so die eingehenden Anfragen noch effizienter bearbeiten.
 == Sicherheit ==

Protokolle	CGI \| SCGI \| FastCGI \| AJP
APIs	C NSAPI \| C ASAPI \| C ISAPI \| Jakarta Servlet \| ASP.NET \| Python WSGI \| Ruby Rack \| JavaScript JSGI \| PSGI \| Lua WSAPI
Apache-Module	mod_jk \| mod_lisp \| mod_parrot \| mod_perl \| mod_php \| mod_python \| mod_wsgi \| mod_ruby \| Phusion Passenger
Web APIs	WSDL \| XML-RPC \| SOAP \| REST