Flo: Link rewriting bei Apache

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

  1. 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.

    1. 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

      1. 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

        1. 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

    2. 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);

      1. 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.

        1. 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);

          1. 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

            • wenn überhaupt.

            Viele Grüße
            <img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael