Link rewriting bei Apache
Flo
- webserver
Hi,
ich hab folgendes Problem: im internen Netz hab ich einen Webserver, der über diverse Scripts htmlseiten zur verfügung stellt. Leider ist in jeder dieser Seiten ein Tag <BASE HREF=192. ...> alse die interne IP. Jetzt möchte ich aber von außen über die Firewall darauf zugreifen. Dazu existiert in der DMZ ein Apache der als reverse proxy fungiert und mit den inhalt des internen Webservers nach außen weitergibt. Er ändert mir auch braf alle im header enthaltenen URLs um nur leider nicht diesen blöden Base tag. Gibt es eine Möglichkeit, das der Apache den html-code bevor er ihn weitergibt scannt und alle internen ip's durch den fully qualified domain name des reverse proxy ersetzt?
merci,
Flo
hallo flo,
Gibt es eine Möglichkeit, das der Apache den html-code bevor er ihn weitergibt scannt und alle internen ip's durch den fully qualified domain name des reverse proxy ersetzt?
Nein. Der Apache ist ein "Server" und für den Transport zuständig, aber nicht für den Inhalt dessen, was er transportiert. Du verlangst doch von der Post auch nicht, daß sie bei jedem Paket nachscahut, ob eine Tafel SAchokolade drinliegt.
Was du allerdings machen könntest, wäre, mit einem PERL-Script diese "base href"-Angaben zu ersetzen
Christoph S.
Hi Christoph,
Was du allerdings machen könntest, wäre, mit einem
PERL-Script diese "base href"-Angaben zu ersetzen
... und zwar mit einem CGI-Skript, welches als Handler
in die Apache-Konfiguration eingebettet ist und URL
& Pfadname der eigentlich angeforderten Seite über das
Environment erfährt (PATH_INFO und PATH_TRANSLATED).
Exakt dies tut auch gzip_cnc:
http://www.schroepl.net/projekte/gzip_cnc/source.htm
http://www.schroepl.net/projekte/gzip_cnc/install.htm#handler
Ein solcher Handler kann Requests statischer (!) Seiten
on the fly beliebig umgestalten (in meinem Falle sie
beispielsweise bedingt komprimiert ausliefern) - solche
mit dynamischen Inhalten leider nicht.
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael
Moinmoin Michael,
Ein solcher Handler kann Requests statischer (!) Seiten
on the fly beliebig umgestalten (in meinem Falle sie
beispielsweise bedingt komprimiert ausliefern) - solche
mit dynamischen Inhalten leider nicht.
Das ist nur bedingt richtig. Man koennte durchaus eine CGI-Umgebung
nachbauen und die Ausgabe umleiten. Das macht ja beispielsweise auch
der CGI-Wrapper (http://sourceforge.net/projects/cgiwrap).
Allerding halte ich das fuer gzip_cnc[c] nicht sonderlich sinnvoll,
da solche IPC-Geschichten haeufig sehr teuer sind.
Gruesse,
CK
Hallo Christian,
Das ist nur bedingt richtig. Man koennte durchaus
eine CGI-Umgebung nachbauen und die Ausgabe umleiten.
Yep - so ähnlich steht es sogar in der gzip_cnc-Doku
drin ...
Allerding halte ich das fuer gzip_cnc[c] nicht
sonderlich sinnvoll, da solche IPC-Geschichten
haeufig sehr teuer sind.
Erstens das, und zweitens würde gzip_cnc dann zusätzlich
von irgendwelchen Kommunikations-Modulen abhängig sein.
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael
use Mosche;
Gibt es eine Möglichkeit, das der Apache den html-code bevor er ihn weitergibt scannt und alle internen ip's durch den fully qualified domain name des reverse proxy ersetzt?
Nein. Der Apache ist ein "Server" und für den Transport zuständig, aber nicht für den Inhalt dessen, was er transportiert. Du verlangst doch von der Post auch nicht, daß sie bei jedem Paket nachscahut, ob eine Tafel SAchokolade drinliegt.
Neben der Antwort von Michael bleibt es wohl noch, dieser Aussage zu widersprechen. "Der Apache" als Server muß in die Seite schauen können, sonst würde bspw. SSI (und ähnliche Module) nicht funktionieren. Er kann also durchaus seinen eigenen Handler schreiben, und alle Ausgaben des Servers durch diesen Handler laufen lassen (eben da gleiche, was Michael vorgeschlagen hat, nur eben auf Apache-Admin-Ebene und nicht im User-mode).
Das sollte sogar schneller sein als Michaels Methode.
Du hast nur insofern recht, dass der "Standard"-Apache nicht in den Inhalt guckt (was nichts an der Tatsache ändert, dass es über die Methode, Module einzusetzen, nicht geht).
Fachliche Verbesserungen am Text sind erwünscht :-).
use Tschoe qw(Matti);
hallo Matti,
Neben der Antwort von Michael bleibt es wohl noch, dieser Aussage zu widersprechen. "Der Apache" als Server muß in die Seite schauen können, sonst würde bspw. SSI (und ähnliche Module) nicht funktionieren. Er kann also durchaus seinen eigenen Handler schreiben, und alle Ausgaben des Servers durch diesen Handler laufen lassen (eben da gleiche, was Michael vorgeschlagen hat, nur eben auf Apache-Admin-Ebene und nicht im User-mode).
vielleicht verstehen wir die Frage von Flo unterschiedlich. Ich bestreite nicht, daß der Apache in Dokumente, die er ausgeben soll, hineinschauen muß. Das betrifft auch nicht nur SSI, sondern ebenso PHP und noch einiges andre. Und er muß auf einige Angaben im Dokument auch reagieren, Anfragen weiterleiten können bzw. an Module oder externe Programme verweisen, die unter Umständen neuen Code erzeugen. Aber ein unmittelbares Eingreifen und/oder Verändern eines Dokuments nimmt der Apache nicht vor.
Man könnte einen neuen eigenen Handler schreiben, der auf spezifische Tags reagiert, das ist richtig. Aber auch so ein Handler müßte serverseitig irgendein Zusatzprogramm in Gang setzen, das dann die verlangten Änderungen am Dokument vornimmt.
Das sollte sogar schneller sein als Michaels Methode.
So weit ich mir Michaels Vorschläge bisher angeschaut und vielleicht auch verstanden habe, befolgt er dasselbe Prinzip.
Du hast nur insofern recht, dass der "Standard"-Apache nicht in den Inhalt guckt
Vor einiger Zeit hat mich Michael mal zu belehren versucht, daß es einen "Standard" beim Apache eigentlich nicht gebe. Ich kann dieser Ansicht sehr viel Wahrheitsgehalt abgewinnen. Wenn du unter "Standard" das verstehst, was du unmittelbar nach einer Software-Installation auf deinem Rechner vorfindest, so kannst du ziemlich sicher sein, daß das fast überall dasselbe ist. Eine solche Installation kann vielleicht noch nicht mit SSI umgehen, aber in ein Dokument hineinschauen und reagieren kann der Apache auch in diesem Zustand - nur eben verändern kann er am Dokument nix.
so, jetzt bist du wieder dran. Widerspruch ist zulässig ;-)
Christoph S.
use Mosche;
Man könnte einen neuen eigenen Handler schreiben, der auf spezifische Tags reagiert, das ist richtig. Aber auch so ein Handler müßte serverseitig irgendein Zusatzprogramm in Gang setzen, das dann die verlangten Änderungen am Dokument vornimmt.
Im Endeffekt wäre meine Lösung sowas wie das SSI-Modul, dass die Dateien parst und und Strings ersetzt. Das gleicht Michaels Lösung: bis auf die Tatsache, das er einen Handler als User einsetzt und meine Lösung auf Apache-Konfiguartions ebene stattfindet - neustarten des Servers inklusive. Deswegen sollte es auch schneller sein (wie bei httpd.conf <-> .htaccess).
Ich drücke mich vielleicht etwas ungewählt aus, deswegen die Nachfrage zur Terminologie:
Handler ist das, was Michael einbindet (zB ein CGI-Script, was ja sein Grund war, gzip_cnc zu schreiben).
Modul ist das, was zB SSI ist (oder ist SSI auch ein Handler ?).
Wäre nett, wenn mich in dieser Hinsicht jemand aufklären könnte.
Wenn du unter "Standard" das verstehst, was du unmittelbar nach einer Software-Installation auf deinem Rechner vorfindest, so kannst du ziemlich sicher sein, daß das fast überall dasselbe ist. Eine solche Installation kann vielleicht noch nicht mit SSI umgehen, aber in ein Dokument hineinschauen und reagieren kann der Apache auch in diesem Zustand - nur eben verändern kann er am Dokument nix.
Ich habe mir mit Standard den Apache mit nur der Grunddistribution an Modulen vorgestellt.
use Tschoe qw(Matti);
Hi Matti,
Im Endeffekt wäre meine Lösung sowas wie das SSI-
Modul, dass die Dateien parst und und Strings
ersetzt. Das gleicht Michaels Lösung: bis auf die
Tatsache, das er einen Handler als User einsetzt
und meine Lösung auf Apache-Konfiguartions ebene
stattfindet - neustarten des Servers inklusive.
Deswegen sollte es auch schneller sein (wie bei
httpd.conf <-> .htaccess).
langsam ist meine Methode vor allem, weil mein Handler
immer wieder neu geladen werden muß.
Ein Handler, der bereits im Apache-Code drin steckt
und noch dazu aus kompiliertem C-Code besteht statt
aus interpretiertem Perl, ist natürlich erheblich
schneller.
Modul ist das, was zB SSI ist (oder ist SSI auch ein
Handler ?).
mod_includes enthält zumindest auch einen Handler:
AddHandler server-parsed .shtml
(aus httpd.conf)
Wäre nett, wenn mich in dieser Hinsicht jemand
aufklären könnte.
mod_includes ist zunächst einmal ein Modul.
Ein Apache-Modul besteht aus einer variablen Anzahl
unterschiedlichsten Code-Stücken, die über verschie-
dene Mechanismen ("hooks") vom Apache-Basis-Code
eingebunden werden.
Ein Typ von Code-Stück ist beispielsweise eine Funktion
zur Analyse und Auswertung einer Konfigurations-
Direktive. Jedes Modul lädt seine eigenen Direktiven-
Parser und baut seinen eigenen Konfigurations-Record
auf; wenn Du ein Modul nicht geladen hast, aber Direk-
tiven zu diesem Modul in der httpd.conf stehen, dann
gibt das Syntaxfehler und der Apache läßt sich gar
nicht neu starten.
Andere Code-Stücke wiederum sind die Handler. Sowohl
SSI als auch CGI enthalten u. a. auch einen solchen
Handler, der allerdings über eine interne Apache-API
versorgt wird - und deshalb sehr viel mehr kann und
darf als ein Handler, der lediglich via "Action" oder
"SetHandler" eingebunden wurde.
Und mod_include enthält nun beides - sowohl einen
Handler als auch eine Handvoll Direktiven-Parser.
Der Handler kann auf die von den Direktiven-Parsern
aufgebauten Konfigurations-Datensätze zugreifen und
somit erkennen, was er tun darf, soll und muß.
Es gibt wohl noch weitere Arten von Code-Stücken -
ich habe das Apache-Modul-API bisher erst teilweise
verstanden.
Falls Dich Details interessieren, dann lies mal den
Quelltext von "mod_example" - das ist ein ganz bewußt
zum Lernen mitgeliefertes Spiel-Modul, das nichts
anderes tut, als Meldungen auszugeben, wann welche
seiner Funktionen aufgerufen wurde, das Beispiel-
Direktiven implementiert usw.
Es gibt im Apache-Developer-Bereich auch eine Doku
zu diesem Modul-API ...
Ich habe mir mit Standard den Apache mit nur der
Grunddistribution an Modulen vorgestellt.
Welche Distribution? Irgend eine aufgepumpte von
irgend einem Linux-Distrubutor (igitt), oder die-
jenige, die beim Original-Download des Quelltextes
mit "./configure" ohne weitere Parameter entstehen
würde? Letztere würde ich als "den Standard" ansehen
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael