Gzip Supporting

[yaoxing zhang]

hi,
I downloaded the latest code from
http://lighttpd-improved.googlecode.com/svn/trunk
and use mod_cache as an accelerator, just like squid. Everything else is
fine, except the gzip compressing. I don't know if mod_cache is using
mod_compress, or mod_mem_compress? And is the mod_mem_compress included
in the source above?
--
Regards,
YX

[shellcode]

For content cached in memory by "use-memory", the only way to gzip them is "memory-compress" option.
For content cached in local disk, mod_compress/mod_mem_compress can be used to gzip them.

mod_mem_compress module is included in the lighttpd 1.4.23 tarball.

[yaoxing zhang]

Seems it's because of both mod_mem_cache and IIS7 gzip being turned on. I turned off both, and now it's working.
But why does mod_mem_cache break gzip function? Smells like a bug.
And just be curious, why can't it be cached and compressed when IIS7 gzip is turned on? Any solutions to this? Because we might need the back-end server to provide service to the public, too.

Regards,
YX

On 2009年11月19日 18:01, shellcode wrote:

turn off gzip compress on IIS server

On Thu, Nov 19, 2009 at 6:00 PM, yaoxing zhang <yaoxin...@gmail.com> wrote:

Yes it's included, and if I directly request the back-end server, IIS7 does send back the compressed response with Content-Encoding: gzip.

Regards,
YX

On 2009年11月19日 17:57, shellcode wrote:

"X-Cache: TO MEMCACHE" is set by mod_mem_cache, not mod_mem_compress.

'X-Cache: Hit' response header will appear when request is hit and served by mod_cache.
In order to gzip cached content, 'Accept-Encoding: gzip, deflate' must include in request header

[shellcode]

it's not bug. lighttpd calls modules by the order of server.modules.
for example: server.modules = (A,B,C), request is process in module A first, If A don't want to handle it, then pass request to B. B passed to module C when B don't want to handle it.

so if mod_mem_cache handles request, then modcache will not handle it if modcache is behind mod_mem_cache

[yaoxing zhang]

Does it mean I should load mod_mem_cache after mod_cache, mod_proxy and
mod_compress?
And how about the IIS gzip issue? Does it mean mod_cache can't handle
gzip response from IIS? Or is there any work round? Because my purpose
of using mod_cache is to reduce the stress of main server, thus I still
need the main server to serve people. If I turn off gzip, it would cause
like 3 times' larger traffic.

Regards,
YX

> --
>
> You received this message because you are subscribed to the Google
> Groups "mod_cache" group.
> To post to this group, send email to mod_...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mod_cache?hl=.

[yaoxing zhang]

I find something more interesting. I finally figure out that the page
being not compressed has nothing to do with IIS sends compressed
response or not. The factor is only whether mod_cache HITs or not. In
other words, if mod_cache HITs, the response will be compressed. If not,
mod_cache will get response from IIS and return return to me a fresh
version. This version is always not compressed. This also happens when
the page is not included in the refresh patterns. For example, my
refresh pattern is:
cache.refresh-pattern = (
"\.(?i)aspx" => "30 use-memory memory-compress",
"\.(?i)(html|css|js)" => "30"
)
So the first time when I access the page, all the .aspx/html/css/js type
page will be returned un-compressed. But the 2nd time, I'll get the header
Cache: HIT
and this time, the header also includes
Content-Encoding: gzip
However, the types which are not included in the refresh pattern, like
WebResources.axd, I'll always get the fresh version, and they are never
compressed.
And i can make sure this is not a mod_compress issue because it works
for all the other virtual hosts in the same server. Any ideas?
Regards,
YX

[shellcode]

modcache default to not cache. for urls not handled by refresh.patterns, lighttpd works like proxy only, so you get fresh content every time.

proper module load sequence is "mod_compress(or mod_mem_compress) mod_mem_cache mod_cache mod_proxy", which make lighttpd try

to compress local files first, then try to cache local files in memory, then try to cache remote files in memory/disk or compress memory cached content.

[yaoxing zhang]

Now the problem seems like mod_proxy doesn't work with mod_compress directly. But once the URL is cached by mod_cache, mod_compress works. Probably not a problem of mod_cache. I'll get more help from mod_proxy and mod_compress group. Thank you very much.

Regards,
YX

--

[shellcode]

mod_compress only compresses local disk file, not remote file servered by mod_proxy.

[yaoxing zhang]

any work around?
Regards,
YX

On 2009年11月20日 11:07, shellcode wrote:
> mod_compress only compresses local disk file, not remote file servered
> by mod_proxy.
>

> --
>
> You received this message because you are subscribed to the Google
> Groups "mod_cache" group.
> To post to this group, send email to mod_...@googlegroups.com.

> To unsubscribe from this group, send email to
> mod_cache+...@googlegroups.com.