Dateien verarbeiten wie Apache

[Timmer]

Hey,

ich habe mal vor Ewigkeiten an einem Skript gearbeitet, dass alle Requests an eine Datei schickt und dort entscheidet, was getan wird (z.B. Parameter an Programm übergeben und ausführen, Client weiterleiten oder reale Datei auf der Platte ausgeben). Damals wie heute habe ich das Problem, dass ich Dateien, welche real auf der Platte liegen, gerne so verarbeiten/ausgeben möchte, wie es der Apache ohne meinen Umweg tun würde, heißt: Ausführbare Dateien wie PHP oder CGI-Skripte sollen ausgeführt werden, Bilder direkt ausgegeben werden, usw.

Natürlich könnte ich jetzt auf verschiedenste Kriterien prüfen, was mit der Datei anzustellen ist, ich würde das aber lieber den Apachen tun lassen. Kann ich die Datei per Befehl an den Apachen geben und das Ergebnis ausgeben lassen? Ist leider schon etwas länger her, dass ich mit PHP gearbeitet habe und finde dazu auch nichts wirklich brauchbares :/

Danke schonmal!

Timmer

 

[Sentence]

Moin Timmer,
ich verstehe nicht genau was du vor hast, aber über den Apache irgendwas ausgeben zu lassen funktioniert nicht. Der Apache ruft ja auch nur für bestimmte mime-types die entsprechenden interpreter auf (php, python usw.) und gibt das ergebnis an den aufrufenden Client (Browser) aus, der Browser entscheidet wie er das rendert (html, xml, bild usw.)

Php und Python lassen sich aber durchaus auch ohne den Apachen nutzen. Von php gibts auch ne CLI Version, welche keine HTML Ausgaben macht, sondern reinen Text.
Aber ich glaub nicht, dass es das ist, was du suchst...

An was für einem Script hast du gearbeitet? perl? php? python?
Requests von wo? Per Browser an einen Webserver? Dann musst du doch in dem Script nur eine Weiche einbauen, die prüft ob die Datei lokal liegt und evtl. per header darauf weiterleiten.

Vielleicht verstehe ich auch nicht was du willst ;-)

MfG

 

[Timmer]

Danke für die schnelle Antwort =)

Also es handelt sich um ein PHP Skript, das auf dem Webserver liegt. Per ModRewrite leite ich nun alle Requests an das Skript (mit Ausnahme der bereits behandelten Requests, um eine Endlosschleife zu vermeiden). Wenn in diesem Skript nichts weiter zu tun ist, als die Berechtigungen des Users zu prüfen und anschließend eine Datei auf der Platte auszugeben, will ich, dass diese Datei interpretiert wird, wie bei einem Request ohne ModRewrite.

Rufe ich also eine .php-Datei auf, soll diese interpretiert werden. Allerdings kann man dem PHP Interpreter auch beibringen, .html-Dateien zu interpretieren, was ich in diesem Fall natürlich auch gerne machen würde. Was ich also jetzt brauche, wäre ein Befehl oder eine Funktion, die mir die entsprechenden Interpreter-Configs des Apache's liefert, damit ich anschließend im Skript alle Dateien auch so behandelt kann, wie sie es verdienen. Ungefähr verstanden, was ich meine?

Die Schwierigkeit darin besteht, dass ich meine Umgebung nicht kenne. Das Skript ist Teil eines Stück Software, das willkürlich auf jedem Webserver mit PHP laufen kann.

 

[Sentence]

Also es handelt sich um ein PHP Skript, das auf dem Webserver liegt. Per ModRewrite leite ich nun alle Requests an das Skript (mit Ausnahme der bereits behandelten Requests, um eine Endlosschleife zu vermeiden). Wenn in diesem Skript nichts weiter zu tun ist, als die Berechtigungen des Users zu prüfen und anschließend eine Datei auf der Platte auszugeben, will ich, dass diese Datei interpretiert wird, wie bei einem Request ohne ModRewrite.

Theoretisch könntest du einen Subrequest mit virtual() ausführen, da besteht dann aber wohl wieder das Problem der Endlosschleife, weil die htaccess wieder greifen würde. Außerdem benötigt das PHP als Modul, nicht als CGI.
Alles was nicht geparst werden muss, kannst du aber einfach mit readfile() ausgeben. Vorher musst du aber den passenden header() senden.

Rufe ich also eine .php-Datei auf, soll diese interpretiert werden. Allerdings kann man dem PHP Interpreter auch beibringen, .html-Dateien zu interpretieren, was ich in diesem Fall natürlich auch gerne machen würde. Was ich also jetzt brauche, wäre ein Befehl oder eine Funktion, die mir die entsprechenden Interpreter-Configs des Apache's liefert, damit ich anschließend im Skript alle Dateien auch so behandelt kann, wie sie es verdienen. Ungefähr verstanden, was ich meine?

