4. cgi mit c und html

cgi mit c und html

  • ?

    Auf meinem Webspace funktionieren meine CGIs mit C++ nicht. Aber auf meinem lokalen Server funktionieren alle Scripte.

    Ich vermute das es daran liegt, dass ich die Datei als ausführbare Windowsdatei erstelle und nicht als ausführbare Linuxdatei. Die meisten Webserver laufen aber alle mit Linux. Mein Problem dabei ist, dass ich kein Linux hab. Und wenn, dann hätte ich davon keine Ahnung.

    hier mein Test\1:

    #include <stdio.h>

int main()
{
  printf("Content-Type: text/html\n\n");
  printf("Hier ein Text. Einfacher geht es nicht.");
  return 0;
}

    Könnt ihr mir helfen?

    0
  • E

    Das wird net hinhauen. Du kannst keine Windowsdatei unter linux einfach so ausführen. Auserdem solltest du mal prüfen ob du überhaupt Binarys auf deinem Server ausführen darfst. Bei den meisten is das nämlich nicht erlaubt.

    muss es eigntlich unbedingt c sein?

    #include <iostream>
#include <string>
#include <fstream>
#include <cstdlib>
#include <unistd.h>

using namespace std;

int main(){

 string buffer=getenv("QUERY_STRING");
 int pos(0);
 int buffergr(0);
 int i(0);

 pos=buffer.find("=");
 buffer.erase(0, pos+1);
 buffer.insert(3, "*");

 ofstream abrufscript("abrufen.sh");

 abrufscript << "cat " << buffer << " > datei"; 

 abrufscript.close();

 system("./abrufen.sh");  

 cout << "Content-type:text/html" << endl << endl;
 cout << "<HTML>" << endl;
 cout << "<BODY>" << endl;
 cout << "Zum abrufen/speichern der Logdaten " << endl;
 cout << "<a href=\"/*********\">hier </a> klicken" << endl;
 cout << "<br />" << endl;
 cout << "<br />" << endl;

 cout << "</BODY>" << endl;
 cout << "</HTML>" << endl; 

return 0;

}

    Das hab ich vor langer Zeit mal geschrieben um die Daten aus einer Datei an den server auszugeben is zwar in c++ aber evtl hilfts dir weiter.

    0
  • B

    So, hab mich jetzt erst mal registriert. 🙂

    Zu deiner Frage: Auf meinem Server darf ich CGIs ausführen. Pearl funktioniert auch, aber eben nicht meine erstellten C++Programme.

    Dein Programm hab ich auch ausprobiert. Hab aber vorher ein wenig gekürzt. 😉

    #include <iostream>
#include <string>
#include <fstream>
#include <cstdlib>
#include <unistd.h>

using namespace std;

