Dieses Modul implementiert ein proxy/gateway für Apache. Es implementiert
Proxy-Fähigkeit für
FTP,
CONNECT (für SSL),
HTTP/0.9,
HTTP/1.0 und
HTTP/1.1.
Das Modul kann konfiguriert werden, um andere Proxymodule
für diese und andere Protokolle anzuschließen.
Dieses Modul war experimentell in Apache 1.1.x. Verbesserungen und Fehlerbeseitigungen wurden in Apache v1.2.x und in Apache v1.3.x gemacht, dann unterging das Modul einer Generalüberholung für Apache v2.0. Die Protokollunterstützung wurde zu HTTP/1.1 verbessert, und Filterunterstützung wurde ermöglicht.
Notieren Sie bitte, daß die cache-Funktion, die im mod_proxy bis zu Apache v1.3.x vorhanden ist, vom mod_proxy entfernt worden und im neuen Modul mod_cache enthalten ist.
Sollten Sie beim Verbindungsaufbau zu Internetservern SSL brauchen,
lesen Sie bitte die SSLProxy* Direktiven in mod_ssl.
Setzen Sie keinen Proxy mit
Apache kann als forward und reverse Proxy konfiguriert werden.
Ein Forward Proxy ist ein Transitsystem, das einem Client-Browser die Verbindung zu einem entfernten Netzwerk ermöglicht worauf dieser normalerweise keinen Zugriff hat. Ein solcher Proxy kann auch Daten im Cache ablegen, was die Netzbelastung zwischen dem Rechner des Proxy und dem entfernten Webserver reduziert.
Einen Forward Proxy, einen Weiterleiter, konfiguriert man mit der
Ein Reverse Proxy ist ein Webserver, der so konfiguriert ist, daß er Seiten eines anderen Webservers einblendet - und das zusätzlich zu eigenen von der Festplatte stammenden Dokumenten oder solchen, die dynamisch mit Skripten erzeugt wurden. Dem Client bleibt der Ursprung der eingeblendeten Seiten verborgen.
Ist der Reverse Proxy mit mod_cache konfiguriert, kann er auch als Cache für langsame Webserver eingesetzt werden. Damit lassen sich fortgeschrittene URL-Strategien und Verwaltungstechniken einsetzen in dem Sinn, daß Webseiten verschiedener Webserver oder Betriebssysteme innerhalb eines gemeinsamen Namensraums koexistieren. Zusätzlich bietet sich hier die Möglichkeit ein zentrales Loggen der Zugriffe zu implementieren.
Einen Reverse Proxy konfiguriert man mit den Direktiven
Zugriffskontrolle auf den Proxy erfolgt mit der
Wenn man einen Reverse Proxy konfiguriert, wird die Zugriffskontrolle übernommen
von den Anweisungen in der
Ein wahrscheinlicher Grund wird sein, daß der betreffende Dateityp nicht als application/octet-stream in der Datei mime.types konfiguriert ist. Eine solche Zeile könnte z.B. sein:
In der seltenen Situation wo ein solches Herunterladen mittels der FTP
ASCII Übermittlungsmethode nötig ist (Standardtransfer
ist binär), kann man die Voreinstellung von mod_proxy
umgehen, indem man den URI ergänzt mit dem Zusatz ;type=a,
um den ASCII-Transfer zu erzwingen (FTP Verzeichniseinträge werden immer
im ASCII-Modus ausgeführt).
Eine FTP URI wird normalerweise relativ zu dem Benutzerverzeichnis des Benutzers interpretiert, der sich auf dem Server einloggt. Um in höher gelgene Stockwerke zu gelangen, kann man beispielsweise nicht /../ angeben, da die Punkte vom Browser interpretiert und nicht zum FTP-Server gesandt werden. Um dieses Problem zu lösen, wurde der sogenannte "Squid %2f hack" in den Apache FTP-Proxy implementiert; diese Lösung wird auch in anderen Proxyservern, wie z.B dem Squid Proxy Cache benutzt. Indem man ein /%2f an den Pfad der Anforderung anhängt, kann man das Startverzeichnis für FTP auf / (root - an Stelle des Benutzerverzeichnisses) setzen. Das hängt natürlich auch von der Konfiguration des jeweiligen FTP-Servers ab.
Beispiel: Um auf die Datei /etc/motd zuzugreifen,
verwendet man die URL
Apache benutzt verschiedene Strategien, wenn es um das Einloggen mittels Benutzername und Passwort geht. Fehlen Benutzername und Passwort, sendet Apache an den FTP-Server ein anonymes Login, z.B.,
Das ist erfolgreich bei allen populären FTP-Servern, die für anonymen Zugriff konfiguriert sind.
Will man sich mit seinem Benutzernamen einloggen, so kann dieser in die
URL beispielsweise eingegeben werden als ftp://benutzername@rechner/datei.
Wenn der FTP-Server nach einem Passwort fragt, was normalerweise der Fall
ist, dann wird Apache einen Antwort-Header generieren [401 Authorization
required], der den Browser des Benutzers dazu bringt ein Dialogfenster zu
öffnen, in welches Passwort und Benutzername eingegeben werden können.
Sind diese Eingaben erfolgt, wird ein neuer Verbindungsaufbau versucht,
und im Erfolgsfall wird die Seite angezeigt. Der Vorteil des Dialogfensters
für Passwort und Benutzername liegt darin, daß diese kritischen
Angaben nicht in der URL des Browsers erscheinen und damit für jemand
mit Zugang zum selben Rechner in der Historie des Browsers sichtbar sind.
Wenn man z.B. die
Ein Apache Proxyserver im Intranet einer Firma wird Anfragen zum Internet
in der Regel durch eine Firewall senden müssen. Erfolgt jedoch auch
ein Zugriff auf Webseiten im Intranet, so sollte die Firewall umgangen werden.
Dazu dient die Direktive
Benutzer innerhalb eines Intranet tendieren dazu in der URL des Browsers
lokale Adressen abzukürzen, wie z.B. "http://intra/" an Stelle von
"http://intra.unsere.firma.de/". Bei einigen kommerziellen Proxyservern kann
man dieses Benutzerverhalten durch eine entsprechende Konfiguration abfangen
und auf die richtige Adresse weiterleiten. Wenn im Apache Webserver der
Proxydienst aktiviert ist, setzt man die
Sollte ein Fall vorliegen, wo ein Applikationsserver keine Verbindungen
aufrechterhalten kann, oder HTTP/1.1 ist nicht sauber implementiert,
stehen zwei Umgebungsvariablen zur Verfügung, die ein HTTP/1.0
mit "no keepalive" senden. Gesetzt wird das mit den
Direktiven innerhalb des
Im folgenden Beispiel wird nur Rechnern der Domain yournetwork.example.com
Zugriff auf den Proxyserver gewährt:
Das nächste Beispiel zeigt wie man alle Dateien im Verzeichnis foo
von example.com mit dem INCLUDES-Filter parst, wenn
sie über den Proxy angefordert werden:
Die
Wenn dieser Schalter gesetzt ist, wird die Zeile mit dem Host-Feld der eingehenden Anforderung zum übergeordneten Server unverändert durchgereicht.
Normalerweise wird man diese Direktive nicht benutzen.
Damit wird das Proxy-Modul des Apache aktiviert, um als Forward Proxy
tätig zu werden. Bleibt der Schalter aus, ist keinesfalls die Möglichkeit
zur Konfiguration eines Reverse Proxy mit der
Warnung: Schalten Sie
Mit dieser Direktive gibt man einen übergeordneten Cache an. Das Argument match ist entweder der Name eines vom vorgeschalteten Cache unterstützten URL-Schemas, oder eine partielle URL, bzw. ein '*' steht für alle Protokolle, mit denen Anforderungen an den anderen Cache weitergeleitet werden. Syntax:
remote-server = protocol://hostname[:port]
protocol ist das Protokoll, mittels dessen mit dem vorgeschalteten Cache kommuniziert werden soll; nur "http" wird vom Proxy-Modul unterstützt.
Beispiel:
Hierbei wird der Proxy alle FTP-Anforderungen an den ftpproxy.mydomain als HTTP-Proxy-Request weiterleiten. Ist der Host nicht erreichbar, wickelt der Apache die Anfrage eigenständig ab.
Mit dieser Direktive kann man auch die Konfiguration eines Reverse Proxy aufbauen. Beispielsweise kann ein hinter einer Firewall agierender Applikationsserver in den Namensraum eines virtuellen Hosts eingebettet werden - selbst dann, wenn ein anderer Weiterleitungs-Proxy diesen verbirgt.
Beim Einsatz dieser Direktive können Seiten anderer Server in den lokalen Namensraum eingeblendet werden; verwenden Sie zu diesem Zweck auf keinen Fall die Direktive ProxyRequests on. Der lokale Server agiert nicht als Proxy im herkömmlichen Sinne sondern mehr als ein Spiegel des Servers, dessen Seiten eingeblendet werden. Mit pfad geben Sie den Namen des lokalen virtuellen Pfades an und mit url die URL des entfernten Servers. Diese darf keine Zusätze mit CGI-Abfragen enthalten.
Hat beispielsweise der lokale Server die Adresse http://wibble.org/;
dann
wird eine lokale Anforderung für <http://wibble.org/mirror/foo/bar>
intern in eine Proxy-Anforderung für <http://foo.com/bar>
umgewandelt.
Die (Verneinungs-) ! Direktive ist nützlich für Situationen, in denen man ein Einblenden für ein bestimmtes Unterverzeichnis ausschliessen will. Das folgende Beispiel
lenkt alle Anfragen wie gehabt um mit Ausnahme derjenigen, die nach dem foo das Unterverzeichnis i angeben.
Wird ProxyPass innerhalb von
Haben Sie das Proxy-Modul in den Apache eingebunden, lassen sich über
das Proxy-Flag von [P]sehr vielseitige Konfigurationen erstellen, da die Nutzung
des Proxy transparent für den Client geschieht.
Diese Direktive schreibt den eigenen Hostnamen in die URL in den Feldern
Location, Content-Location und URI
des Headers bei HTTP-Redirekts des übergeordneten Webservers.
Erst durch diese zu ProxyPass als Ergänzung dienende Funktionalität
läßt sich der Apache als Reverse-Proxy einsetzen. Der Begriff
bedeutet, daß die Seiten nicht vom eigenen Server stammen, sondern
von einem oder mehrern anderen Servern, die quasi hinter dem Reverse-Proxy
versteckt werden. Ein typisches Einsatzgebiet sind Datenserver hinter einer
Firewall.
Mit pfad geben Sie den Namen des lokalen virtuellen Pfades an
und mit url die URL des entfernten Servers - wie bei der
Beispiel:
Angenommen der lokale Server hat die Adresse http://my.antispam.de/;
dann wird im folgenden Beispiel
nicht nur die lokale Anforderung für <http://my.antispam.de/misc/spamAbuse>
intern konvertiert in eine Proxy-Anforderung <http://ordb.org/faq>
(die Funktionalität von ProxyPass), es werden durch ProxyPassReverse
auch Redirekt-Headerzeilen (301, 302, 304) des Servers ordb.org behandelt. Wenn
die über den Proxy unter http://ordb.org/faq aufgerufenen
Seite einen Link auf http://ordb.org/dictionary enthält,
wird Apache diesen Link umwandeln in http://my.antispam.de/dictionary
in der HTTP-Redirekt-Antwort an den Client. Das heißt, daß dieses
Verzeichnis bei my.antispam.de existieren muß, damit es
keine "Not Found"-Meldung (404) gibt.
Bei Benutztung von RewriteRule-Flag [P]des Moduls
Wird ProxyPassReverse innerhalb von
Die
Mit der
'rocky.wotsamattau.edu' wird demnach auch gesperrt, wenn stattdessen in der URL die IP-Adresse eingegeben wird.
Wichtig: auch 'wotsamattau' genügt als Treffer für 'wotsamattau.edu'.
Und keinen Sinn macht die folgende Angabe, die den Zugriff auf alles sperrt:
Mit der
Die
Diese Anweisung ist nur dann nützlich, wenn die
Als host-Argumente für die NoProxy-Direktive können Sie folgende Werte verwenden:
.com .apache.org.
192.168 oder 192.168.0.0192.168.112.0/2192.168.123.7prep.ai.mit.edu www.apache.org.WWW.MyDomain.com
und www.mydomain.com. (abschliessenden Punkt beachten!) als
gleich betrachtet.Mit dieser Direktive kann die Voreinstellung von 300 Sekunden reduziert oder erhöht werden. Das ist insbesondre dann nützlich, wenn ein Applikationsserver gelegentlich "hängt" und man möchte den Client lieber rechtzeitig mit einer Timeout-Meldung versorgen als ihn in dieser Verbindung auf unbestimmte Zeit hängen zu lassen.
Diese Direktive ist nur nützlich für Apache Proxyserver im Intranet.
Die
Ein bereits in einer Anforderung vorhandener Via: HTTP-Header
wird vom Proxy weitergeleitet, jedoch wird ein eigener Eintrag erst generiert,
wenn der Schalter nicht aus ist. Damit kann man den Weg einer Anfrage entlang
einer Kette von Proxyservern verfolgen (siehe auch RFC2068, HTTP/1.1).
Via: Header hinzugefügt, die den eigenen
Hostnamen enthält.Via:
Header zusätzlich zum Hostnamen die Serverversion im Via:
-Kommentarfeld angezeigt.Via: Header in der Anfrage entfernt und kein neuer
generiert.Diese Direktive ist beispielsweise nützlich, wenn man für den Endbenutzer ein vertrautes "look and feel" für Seiten mit Fehlermeldungen herstellen möchte, insbesondre wenn ein Reverse Proxy konfiguriert ist. Mittels SSI kann man zusätzlich den Fehlercode erfassen und entsprechend eine dafür geeignete Seite an den Browser des Benutzers zurückliefern.