Diskussion:Common Gateway Interface

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Common Gateway Interface“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Was bedeutet "dritte Software" im ersten Satz?

Webbrowser (1), Webserver (2), CGI-Skript (oder -Programm) (3). Gruß, Peritus 16:21, 27. Nov. 2006 (CET)

Hinweis: Mac OS X launchd plist to run PHP fcgi

bin leider noch nicht so tief in der materie, aber vielleicht könnte ja ein php_profi sich dessen mal annehmen http://snippets.dzone.com/posts/show/4115 Thu Jun 07 15:51:36 EDT 2007

Link zu http://cgi-spec.golux.com/ aus folgendem Grund gelöscht:

Browser, die nicht den Vorstellungen der Web-Site-Betreiber entsprechen, werden rüde ausgesperrt, nach einer ganzseitigen Belehrung folgt der Satz: "We receive no benefit from having this link or mentioning these products; we have selected Firefox and Mozilla as our own tools based solely on their quality."

Ich kann eine derartige Politik weder nachvollziehen noch gutheissen und habe daher den Link gelöscht. Wenn jemand Lust hat, darf er ihnen das auch schreiben, selber ist mir das zu blöd.

Mein Browser ist übrigens Konqueror Version 3.5.6.

Daniel

(nicht signierter Beitrag von 77.56.247.213 (Diskussion) 09:47, 25. Aug. 2007) --Shadak 15:12, 5. Jan. 2008 (CET)

Lieber Daniel, ich finde Deine Handlungsweise (wenn dies so stimmt) voll OK. Übrigens der Server war bei jüngsten Aufruf nicht erreichbar. (schad wohl nix). --77.20.204.39 20:42, 16. Okt. 2008 (CEST)

Nachteil mit Neuinterpretierung

Für den Abschnitt "Nachteile": Wenn CGI-Dateien nicht mit interpretierten Skriptsprachen, sondern mit bereits Kompilierten Sprachen (wie zb CGI mit C) gemacht werden, ist es denn auch so langsam oder nicht? Auch wenn CGIs mit C sehr selten sind, ist C ja eigentlich eine sehr schnelle Sprache. --83.79.192.81 22:22, 28. Sep. 2007 (CEST)

Im Grunde hat das Parsen den Löwenanteil. PHP scheint beim Parsen sehr schnell zu sein, Perl hingegen ist sehr (=spürbar) langsam, wenn er das Skript zum ersten mal läd (mit Java ist es so ähnlich). FastCGI vermeidet das, in dem es (vom Prinzip her) einfach eine Endlosschleife um dein eigentliches Programm herumsetzt... C ist an sich nicht schnell, dein Programm ist einfach schon in Maschinencode übersetzt und kann direkt auf der CPU ausgeführt werden -- .love.is.war. 02:34, 16. Apr. 2011 (CEST)

Mehrdeutigkeit - Computer Generated Image?

Wie sieht es mit der Abkürzung CGI für Computer Generated Image(s) aus? Diese Bezeichnung für computergenerierte Spezialeffekte z.B. beim Film ist doch mittlerweile durchaus auch im Deutschen gebräuchlich. 128.176.108.22 17:31, 2. Apr. 2009 (CEST)

Abschnitt „Weitere serverseitige Technologien“

Habe mir mal erlaubt, die Liste des Abschnitts "Weitere serverseitige Technologien" etwas umzusortieren. Bedarf eigentlich einer weiteren Ausmistung (oder einer Erklärung was PHP mit CGI zu tun hat) -- .love.is.war. 02:39, 16. Apr. 2011 (CEST)

Übersetzung

Hat jemand denn einen besseren Übersetzungsvorschlag als den hiermit[1] entfernten? Gruß --dealerofsalvation 08:05, 16. Jun. 2011 (CEST)

Grammatikfehler

"Dass mit CGI Programme, die ein Dritter erstellt hat, auf dem Webserver ausgeführt werden können, ist in höchstem Maße sicherheitsrelevant." soll vermutlich "Dass CGI Programme, die ein Dritter erstellt hat, auf dem Webserver ausgeführt werden können, ist in höchstem Maße sicherheitsrelevant." lauten. --101.108.3.27 03:31, 31. Okt. 2011 (CET)

