Mit Apache httpd 2.2 war es möglich, einen Reverse-Proxy einzurichten und mod_deflate zum Komprimieren von proxied-Inhalten zu verwenden, wobei Accept-Encoding: gzip -Header berücksichtigt wurden.
Diese Konfiguration war ausreichend, um es zum Laufen zu bringen:
%Vor%Nach dem Upgrade auf 2.4 (2.4.29 unter Windows) wird die gleiche Konfiguration akzeptiert, und statische Inhalte, die von DocumentRoot bereitgestellt werden, werden komprimiert. Aber derselbe Inhalt wird unkomprimiert zurückgegeben, wenn er über ProxyPass abgerufen wird.
Ich weiß, dass ich Tomcat für die Komprimierung konfigurieren kann, aber es gibt auch diesen anderen Server, der Accept-Encoding-Header ignoriert.
Wie kann ich einen Reverse-Proxy einrichten und Inhalt komprimiert haben?
Bearbeiten:
Hier sind die zurückgegebenen Header, die zeigen, dass der Proxy-Inhalt nicht vom Server 2.4 komprimiert wird:
%Vor%All dies wurde in einer einfachen 2.4.29-Installation getestet, die von ApacheHaus heruntergeladen wurde . Die obige Konfiguration wurde zu httpd.conf hinzugefügt, nichts anderes wurde geändert. Gleiches gilt für die 2.2.14-Installation (heruntergeladen 2009 von Apache ), die jedoch zusätzlich auf Port 81 geändert wurde .
Ich habe es geschafft, curl + apache/tomcat behavior zu reproduzieren, das du beschrieben hast
So habe ich es reproduziert (OS X El Capitan):
Tomcat :
%Vor%Apache
%Vor%Apache-Konfiguration (in ihrer Gesamtheit):
%Vor%Wie Sie sehen, stimmt die Ausgabe sehr gut mit Ihrem Beispiel überein
Wenn ich eine reguläre GET Anfrage anstelle von HEAD (via Browser oder curl ohne -I ) verwende, wird die Antwort von tomcat GZIPPED
Keine Ahnung, warum es passiert, sieht aus wie Apaches + mod_proxy / defate Fehlverhalten bei HEAD Anfragen. Wenn Sie sagen, dass es in Apache 2.2 in Ordnung war, würde ich denken, dass es irgendwie mit dieser Anpassung zusammenhängen könnte
%Vor%Also würde ich in Ihrem Fall prüfen, ob das Problem für GET -Anforderungen bestehen bleibt. Wenn ja, geben Sie noch mehr Details zu Ihrer Einrichtung an, damit Ihre Umgebung zu 100% repliziert werden kann - eine gültige Dockerfile für Apache und Tomcat zur Isolierung einer möglichen Umgebungsdiskrepanz wäre in Ordnung.
Sie senden eine HTTP HEAD-Anfrage mit dem -I -Flag in curl. Wie die Antwort von ffeast nahelegt, könnte dies die Ursache des Problems sein.
Wenn das tatsächlich der Fall ist, dann ist es entweder ein Fehler oder eine bewusste Missachtung des HTTP RFC: Ссылка
9.4 HEAD
Die HEAD-Methode ist identisch mit GET, außer dass der Server nicht darf Rückgabe eines Nachrichtentextes in der Antwort Die Metainformation enthielt
in den HTTP-Headern als Antwort auf eine HEAD-Anfrage SOLLTE identisch sein zu den Informationen gesendet als Antwort auf eine GET-Anfrage.
Wenn dies der Fall ist, sollten Sie dies über diesen Prozess als möglichen Fehler melden: Ссылка
Tags und Links apache mod-deflate mod-proxy