.php Dateien kannst du auch einfach includen...

Welcher Sinn steckt dahinter? Passwortschutz?

MfG

 

[Timmer]

Der Sinn dahinter ist, dass jeder Link alles mögliche bedeuten kann. Entweder es ist ein in einer Datenbank definierter Link oder ein direkter Programmaufruf. Ich möchte aber nicht ausschließen, dass auf dem Webserver auch andere Dinge rumliegen. Includen kann ich die Files nicht, da diese Dateien zu 99 % nicht meine Files sind (diese werden nicht direkt per Browser aufgerufen).

virtual() könnte mir da schon gut weiterhelfen, ich muss nur einen weiteren GET-Parameter (wie der Parameter für behandelte Requests in der ModRewrite) einführen bzw. den bereits existenten Nutzen, da dieser gleich bei der RewriteCond aussteigt. Der GET-Parameter kommt systemweit nicht mehr vor und wird bei der Installation bzw. bei der Einrichtung zufällig generiert.

Den Inhalt einer Datei gebe ich einfach mit echo file_get_contents($_request_file); aus ;)

 

[Timmer]

Tatsächlich funktioniert es nicht wie gewünscht

Ich habe jetzt noch folgende RewriteCond in die .htaccess eingebaut, um Subrequests über virtual() abzufangen:

RewriteCond %{IS_SUBREQ} false

Jetzt weiß ich auch endlich, was IS_SUBREQ genau macht (habs vorher nie zum Greifen gebracht).

In der index.php hole ich mir mit einer Subroutine den MIME-Type und puste diesen in den Content-Type Header und anschließend führe ich das virtual() aus. HTML-Dateien werden richtig interpretiert, PHP-Dateien werden zum Download angeboten (ich weiß, für PHP-Dateien lieber includen, jedoch müsste ich dafür die Einstellungen des PHP Interpreters auslesen). Help?

 

[Sentence]

PHP-Dateien werden zum Download angeboten (ich weiß, für PHP-Dateien lieber includen, jedoch müsste ich dafür die Einstellungen des PHP Interpreters auslesen). Help?

Komisch, da kann ich dir aber nicht helfen, mit virtual() hab ich bisher nicht gearbeitet. Aber warum musst du bei einem include die Einstellungen des PHP interpreters auslesen? Deine index.php läuft doch sowieso mit den Einstellungen, oder läuft dein Script unter einem anderen Benutzer als der rest?

MfG

 

[Timmer]

Es geht darum, dass ich nicht weiß, wie der Inhaber des Webservers diesen eingestellt hat. Vielleicht will er .html oder gar .exe Dateien durch den PHP Interpreter jagen oder was weiß ich. Natürlich will ich dann das gleiche Verhalten für solche Dateien übernehmen.

Ich müsste also irgendeine Config auslesen, der ich entnehmen kann, welche Dateien durch welchem Interpreter gejagt werden und die Datei anschließend selbst dem Interpreter übergeben. Alles, was nicht einem Interpreter zugeordnet werden kann, wird einfach mit file_get_contents() ausgegeben. Any idea?

Edit: Demnach müsste ich die httpd.conf auslesen, nicht?

 

[threadi]

Wenn es dir um die Apache-Konfiguration geht, kann man nicht sagen, welche Konfigurationsdatei Du nun auslesen solltest. Das ist auf jedem Server bzw. jeder Distribution anders. Bei der einen heißt die zentrale Konfigurationsdatei apache2.conf, bei anderen httpd.conf. Viele aktuelle Distributionen teilen die Konfiguration zudem über viele Dateien auf. Das auszulesen nur um zu ermitteln, welcher Interpreter installiert ist, wäre viel zu aufwendig wenn Du ein Script schreiben willst, was auf "beliebigen" Servern installiert werden kann.

Falls Du eine Liste der aktiven Erweiterungen haben willst, gibt es ein Apache-Konsolenkommando, welches man dafür nutzen könnte:
Zeige geladenen apache Module an | codeterrorizer.com
Dadurch weißt Du aber lange nicht, welche Dateiendung von welchem Interpreter ausgeführt wird.

 

[Timmer]

Mir geht es ja eher darum, herrauszufinden, welche Dateien mit welchem Interpreter behandelt werden sollen. Da der Aufwand aber anscheinend zu groß ist, und ein Subrequest via virtual() nicht funktioniert (jedenfalls krieg ichs nicht hin), muss ich wohl grundsätzlich einen anderen Weg finden...