Was soll an „Dass mit CGI Programme … ausgeführt werden können, ist … sicherheitsrelevant“ grammatisch falsch sein? Dein Vorschlag ist grammatisch falsch, es sei denn, du meinst nicht „Dass CGI Programme …“ (Leerzeichen in Komposita), sondern „Dass CGI-Programme …“ --dealerofsalvation 06:41, 2. Nov. 2011 (CET)

Stimmt wahrscheinlich. Das ist mir vorher noch nicht aufgefallen.--101.108.26.58 03:20, 4. Nov. 2011 (CET)

Na denn. Danke & Gruß --dealerofsalvation 06:09, 4. Nov. 2011 (CET)

Abschnitt "Nachteile" leicht widersprüchlich

1. Im Abschnitt Nachteile steht erstmal, dass sich CGI und auch "selbst Ansätze wie FastCGI" nicht auf breiter Front durchsetzen konnten. Es klingt so, als läge das an der Geschwindigkeit.
2. Dann wird gesagt, dass es daher mittlerweile Module gibt, die schneller sind weil sie nur einmal beim Start des Webservers geladen werden müssen.
3. Im Satz darauf wird aber wieder FastCGI als eine "oft sogar effizientere Möglichkeit" als Module genannt. Dies wird damit begründet, dass die "Anwendung selbst" die ganze Zeit geladen bleiben kann...

Das klingt doch irgendwie nach einem Widerspruch zwischen Punkt 1 und Punkt 3, oder nicht? Was stimmt denn nun? --GGShinobi (Diskussion) 20:17, 9. Mär. 2012 (CET)

Fastcgi hat eigene Nachteile, wegen denen es sich nicht durchsetzen konnte. Allerdings ist (Fast)CGI eine voraussetzung für suexec, was wiederum von Hostern eingesetzt wird um verschiedene User/Kunden auf dem selben Webserver zu trennen. --P.C. ✉ 19:39, 13. Sep. 2012 (CEST)

Abschnitt "CGI-nutzbare Sprachen"

Es sollte ein Abschnitt eingefügt werden, wo die bekanntesten CGI-nutzbaren Sprachen aufgelistet sind wie Python, Perl und co --213.33.98.141 19:14, 13. Sep. 2012 (CEST)

Jede Sprache ist nutzbar. Da wird die Liste aber lang. --P.C. ✉ 19:36, 13. Sep. 2012 (CEST)

Das sollte kein Hinderungsgrund sein. Ich für meinen Teil würde auch "Tcl" (mit mod_tcl) noch mit hinzufügen. ;) Wiesenkraut (Diskussion) 13:37, 22. Sep. 2014 (CEST)

Geschwindigkeit ist relativ

Die Geschwindigkeit eines Interpreters kann hoch oder gering sein. Ein Skript kann kurz und einfach sein, aber auch komplex, mit umfangreicher Aufgabe. So kann eine Aufgabe 100-mal mehr Zeitbedarf haben als das Starten eines neuen Prozesses. Somit ist der Zeitbedarf für das Starten eines neuen Prozesses sehr relativ, möglicherweise meistens fast ohne Bedeutung.

Ich selbst habe auf meinen Webspace einen selbst entwickelten Interpreter /cgi/shell_interpreter (linux-executable 64bit) hochgeladen, der in den ausführbaren Skripten jeweils in der ersten Zeile '#!./shell_interpreter' genannt wird. Der läuft seit 1998 makellos und sehr schnell.

Die Betriebssysteme optimieren zudem das Starten von Prozessen. Es kann beobachtet werden, daß Prozesse bei wiederholten Starts beispielsweise 3-fach schneller starten.

Daß FastCGI sich nicht durchsetzte, ist nicht verwunderlich. Bestehende /cgi/Skripte, an denen vielleicht ein halbes Jahr entwickelt wurde, müßten schließlich neu entwickelt werden! Außerdem ist die herkömmliche CGI-Schnittstelle sehr angenehm, einfach, nützlich und paßt vorzüglich beispielsweise zu einer /bin/sh. --Wphobs (Diskussion) 14:06, 13. Mär. 2018 (CET)

Abgrenzung zu Web Frameworks?

