Indy Webserver mit PHP und CGI

[GerhardS]

Hallo,
hier im Forum bin ich auf die kühne Behauptung in Bezug auf die Indy Webserver-Komponente gestoßen:
"Ja, PHP, CGI und Co. kann man ja fast wie eine Consolenanwendung aufrufen, bzw. wie eine DLL einbinden und so aufrufen."
(Quelle: http://www.delphipraxis.net/164814-f...webserver.html)
Da ich schon lange nach einer Möglichkeit suche, einen lokalen "Webserver" mit Delphi zu bauen, mit dem Anwender ihre künftige Webseite (incl. HTML-, PHP- und CGI-Code) lokal testen können, interessiert mich die Einbindung von PHP und CGI in den Indy-Webserver enorm.
Gibt's dafür eine Beispiellösung?
Danke im Voraus.

[nuclearping]

Zitat von GerhardS:

Da ich schon lange nach einer Möglichkeit suche, einen lokalen "Webserver" mit Delphi zu bauen, mit dem Anwender ihre künftige Webseite (incl. HTML-, PHP- und CGI-Code) lokal testen können

Warum benutzt du kein WAMP? Apache inkl. aller Extensions (PHP / CGI), MySQL, ... gibts doch auch für Windows? Wozu einen eigenen Server bauen? Oder verstehe ich da jetzt was falsch?

[mjustin]

PHP und CGI sind einfache Anwendungen (EXE), die von der Standardeinggabe lesen und auf der Standardausgabe ausgeben.

Daher kann man den PHP Interpreter (PHP.EXE) oder eine CGI Anwendung im Indy OnCommandGet aufrufen und dann aus Standardausgabe den HTML Code auslesen und an den Client zurücksenden.

Als wichtigsten Baustein braucht man ein Stück Delphi Code, mit dem man einen String (oder Stream) an einen Prozess als Standardeingabe übergeben und seine AUsgaben zurück in einen String (oder Stream) einliest.

p.s.

Codebeispiele habe ich hier gefunden:

http://www.delphipraxis.net/119316-a...e-fassung.html
http://stackoverflow.com/questions/8...ole-stin-sterr

p.p.s.:

PHP von einem eigenen Webserver aus aufzurufen ist nicht besonders kompliziert. Der Ablauf wird auf Stackoverflow hier beschrieben: http://stackoverflow.com/a/7047581/80901

Man definiert einige Umgebungsvariablen, und ruft dann den PHP Interpreter auf. Bei einem GET übergibt man PHP einfach nur den Skriptdateinamen als Umgebungsparameter:

Code:

setenv GATEWAY_INTERFACE="CGI/1.1"
setenv SCRIPT_FILENAME=/path/to/script.php
setenv QUERY_STRING="id=123&name=title&parm=333"
setenv REQUEST_METHOD="GET"
...

exec /usr/bin/php-cgi

Bei einem POST schreibt man beim Aufruf des Interpreters den PPOST Body in die Standardeingabe.

In beiden Fällen erhält man den HTML Response Code von der Standardausgabe des PHP Prozesses.

[Progman]

Zitat von nuclearping:

Warum benutzt du kein WAMP? Apache inkl. aller Extensions (PHP / CGI), MySQL, ... gibts doch auch für Windows? Wozu einen eigenen Server bauen? Oder verstehe ich da jetzt was falsch?

Exakt. Für Windows heißt es XAMPP. Das nutze ich seit Jahren, um Webseiten-Projekte lokal zu testen, bevor sie auf den Webserver des Providers gespielt werden.

[Klaus01]

WAMP - Windows - Apache - PHP
LAMP -> Linux - Apache - PHP
MAMP -> Mac - Apache - PHP
XAMPP -> OS egal - Apache - PHP - Perl

ups- überall mySQL vergessen..

Grüße
Klaus

[mjustin]

Zitat von nuclearping:

Zitat von GerhardS:

Da ich schon lange nach einer Möglichkeit suche, einen lokalen "Webserver" mit Delphi zu bauen, mit dem Anwender ihre künftige Webseite (incl. HTML-, PHP- und CGI-Code) lokal testen können

Warum benutzt du kein WAMP? Apache inkl. aller Extensions (PHP / CGI), MySQL, ... gibts doch auch für Windows? Wozu einen eigenen Server bauen? Oder verstehe ich da jetzt was falsch?

Das könnte in der Praxis bei einer Migration von PHP nach Delphi verwendet werden. Der mit Indy geschriebene Webserver delegiert dann alle *.php URLs an den PHP Interpreter. Nach und nach kann man aber den PHP Anteil zurückschrauben (einzelne Seiten werden dann mit einer in Delphi erzeugten Response beantwortet). Nach aussen ändert sich dabei nichts. Ermöglicht auch Caching und Filterung (Nachbearbeitung der Response).

Allerdings gebe ich gerne zu dass es auch einfacher geht - ein vorgeschalteter Apache beantortet die PHP Anfragen, ausser solche, für die es eine Weiterleitungsregel an den im internen Netz stehenden Delphi Webserver gibt. Der kann dann anstelle des PHP Interpreters diese Requests übernehmen.

[GerhardS]

Da viele Anwender zwar eine eigene Website haben, sich aber nicht mit HTML, PHP u.dgl. beschäftigen wollen, läuft das Projekt letztendlich darauf hinaus, ein "Desktop CMS" zu entwickeln (Beispiel: Zeta Producer). Der lokale Webserver soll für die Anwender völlig unsichtbar bleiben und - wenn möglich - auch nur innerhalb meiner Anwendung laufen. Auch der Browser ("Vorschau") soll als solcher nicht zu erkennen sein. Wenn eine Webseite fertig ist, werden die zugehörigen Dateien hochgeladen - und das war's. Die PHP-Einbindung des lokalen Webservers brauche ich, um den Code zur Organisation der Inhalte nicht zweimal schreiben zu müssen - lokal in Object Pascal und remote als PHP.

[mjustin]

Zitat von GerhardS:

Da viele Anwender zwar eine eigene Website haben, sich aber nicht mit HTML, PHP u.dgl. beschäftigen wollen, läuft das Projekt letztendlich darauf hinaus, ein "Desktop CMS" zu entwickeln (Beispiel: Zeta Producer). Der lokale Webserver soll für die Anwender völlig unsichtbar bleiben und - wenn möglich - auch nur innerhalb meiner Anwendung laufen. Auch der Browser ("Vorschau") soll als solcher nicht zu erkennen sein. Wenn eine Webseite fertig ist, werden die zugehörigen Dateien hochgeladen - und das war's. Die PHP-Einbindung des lokalen Webservers brauche ich, um den Code zur Organisation der Inhalte nicht zweimal schreiben zu müssen - lokal in Object Pascal und remote als PHP.

Klingt interessant - bei Interesse kann ich versuchen, PHP Interpreter Aufrufe in mein (kommerzielles) Projekt Habari Web Components zu integrieren, zumindest als Prototyp.

[GerhardS]

Serhij Perevoznik hat 2006 für Indy 8 und 9 den IdRunner entwickelt, mit dem man auf dem Indy Webserver PHP als CGI ausführen kann. Der Autor hat nahezu alle Links dazu gekappt, nur auf Torry ist es noch zu finden:
www.torry.net/vcl/internet/cgiisapi/idrunner.zip
Jetzt muss nur noch der Code an Indy 10 angepasst werden ...

[nuclearping]

Zitat von GerhardS:

Da viele Anwender zwar eine eigene Website haben, sich aber nicht mit HTML, PHP u.dgl. beschäftigen wollen, läuft das Projekt letztendlich darauf hinaus, ein "Desktop CMS" zu entwickeln (Beispiel: Zeta Producer). Der lokale Webserver soll für die Anwender völlig unsichtbar bleiben und - wenn möglich - auch nur innerhalb meiner Anwendung laufen. Auch der Browser ("Vorschau") soll als solcher nicht zu erkennen sein. Wenn eine Webseite fertig ist, werden die zugehörigen Dateien hochgeladen - und das war's. Die PHP-Einbindung des lokalen Webservers brauche ich, um den Code zur Organisation der Inhalte nicht zweimal schreiben zu müssen - lokal in Object Pascal und remote als PHP.

Wenn du mit einem Browser arbeitest, auch eine IE / Mozilla Kapselung innerhalb deiner Anwendung, wirst du trotzdem nicht drum herumkommen, auf localhost einen HTTP-Server laufen zu lassen, weil du ja selbst innerhalb deines Anwendungsbrowsers navigieren musst.

Dann entwickel lieber ein Desktop-CMS mit WAMP, statt das Rad neu erfinden zu wollen, Jahre an Arbeit reinzustecken, um dann am Ende festzustellen, dass du vlt doch besser bestehende Lösungen genutzt hättest (Stichwort Wartung, Erweiterung, Versions- / Paradigmenwechsel, etc).