For example I discovered text/javascript was not being compressed and I had to add it manually, in addtion to text/*

But now I am having an additional problem in that .htc files which are mime type "text/x-component" do not get compressed even when text/x-component is added to the list. The analyzer I use to determine this shows the proper mime type is being sent and will always accept compression if the server offers it. The filesize is larger than the minimum set for compression.

I've been using the new YSlow addon for performance profiling in Firebug.

None of the CSS or JS files served by my site are getting gzipped despite having the default settings of text/*, application/x-javascript, application/xml in the list of compressible types. I also tried adding text/css directly to the list but it still wouldn't compress the CSS.

The header settings for the CSS files are defined as text/css and that is listed in the recognised mime-types in LS, so I don't know why the CSS isn't getting compressed. The main page body is getting compressed though.

The site is a Rails app running with LS 3.2-ent, but we are seeing this behaviour with all four of our servers using LS, which have pretty much the default configuration settings. Any suggestions here?

Argh, you are correct. text/css is not compressing either and I could have sworn I checked for and fixed this in our 3.1.1 configuration. So it either reverted or never worked. That's millions of pageviews now without compression

And that one *is* under "Mime Type Definition" by default.

So it's definitely a bug unless they can explain otherwise?

I assume you are using the commercial version given the number of servers, etc. so this is not just a standard version bug anymore...

added: even when the file is renamed to style.txt and served as text/plain it's not compressed

The problem should be addressed in the latest 3.2.1 build. A dedicate gzip cache directory will be used for static content, so LSWS will not require rewrite permission to user's document root directory in order to serve compressed version of static files.

By the way, I wanted to report (again) that I've always had trouble doing a direct wget from your servers of the package. The download stalls out. To solve the problem I have to limit the rate (and even that doesn't always work)

Please download and try the updated 3.2.1 package. you may see uncompressed version being served during the construction of the compressed cache for that file, once the compressed version was built, compressed version will always be served.