Da mir schon klar war, dass jedes CGI Programm bei jeder Abfrage das Starten eines neuen teuren Prozesses bedeutet, habe ich nach Alternativen gesucht, die das ganze auch in möglichst einem Prozess bewerkstelligt. Mittels der beiden Suchbegriffe "cgi + slow" bin ich dann auf die Seite "Stop Using CGI" geraten. Dort wird ein Web Framework als Alternative zu CGI propagiert. Liest man aber den Wikipedia Artikel zum Thema Webframework durch, dann wird dort gar nicht klar, dass ein Web Framework auch CGI oder FastCGI ersetzen und in diesem Artikel findet man zu dieser Thematik auch nichts. Außer eben, dass gängige Webserver wie bspw. Apache ansonsten noch Module für irgendeine Skriptsprache mitliefern, bei denen dann auch nicht ständig ein neuer Prozess für jede Abfrage gestartet werden muss. Ich finde, das sollte man in dem Artikel oder im Verwandten Artikel Webframework noch einmal klarer herausheben, besonders wenn die Definition auf der verlinkten Seite richtig ist, wovon ich momentan ausgehe. --134.3.80.238 10:19, 31. Okt. 2018 (CET)

Diese beiden Artikel haben eigentlich nichts oder nur wenig miteinander zu tun, sind deshalb auch nicht abzugrenzen.

• Webframework hantiert auf der Ebene der inhaltlichen Autoren, die Texte, Formulare, Dekoration usw. entwickeln, und das ggf. vielfältig verteilt über menschliche Arbeitsgruppen und unterschiedliche Server und Abteilungen.
• CGI ist eine Technik, wie ein Server rein technisch eine Anfrage über das Netz handhabt und beantwortet.
  • Sie ist sogar älter als das „Internet“ (www).
  • Sie beruht architektonisch auf den typischen Unix-Workstations jener Zeit.
  • Damals gab es kaum Anfragen, auch keine Million Netz-Teilnehmer, und deshalb auch keine hochfrequente Auslastung.
  • Deshalb genügte es, simple, leicht zu erstellende Skripte auf dem Server wie halt üblich auszuführen.

Für heutige, skalierbare Hochlast-Dialoge wird man sich nach initialer Lastverteilung andere Architekturen ausdenken, die eine Session mit einem Dialogpartner an einen kontinuierlichen inneren Prozess knüpft und deren Anwendungsprogramm je Server nur einmal im Monat neu gestartet wird und danach möglichst ohne permanente Kindprozesse auf Betriebssystem-Ebene alle Datenbankzugriffe usw. aus dem einen permanenten Prozess heraus ausführen.

• Der CGI-Prozess wird hingegen typischerweise mit dem Senden der Antwort beendet, und die Fortsetzung durch den nächsten Dialog-Schritt des Klienten führt zu einem neuen CGI-Prozess und ggf. eine Verknüpfung mit dem vorangegangenen Schritt mittels einer Session-ID, oft in der URL sichtbar.

CGI-Systeme sind allerdings wesentlich simpler zu bauen, etwa schon durch schlichte Shell-Skrpte, und im ersten Jahrzehnt war das serverseitig auch nichts anderes gewesen.

VG --PerfektesChaos 00:42, 1. Nov. 2018 (CET)

Aber dieses "...nach initialer Lastverteilung anderen Architekturen..usw." ist ja genau das, was dieses Webframework, das in dem verlinkten Artikel erwähnt wird, macht.--134.3.80.238 18:15, 3. Nov. 2018 (CET)

Nö, nicht notwendigerweise.

Der Artikel Webframework beschreibt erstmal nur, dass das eine Ansammlung von Verwaltungsstrukturen und Arbeitsorganisation und Zugriffsrechten und einem oder mehreren Publikums-Frontends sein könne, ohne an irgendeiner Stelle konkret zu werden.

Wie schlau eine Programmierung auf dem Server dann wäre, ob sie mit mehreren gleichzeitig und mit Lastverteilung arbeiten kann oder nicht, hängt ganz vom verwendeten System ab.

Bloß würde man halt heutzutage einen mit Tausenden parallel geöffneter Sitzungen gleichzeitig arbeitenden einzelnen Prozess starten, statt wie zu Zeiten der Telefon-Modems über einzelne Shell-Skripts zu gehen, was natürlich bei einer großen Zahl von Anfragen bös ineffizient werden muss.

Der hiesige Artikel beschreibt eine konkrete technische Umsetzung mit Details wie „Umgebungsvariablen“, wie sie vor dreißig Jahren Stand der Technik war, während Webframework ohne Konkretisierung aufzählt, was eine Installation für viele Anfragen und viele Texte und Datensätze und viele menschliche Bearbeiter und Pfleger so alles drauf haben sollte.

VG --PerfektesChaos 18:47, 3. Nov. 2018 (CET)