gzip compression wildcards STILL not working

aww · Jul 23, 2007

I reported this back with 3.1 and it's still not working in 3.2

under:
/config/confMgr.php?m=serv&p=tuning&t=SERV_TUNING_GZIP&a=e

text/* is NOT being obeyed

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.

mistwang · Jul 23, 2007

You need to add those types to LiteSpeed's MIME configuration file through our web admin interface.

aww · Jul 24, 2007

Sorry if I am not being clear, but I did indeed add them through the admin interface and did the graceful restart.

Wildcards still do not work.

Please test the standard version in your lab and confirm?

mistwang · Jul 24, 2007

Are you sure. It should be added to the server wide MIME configuration, vhost level or context level does not work.

aww · Jul 25, 2007

I posted the url to show you the menu that it's under.
It's under tuning.

/config/confMgr.php?m=serv&p=tuning&t=SERV_TUNING_GZIP&a=e

xing · Jul 25, 2007

No, it should be under Server->General->MIME File, add your MIME there

aww · Jul 25, 2007

litespeed supports the "addtype" directive and I've done it in .htaccess for backwards compatibility with apache

If it's added by addtype, shouldn't the gzip compression be enforced if the mime is in litespeeds compression list? That would mimic apache's mod_gzip behavior/directives.

mistwang · Jul 25, 2007

Type added through AddType is not checked for compression. Only globally defined types are. It does not hurt anything by adding the type globally.
We will address this issue later.

aww · Jul 26, 2007

Ah, so technically it is a bug, since it doesn't mimic apache's compatibility. At least I know now that I'm not going crazy and know what's causing this.

Optionally, in a future version you might want to consider supporting mod_gzip directives in httpd.conf/htaccess?

Here's a list of them with definitions:
http://schroepl.net/projekte/mod_gzip/config.htm
Litespeed already has control over almost all those options so technically you could mimic it if you wanted.

subBlue · Jul 27, 2007

YSlow for profiling in Firebug and GZip

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?

aww · Jul 27, 2007

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

added: even the css on this site is not being compressed:
http://www.litespeedtech.com/static/css/template.css
refuses to be served with compression
(and I am assuming litespeed has text/* in their compresion settings and text/css in their default mime types)

mistwang · Jul 27, 2007

We will look into the problem.

mistwang · Aug 7, 2007

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.

aww · Aug 7, 2007

Wonderful news. Will be testing shortly.

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)

ie.

Code:

wget --limit-rate=100000 http://www.litespeedtech.com/packages/3.0/lsws-3.2.1-std-i386-linux.tar.gz

aww · Aug 7, 2007

Apparently I will have to wait for more instructions.
Upgraded to 3.2.1 and I see the new "Static GZIP Cache Directory" setting.

I tried /tmp and /tmp/ and $SERVER_ROOT/gzip/
Nothing worked (restarted lsws after each time)
Still no compression on .css and .js types.

There are now files however in the $SERVER_ROOT/gzip directory and the owner has been changed from root:root to nobody:nobody so I believe lsws sees it and is using it.

Both the .css and .js files I am testing on are well above the minimum filesize for compression.

I'll wait to hear more...

mistwang · Aug 8, 2007

The MIME type of .js is not text/*, so you need to add that explicitly.
If the file is cache, then the response header will not include the gzip header. Clear your browser cache and try again.

aww · Aug 8, 2007

I added the mime type for js long ago.
But let's just use the css for now as an example.

Both my browser and my php test tool for gzip (which does not cache in any circumstance) are showing it as still uncompressed.

Code:

GET /forums/example/style.css HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.x 200 OK
Date: Wed, 08 Aug 2007 14:19:40 GMT
Server: LiteSpeed
Accept-Ranges: bytes
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Cache-Control: max-age=604800
Expires: Wed, 15 Aug 2007 14:19:40 GMT
Etag: "1dde-46aca652-37c334e"
Last-Modified: Sun, 29 Jul 2007 14:38:10 GMT
Content-Type: text/css
Content-Length: 7646

mistwang · Aug 8, 2007

Please try adding "text/css" explicitly to the list see if help, we have done some experiments with our live site, sometime it interfere with the expires configuration, we will continue investigation.

mistwang · Aug 8, 2007

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.

aww · Aug 9, 2007

I finally got it working. But the problem was not what we thought.

One thing you never mentioned is that "Auto Update Static" must be turned on.

That was the entire problem.

But that is very confusing in the settings. Is it really required to be enabled?

The first "Enable Compression" option is followed by "Enable Dynamic Compression". That implies the first option is for static files. Any further options are therefore, optional.

Is it not possible to have static files compressed on the fly without storing .gz verisons first?
It should be. More overhead yes, but might be necessary in some environments.

I assume litespeed checks the original file for changes and re-creates the .gz if there is a timestamp difference?

gzip compression wildcards *STILL* not working

Well-Known Member

LiteSpeed Staff

Well-Known Member

LiteSpeed Staff

Well-Known Member

LiteSpeed Staff

Well-Known Member

LiteSpeed Staff

Well-Known Member

Active Member

Well-Known Member

LiteSpeed Staff

LiteSpeed Staff

Well-Known Member

Well-Known Member

LiteSpeed Staff

Well-Known Member

LiteSpeed Staff

LiteSpeed Staff

Well-Known Member

gzip compression wildcards STILL not working