int main(){
 cout << "Content-type:text/html" << endl << endl;
 cout << "<HTML>" << endl;
 cout << "<BODY>" << endl;
 cout << "Zum abrufen/speichern der Logdaten " << endl;
 cout << "<a href=\"/*********\">hier </a> klicken" << endl;
 cout << "<br />" << endl;
 cout << "<br />" << endl;

 cout << "</BODY>" << endl;
 cout << "</HTML>" << endl;

 return 0;
}

    Das Programm läuft ebenfalls auf meinem lokalen Server aber nicht auf meinem Webserver. "500 Internal Server Error"

    Wie ich schon gesagt habe liegt der Fehler sicher daran, dass ich nicht in Linux compiliert habe. Falls also jemand Linux hat, kann der mal bitte diesen Code zum Testen compilieren? 🙂

    0
  • ?

    das du skripte ausführen darfst, heißt noch lange nicht, das die auch als .exe laufen dürfen
    musste deinen webadmin konsultiern

    0
  • T

    byter schrieb:

    Ich vermute das es daran liegt, dass ich die Datei als ausführbare Windowsdatei erstelle und nicht als ausführbare Linuxdatei. Die meisten Webserver laufen aber alle mit Linux. Mein Problem dabei ist, dass ich kein Linux hab. Und wenn, dann hätte ich davon keine Ahnung.

    Wenn Du Linux hättest, hättest Du doch Ahnung davon 😃

    Na ja - hast Du wirklich erwartet, daß Du ein Windows-Programm unter Linux ausführen kannst? Wenn Du unter Windows ein C-Programm übersetzt, bekommst Du eine Exe-Datei für Windows. Das kannst Du unter anderen Betriebssystemen nicht ausführen. Deinen Quellcode kannst Du allerdings unter Linux compilieren. Dann bekommst Du ein Linux-Programm und das sollte auf einem Linux-Webserver auch funktionieren.

    Mit interpretierten Sprachen verhält es sich halt anders. Die werden zur Laufzeit übersetzt. Und wenn Du ein Perl oder PHP Skript unter Linux ausführst, wird es zur Laufzeit (vereinfacht dargestellt) von dem Interpreter in ausführbaren Linux-Code übersetzt.

    0
  • B

    @CGI
    Ich hab auch schon meinen Webmaster gefragt, aber der hat leider keine Ahnung davon. Er hat mir nur gezeigt, dass Pearl-Scripte mittels CGI funktionieren. Da werd ich nochmal nachfragen müssen.

    Wenn Du Linux hättest, hättest Du doch Ahnung davon 😃

    Gute Schlussfolgerung! 😃

    Mit interpretierten Sprachen verhält es sich halt anders. Die werden zur Laufzeit übersetzt. Und wenn Du ein Perl oder PHP Skript unter Linux ausführst, wird es zur Laufzeit (vereinfacht dargestellt) von dem Interpreter in ausführbaren Linux-Code übersetzt.

    Kann ich mir gut vorstellen. Deshalb wäre es nett, wenn jemand mir vielleicht mal den Quellcode in Linux compilieren würde, damit ich testen könnte ob es daran liegt.

    PS: Habs jetzt doch rausgefunden. Liegt wirklich daran, dass ich nicht unter Linux compiliert habe. Muss mich also wohl oder übel mit Linux auseinandersetzten.

    0
  • ?

    Ich habe früher viel mit CGI rumprobiert. Die meisten Provider, die ich so angetestet habe, hatten einen Standard CGI-Ornder mit einem Auto-Link zum Perlinterpreter.
    Der Perlinterpreter konnte dann auch nichts mit meinem C-Programm anfangen.
    Gruß,
    CGI

    0
  • ?

    Edit:
    Aus diesem Grund wage ich jetzt mal eine Voraussage:
    Es wird auch nicht als Linux-Compilat Funktionieren.

    Warum benutzt du nicht einfach Perl ?
    ( Wobei auch bei Perl nicht alle Funktionen freigeschaltet sein müssen )

    0
  • B

    Ich hab nun was gefunden wo steht, dass ich in Linux compilieren muss. Und auf meinem lokalen Server funktioniert es ja.

    Warum ich mit C/C++ arbeite?
    Ich kann zwar schon gut mit PHP umgehen. Aber wenn ichs mit C/C++ mache, dann kann ich noch viel dazu lernen z.B. mit Strings umzugehen. Außerdem hat eine compiliertes Programm auch Vorteile z.B. sind komplexere Scripte etwa 3 mal schneller verarbeitet (hab ich getestet). Und die Scripte sind auch sicherer und schwerer zu knacken.

    0
  • ?

    Und die Scripte sind auch sicherer und schwerer zu knacken.

    Dummes Geschwätz. Warum soll eine eigens gefrickelte CGI Lösung in C/C++ pauschal sicherer sein als eine Scriptlösung? Meine Fresse, hauptsache was erzählt.

    Und bei einem normalen Webhostingprovider darfst du in hundert Jahren keine Anwendungen laufen lassen. Um eigene Anwendungen auszuführen benötigst du einen dedizierten Server, oder zumindest einen V-Server.

    0
  • ?

    byter schrieb:

    Ich hab nun was gefunden wo steht, dass ich in Linux compilieren muss. Und auf meinem lokalen Server funktioniert es ja.

    Ja, auf deinem Server. Generell bestreitet ja niemand, das es nicht möglich ist.
    Du hast aber nichts davon, wenn du es auf deinem Webspace laufen lassen willst, dies aber von deinem Provider nicht unterstützt wird.
    Logisch ne ?

    0
  • T

    byter schrieb:

    Ich hab nun was gefunden wo steht, dass ich in Linux compilieren muss. Und auf meinem lokalen Server funktioniert es ja.

    Warum ich mit C/C++ arbeite?
    Ich kann zwar schon gut mit PHP umgehen. Aber wenn ichs mit C/C++ mache, dann kann ich noch viel dazu lernen z.B. mit Strings umzugehen. Außerdem hat eine compiliertes Programm auch Vorteile z.B. sind komplexere Scripte etwa 3 mal schneller verarbeitet (hab ich getestet). Und die Scripte sind auch sicherer und schwerer zu knacken.

    Du arbeitest schon mal nicht mit C/C++, sondern entweder mit C oder mit C++.

    Und wenn Du was dazu lernen willst, dann solltest Du das auf Deinem Rechner zu Hause machen und nicht auf einem Server im Internet. Einen Server im Internet zu betreiben ist eine verantwortungsvolle Aufgabe, bei der man nicht einfach mal experimentieren sollte.

    Ausserdem wage ich zu bezweifeln, daß deine CGIs, die Du mit C schreibst, wirklich schneller sind, als PHP. CGI ist langsam. Für jeden Request wird ein Prozess gestartet. Das passiert bei PHP nicht. Ich habe auf meinem Rechner mal einfache Benchmarks gemacht, wo ein einfaches Skript mit PHP ca. 700 Requests geschafft hat und das äquivalente C-CGI ca. 70, also nur etwa ein Zehntel. Das ändert sich erst, wenn das C-Programm genauso persistent ist, wie PHP. Das ereichst Du aber erst mit FastCGI oder meinem Tntnet.

    0
  • B

    Außerdem hat eine compiliertes Programm auch Vorteile z.B. sind komplexere Scripte etwa 3 mal schneller verarbeitet (hab ich getestet). Und die Scripte sind auch sicherer und schwerer zu knacken.

    Ich hab das zumindest gelesen in dem Buch "C von A bis Z".

    Hier ein paar Ausschnitte aus dem Buch:
    - Weniger Zugriffe auf den Server, auf dem sich das CGI-Script befindet. Das heißt es muss nicht erst ein Interpreter gestartet werden, der das Script übersetzen muss (finde ich am überzeugendsten)
    - Da der Quelltext bei Executables nicht offen ist, lassen sich Sicherheitsfunktionen hervorragend verstecken.

    Das wichtigste ist für mich im Endeffekt, dass ich etwas in C++ dazu lerne und es eventuell auch irgendwo sinnvoll nutzen kann.

    Und wenn Du was dazu lernen willst, dann solltest Du das auf Deinem Rechner zu Hause machen und nicht auf einem Server im Internet. Einen Server im Internet zu betreiben ist eine verantwortungsvolle Aufgabe, bei der man nicht einfach mal experimentieren sollte.

    Da muss ich zustimmen. Ich mach aber trotzdem weiter, damit ich irgendwann auch meine Seiten mit C-CGI machen kann. (werde ich aber sicher vorher auf meinem PC testen 🙂 )

    Und ob es nun auf meinem Webspace funktioniert muss ich einfach nur mal ausprobieren. Wie ich schon gesagt hatte, fände ich es toll, wenn jemand mal für mich diesen Code (siehe vorherige Beiträge) auf Linux compilieren würde, damit ich das mal testen kann. Danke! 😉

    0
  • C

    byter schrieb:

    - Da der Quelltext bei Executables nicht offen ist, lassen sich Sicherheitsfunktionen hervorragend verstecken.

    Diesen Punkt verstehe ich nicht, vor allem aus zwei Gruenden:
    1. "Sicherheitsfunktionen" die auf verstecktem Quellcode beruhen sind nicht sicher.
    2. Wenn ein Angreifer deine Skripte in Roh-Form (nicht interpretiert oder ausgefuehrt) sehen kann, ist es eh zu spaet.

    0
  • ?

    Was soll bitte an CGI langsam sein? CGI ist eine Schnittstelle. Ok, es wird ein neuer Prozess erzeugt, danach wird jedoch Maschinenkode ausgeführt! Das ist mindestens 10mal schneller aus erstmal ein Script zu parsen, in bytcode wandeln und es anschliessend auszuführen.

    Für jeden HTTP-Request werden bei Apache auch extra Prozesse erzeugt. Diese Prozesse sind jedoch, im Gegensatz zu den "leichten" Maschinenkode ~30-70MB gross, weil alle mod_php+mod_perl-Interpreter mitgeladen werden.

    Ich kann dir Kode posten, der in PHP ~12 Stunden braucht und in C unter 10 Sekunden läuft. (XML-Parsing und Notes extrahieren).

    siehe http://www.mrunix.de/forums/showthread.php?t=50206&highlight=php+cgi

    0
  • ?

    Thread != Prozess

    0
  • T

    hjol hl schrieb:

    Was soll bitte an CGI langsam sein?

    Bei CGI wird für jeden Request ein separater Prozess gestartet. Und das dauert halt. PHP läuft üblicherweise als Apache-Modul und ist damit persistent. Ein PHP-Programm an sich läuft sicher langsamer als ein C-Programm. Ist die Laufzeit des Programms allerdings relativ kurz, dann macht sich der Overhead zum Starten eines Prozesses signifikant bemerkbar.

    Ich habe hier mal eine kleine Hello-World-Webseite mit verschiedenen Technologien realisiert und mit ab (apache bench) getestet. Die Ergebnisse sind wie folgt:
    [] CGI/Perl - 28 Requests/s
    [    ] CGI/C - 244 Requests/s
    [] PHP - 2950 Requests/s
    [    ] Tntnet - 8770 Requests/s
    [*] statische Seite - 8910 Request/s

    Wir sehen deutlich, daß die CGI-Lösungen signifikant langsamer sind. Verstärkt wird der Effekt sicher auch durch die kurze Gesamtlaufzeit. Aber genau das ist die Regel bei Webapplikationen.

    PHP wird interpretiert und ist dennoch wesentlich schneller, als die C/CGI-Lösung. Unter Tntnet laufen Webapplikationen nativ und sind persistent im Speicher. Es entsteht weder Overhead durch Prozessstart noch durch Interpretation. Daher sind die Programme mit statischen Seiten vergleichbar.

    C ist wie auch C++ sehr schnell in der Ausführung. Das ist aber kein Garant für schelle Applikationen. Wenn ich einen ungünstigen Algorithmus oder Verfahren wähle (wie CGI) kann eine native Applikation wesentlich schlechter sein, als eine interpretierte.

    In der Diskussion, auf die Du verweist wird von Erweiterungen gesprochen, die in C kodiert sind. Das sind keine CGI-Programme. Extensions sind Bibliotheken, die genauso persistent sind, wie die PHP-Skripte. Natürlich sind die schneller.

    Das Beispiel, wo PHP 12 Stunden benötigt und C 10 Sekunden ist Blödsinn. Hier wird mit PHP ein XML-Parser aufgerufen und mit C ein anderer. Hier werden die Parser verglichen und nicht wie schnell die Programme sind, die sie aufrufen. Ich glaube kaum, dass hier im PHP-Code selbst viel Zeit verbraucht wird. Daher könnte das Ergebnis genausogut umgekehrt sein.

    0
  • S

    Hi tntnet,

    was ein Unsinn.

    Was hat die Anzahl der Requests mit der Laufzeit eines CGI-Programms zu tun ?

    PHP ist eine lahme Krücke für Heim-und-Hobby-Programmierer wo es auf die Laufzeit
    der Programme nicht weiter ankommt. Also relativ kleine Sachen. Sobald es etwas
    komplexer wird zeigt PHP deutliche Schwächen.

    PHP ist nunmal ein Interpreter. Der muß erst mal geladen und gestartet werden,
    dann lädt er den Quelltext, analysiert den und führt ihn dann aus. Zu diesem
    Zeitpunkt ist ein .exe-File aber schon fertig und die Ergebnisse sind im Browser.

    0
  • T

    Hallo Scheppertreiber,

    die Anzahl der Request ist das, was beim Endanwender ankommt. Dem ist das egal, ob der Server während er auf seine Seite wartet gerade ein PHP-Skript interpretiert oder ein Prozess startet. Und auch dem Server ist es relativ Egal. Hauptsache er kann seine Arbeit zügig erledigen. Und mein einfacher Benchmark zeigt, dass das starten eines Prozesses durchaus signifikant sein kann.

    Du hast natürlich recht, dass die Verarbeitungsgeschwindigkeit von PHP gegenüber compilierten Code durchaus unterschiedlich sein kann. Genau das ist es ja letzten Endes, was tntnet von PHP unterscheidet. Aber bei CGI/C ist 244 Request pro Sekunde so etwa das Maximum, was mein Rechner hier erreichen kann. Egal, wie schnell das C-Programm ausgeführt wird.

    Bei komplexeren Anwendungen wird die Geschwindigkeit (oder Langsamkeit) von PHP sicher signifikanter. Aber es ist einfach falsch anzunehmen, dass ich mein Programm in C Schreibe und es dadurch automatisch schneller wird.

    Und nein - der PHP-Interpreter muss nicht erst mal geladen und gestartet werden, da er bei im Normalfall (mod_php) bereits geladen ist.

    0
  • S

    Das .exe-File hängt genauso im Cache wie der PHP-Quelltext. Ich weiß nicht, wo es
    da Unterschiede geben könnte. Meistens ist die Laufzeit des Programms eh wurscht,
    die Antwortzeiten ergeben sich aus der Übertragung über http.

    egal, ich hatte PHP mal ausprobiert und für zu leicht befunden. Ist ja auch in C
    geschrieben, da nehme ich lieber das Original 🙂

    0
Anmelden zum Antworten