[Apache] Gzip icm. AJP proxy

[RomeoJ]

Op het moment heb ik problemen met het inschakelen van gzip compressie op een Apache HTTP-server welke voor een Apache Tomcat-server staat.

Tussen de HTTP en Tomcat-server wordt gebruik gemaakt van het AJP 1.3 protocol. Daarnaast wordt op het moment elk request vanaf de root (/) naar de Tomcat-server geproxied (door middel van mod_proxy_ajp).

Als ik in de gerelateerde virtualhost mod_deflate gebruik, dan krijg ik met geen mogelijkheid gzip compressie ingeschakeld tussen de HTTP-server en de cliënt.

Ik heb meerdere oplossingen geprobeerd, zowel de meest rigoreuze configuratie:

code:

SetOutputFilter DEFLATE

Alsmede specifieke filters op content type:

code:

AddOutputFilterByType DEFLATE text/html

Ik krijg maar niet de gewenste response header Content-Encoding: gzip te zien, op het moment heb ik al zoveel configuraties geprobeerd dat ik mezelf echt afvraag of het überhaupt wel mogelijk is met een (AJP) proxy, aangezien de mod_deflate prima werkt op alle configuraties die ik voorheen gedaan heb op Apache icm. PHP.

Iemand een oplossing voor mijn probleem?
Uiteraard heb ik al veel gegoogled maar er is niet heel veel geschreven over mod_deflate in combinatie met mod_proxy, zowel een HTTP als een AJP proxy hebben niet het gewenste effect gehad.

[nassau]

Je geeft niet al teveel details over de apache config (anders dan die 2 statements). Dus reageren hierop is wat moeilijk. Apache 2.x?

Wat ik wel zeker weet dat er geen enkele beperking is om mod_deflate toe te passen i.c.m. mod_proxy_ajp. Zo draaien wij veel sites voor klanten.

Heb je andere browsers geprobeerd?
Heb je überhaupt getest met een echte browser? Sommige command line tools vragen expliciet om niet ge-zipte responses.
Iets in je error.log?
Gecontroleerd of andere mime types wel werken zoals text/css?

[RomeoJ]

Excuses inderdaad niet teveel details als ik het zo teruglees:

• Apache HTTPd is versie 2.x
• Apache Tomcat versie 6.x

Voor het controleren van de headers gebruik ik de standaard webdeveloper toolbar van Google Chrome.
Deze verstuurt gewoon de header Accept-Encoding: gzip,deflate,sdch mee, dus dat zou goed moeten zijn. Zeker aangezien al mijn andere websites gewoon met deze browser prima werken.

Andere mime-types heb ik ook geprobeerd, geen één van deze types hebben gzip compressie aanstaan, tevens geen entries in de error.log.

Wel merk ik dat ik continue de header Vary: User-Agent terugkrijg van de Apache webserver, terwijl de andere websites waar gzip aanstaat bijvoorbeeld Vary: Host of Vary: Accept-Encoding teruggeven.
Heeft dat er iets mee te maken misschien?

[nassau]

RomeoJ schreef op donderdag 11 oktober 2012 @ 21:52:
Wel merk ik dat ik continue de header Vary: User-Agent terugkrijg van de Apache webserver, terwijl de andere websites waar gzip aanstaat bijvoorbeeld Vary: Host of Vary: Accept-Encoding teruggeven.
Heeft dat er iets mee te maken misschien?

Vary: User-Agent zie ik eigenlijk ook nooit. Is er iets anders in de vhost actief wat wellicht verstorend kan werken? Heb je ook mod_cache actief bijvoorbeeld, die is wel User-Agent gevoelig.

Zou toch eens een andere browser proberen. Firefox heeft uiteraard Firebug waarmee je dat mooi kan zien.

Als je een publieke URL hebt kunnen we meekijken maar hoeft niet.

[RomeoJ]

Ik ga eens goed kijken wat er geconfigureerd is. Het is namelijk niet door mezelf geconfigureerd, ik wil echter alleen gzip compressie enablen op de virtualhost.

In Firefox heb ik het getest en daar werkt het ook niet in helaas, ook is er geen publieke URL van beschikbaar, omdat dit een OTA omgeving is.

Bedankt voor het meedenken!

[ Voor 4% gewijzigd door RomeoJ op 12-10-2012 08:18 ]

[RomeoJ]

Door middel van het enforcen van het gebruik van gzip ben ik weer iets verder gekomen met dit probleem, aangezien gzip dan wel aanstaat (dat is te zien in de headers).

Omdat ik de werking van gzip compressie nu kan zien, weet ik dat het wel mogelijk moet zijn maar dat er wellicht iets in de loadbalancer (BigIP) of zoals je correct opmerkt, iets in de configuratie, verstorend werkt.

Aangezien dit natuurlijk weer een uniek probleem is, zal ik de komende periode tijd besteden aan het onderzoek hiernaar. Wanneer ik zinnige resultaten heb, dan zal ik dat uiteraard in dit topic vermelden.

[_-= Erikje =-_]

aaaah loadbalancer, die had ik nog niet gezien in je plaatje...

http://www.f5.com/pdf/whi...ligent-compression-wp.pdf

Maw die loadbalancer kan zelf eventueel compressie afhandelen mits geconfigureerd....

[RomeoJ]

_-= Erikje =-_ schreef op donderdag 25 oktober 2012 @ 08:14:
aaaah loadbalancer, die had ik nog niet gezien in je plaatje...

http://www.f5.com/pdf/whi...ligent-compression-wp.pdf

Maw die loadbalancer kan zelf eventueel compressie afhandelen mits geconfigureerd....

Kijk, dat zijn nog eens interessante links!

Het is echter nog niet duidelijk waarom ik met de enforcement mode (dmv: force-gzip) wel pagina's terugkrijg die gzip compressed zijn.

* RomeoJ gaat maar eens toegang vragen tot de LB console..

Bedankt voor de nuttige post Erik.

[ Voor 3% gewijzigd door RomeoJ op 26-10-2012 19:21 ]