Diskussion:Common Gateway Interface
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen.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
- 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.
- Dann wird gesagt, dass es daher mittlerweile Module gibt, die schneller sind weil sie nur einmal beim Start des Webservers geladen werden müssen.
- 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 meinem 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. --wphobs