gzip compression wildcards *STILL* not working

aww

Well-Known Member
#1
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.
 
Last edited:

aww

Well-Known Member
#3
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?
 

aww

Well-Known Member
#5
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
 

aww

Well-Known Member
#7
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

LiteSpeed Staff
#8
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

Well-Known Member
#9
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

Active Member
#10
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

Well-Known Member
#11
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)

http://www.litespeedtech.com/static/css/template.css

GET /static/css/template.css HTTP/1.1
Host: www.litespeedtech.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
[missing "Content-Encoding: gzip" here]
[missing "Vary: Accept-Encoding" here]

Date: Fri, 27 Jul 2007 12:17:02 GMT
Server: LiteSpeed
Accept-Ranges: bytes
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Etag: "20c1-469bead3-3c8252"
Last-Modified: Mon, 16 Jul 2007 22:01:55 GMT
Content-Type: text/css
Content-Length: 8385
Cache-Control: max-age=604800
Expires: Fri, 03 Aug 2007 12:17:02 GMT
 
Last edited:

mistwang

LiteSpeed Staff
#13
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

Well-Known Member
#14
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

Well-Known Member
#15
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...
 
Last edited:

mistwang

LiteSpeed Staff
#16
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

Well-Known Member
#17
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
 
Last edited:

mistwang

LiteSpeed Staff
#18
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

LiteSpeed Staff
#19
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

Well-Known Member
#20
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?
 
Last edited:
Top