On Wed, 2009-03-18 at 12:53 +0000, Tom Evans wrote:
> Hi all
>
> We use apache as a reverse proxy for managing our backend servers, and
> serving static content, and we also use it for providing a more local
> server in remote locations.
>
> (excuse the made up domain names)
> Eg, site www.foo.com is handled by reverse proxy proxy01.local, in which
> we have foo-backend1.local and foo-backend2.local configured as the
> backend servers. We then have secondary proxies, eg in Japan we have
> proxy02.japan, which proxies back to proxy01.local. Users access the
> Japan proxy by using a special domain name, eg jp.foo.com.
>
> The aim of this is that we can ensure that the route from proxy02.japan
> to proxy01.local is high bandwidth and as low latency as possible, where
> as a user in Japan could have a very poor route directly to our data
> centre housing proxy01.local, but would typically have an excellent
> connection to our data centre housing proxy02.japan.
>
> This all works correctly, and has provided a decent boost to our
> Japanese users. What we would like to do is enhance this boost by
> compressing all appropriate content between proxy01.local and
> proxy02.japan, decompress it at proxy02.japan, and then potentially
> recompress it again, depending if the user has requested compression.
> Obviously, if we could be smart here, and not decompress/recompress when
> the user requests compression, that would be better, but we can handle
> the compression load if needs be.
>
> The backend servers either run apache 1.3 with custom content generation
> modules written in C++, or are apache 2.2.11/prefork MPM running FastCGI
> applications. The proxy servers are all apache 2.2.11/event MPM.
>
> Is there a way to do this? I have had a look through the mod_proxy and
> mod_proxy_http documnentation, but cannot see a way to force this
> behaviour.
>
> Regards
>
> Tom
Hi all, follow up to explain for the archives how I managed this:
<VirtualHost *:80>
ServerName jp.foo.com
DocumentRoot /var/empty
<Proxy />
ProxyPass http://www.foo.com/
ProxyPassReverse http://www.foo.com/
</Proxy>
ProxyPassReverseCookieDomain www.foo.com jp.foo.com
# copy Accept-Encoding header for later
RewriteEngine On
RewriteCond %{HTTP:Accept-Encoding} ^(.*)$
RewriteRule ^(.*)$ - [env=accept-encoding:%1]
# check to see if we should deliver compressed
# content to this browser.
# First check is harsher than maybe necessary, but
# makes the logic simpler.
# It only discriminates against Netscape 4.
BrowserMatch ^Mozilla/4 no-gzip
BrowserMatch \bMSIE !no-gzip
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
# Force the backend to compress content
RequestHeader set Accept-Encoding gzip,deflate
FilterDeclare reinflate CONTENT_SET
# reinflate if we decided not to gzip
FilterProvider reinflate inflate env=no-gzip *
# reinflate if the UA didnt request gzip encoding
FilterProvider reinflate inflate env=accept-encoding !$gzip
FilterChain reinflate
</VirtualHost>
I used a no-op rewrite rule to capture the current Accept-Encoding
header, and then overwrite it with a value which will make the upstream
server compress the content. I then use a custom FilterProvider to
reinflate the content if I decide that the users browser is too rubbish
(and I'm a bit pessimistic against users of Netscape 4...), or if the
content type determines that they probably shouldn't be delivered
compressed (like images), or finally if the user didn't actually request
compressed content.
Cheers
Tom
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|