![]() |
cgi mit c/c++
hi leute!
da ich zur zeit nix zu tun hab, wollt ich mal erfragen ob jemand ein online-tutorial oder buch zum thema cgi scripts mit c kennt bzw weiss wo ich sowas finde cu pong |
weiss das denn keiner :heul:
|
auf http://www.jmarshall.com/easy/cgi/german/ gibts ein kleines Tutorial
|
|
danke leute aber kanns sein, dass es wirklcih fast keine cgi scripts in c gibt nur in perl?
|
Perl ist weitaus schneller, da man eigene Module (mod_cgi oder noch besser mod_perl) in den Apache integrieren kann.
Compilen fällt auch weg, so kann das Script schneller geändert und getestet werden. Meistens läßt der Server gar keine C-Scripten zu, ist ein kleines Sicherheitsproblem. Sloter |
mod_perl ist aber auch ein Sicherheitsrisiko und wird daher auf 99,99% der virtuellen Accounts nicht angeboten. Nebenbei müssen die Perl Scripte speziell an mod_perl angepasst werden.
Wenn es speziell nur für Websites gebraucht wird, würde ich PHP nehmen da das fast immer als Servermodul installiert ist und daher wesentlich schneller als Perl ausgeführt wird. |
Mit suexec kombinieren, dann sinkt das Sicherheitsproblem fast auf null.
Sloter |
Wieso macht das dann keiner? Vielleicht weil es doch nicht so einfach ist :). Die 1-2 Provider die das Anbieten erlauben auch nicht das jedes x-beliebige Script installiert wird.
mod_perl ist im Vergleich zu Perl als CGI unkontrolierbar. Es kann nicht wie PHP konfiguriert werden (z.b. Safemode) und der Ram Verbrauch bei schlechten Scripts ist sehr hoch. Beispielsweise UBB 6.0 kann manchmal bis zu 400MB :eek: unter mod_perl belegen. Bei Mandrake wird beispielsweise deshalb mod_perl nicht am normalen Webserver installiert sondern es wird ein zweiten httpd-perl (Apache mit mod_perl) installiert der nur für mod_perl zuständig ist. So ist gewährleistet das selbst wenn der mod_perl Server crasht bzw. überlastet ist die Website noch funktioniert. |
1, Mod_Cgi ist halt einfach zu installieren, und ich kenne eine Menge Server wo mod_perl istalliert ist. Ist einfach weitaus schneller als mod_cgi (200-300% bei manchen Scripten).
Jeder vernünftige Dienstleister darf bei den Kundenscripten keine Auswahl treffen. Das währe ja selbstmord, Kunde bezahlt für den Account und der Provider schmeißt die Scripten wieder runter, wenn sie ihm nicht gefallen. Das kommt nur bei Wohnzimmerprovider vor, die einen schwachen Rechner haben, und keiner eine Serverlast erzeugen darf. Sonst geht der Compi mit 128 Ram gleich in die Knie ;) Ausserdem ist es egal was die Kunden raufladen, du kannst mit Apachemodule die Prozessorzeit und den Ramverbrauch steuern, so kann keiner den Server mit einem Prozess abschießen. ZB. Ein Script darf maximal 10 Sec. und nicht mehr als 5 MB Ram verbrauchen ;) 2, Für das gibt es Suexec: Das steuert den Zugriff auf Scripten und ist gnadenlos beim Überwachen und ausführen (siehe meinen Thread über Suexec) 3, Hä, 2 Apachen am selben Port :confused: Sloter |
Alle Zeitangaben in WEZ +2. Es ist jetzt 06:45 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag