Project

General

Profile

Bug #1869

mod_compress broken in lighttpd-1.4.21-2369

Added by dfavor over 10 years ago. Updated over 10 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Category:
mod_compress
Target version:
Start date:
2009-01-12
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description

Tracking cache use I see this from latest SVN code for the 1.4.x series.

Files are compressed into the cache directory first time they are accessed.

Compressed cache files are never returned. Instead, the original (uncompressed file) is always returned.

I used inotifywatch to track this behavior.

Having a working mod_compress is essential to running a server.

davidfavor.gif (3.63 KB) davidfavor.gif nitrox, 2009-01-14 17:00

History

#1

Updated by dfavor over 10 years ago

Click http://DavidFavor.com/archive/lighttpd for the config files.

I reduced the config from test.conf to simple.conf to ease debugging.

Since several bugs reported relate to virtual hosts failing with mod_compress, I changed simple.conf to only be single host related.

Each time a page is requested, the page is recompressed again, then the uncompressed content is served.

Please let me know if my configuration is incorrect.

Here's what inotifywait reports each access of a page.

net1#pwd
/common/vhost/default
net1#r inotifyw
inotifywait -m -r .
Setting up watches. Beware: since -r was given, this may take a while!
Watches established.
./htdocs/ OPEN index.html
./htdocs/ CLOSE_NOWRITE,CLOSE index.html
./compress/ OPEN index.html-gzip-65790-2738-1231704641
./compress/ CLOSE_NOWRITE,CLOSE index.html-gzip-65790-2738-1231704641
./logs-lighttpd/ MODIFY access.log
./compress/web/ OPEN jquery.js-gzip-18055639-55491-1212167116
./compress/web/ CLOSE_NOWRITE,CLOSE jquery.js-gzip-18055639-55491-1212167116
./compress/web/ OPEN jquery.js-gzip-18055639-55491-1212167116
./compress/web/ CLOSE_NOWRITE,CLOSE jquery.js-gzip-18055639-55491-1212167116
./compress/web/ OPEN base.css-gzip-18056260-2354-1222096036
./compress/web/ CLOSE_NOWRITE,CLOSE base.css-gzip-18056260-2354-1222096036
./compress/web/ OPEN base.css-gzip-18056260-2354-1222096036
./compress/web/ CLOSE_NOWRITE,CLOSE base.css-gzip-18056260-2354-1222096036

#2

Updated by stbuehler over 10 years ago

  • Status changed from New to Need Feedback
  • Priority changed from High to Normal

I can't see anything wrong in that inotify log - only access.log is modified, and the compressed content gets opened. There is nothing wrong if sometimes the original files get opened, either for stat()ing or as someone requested an uncompressed version.

If you really want to show something is broken you should use strace or whatever your platform calls it.

#3

Updated by dfavor over 10 years ago

What's wrong is every page access is serving the uncompressed versions.

In other words, the compress versions are never served.

You can easily test this by using any of the many gzip page testers on the Internet. This is how I caught this challenge.

In this case a gzip page tester will work and there will be no access of uncompressed items. In other words, this will be missing:

./htdocs/ OPEN index.html
./htdocs/ CLOSE_NOWRITE,CLOSE index.html

#4

Updated by nitrox over 10 years ago

I just tested with 1.5 which works like it should, please try the following on 1.4.x too:

Create an test.html full of "1" until you´ve got a filesize of about 5k (to make sure it gets compressed). Use your browser with that file and see if lighty puts that into the compressed directory. Then "mv test-xxxx-xxx test-xxxx-xxx.gz", "gzip -d test-xxxx-xxx.gz and let it overwrite the original file, but remember the file owner/group", "edit some of the "1" and replace them with e.g. "0"", "gzip -6 test-xxxx-xxx", "mv test-xxxx-xxx.gz test-xxxx-xxx", "chown owner:group test-xxxx-xxx".

Go to your browser again, you should see the modified file with some "0" which comes from the compressed file. We think lighty is just doing a stat() on the original and the cached file, but should serve the compressed one.

#5

Updated by dfavor over 10 years ago

No need to go through all this.

If you use http://whatsmyip.org/mod_gzip_test/ and test http://DavidFavor.com
(running apache) and http://DavidFavor.com:1080 (running lighttpd) you'll see the apache version shows gzipped and the lighttpd is served without compression.

#6

Updated by nitrox over 10 years ago

Aehm...

#7

Updated by dfavor over 10 years ago

nitrox wrote:

Aehm...

Highly descriptive comment.

This is confusing. All gzip testers I've used in the past show initial page served without compression. And inotify tools report the uncompressed version is being accessed on the disk, when only the gzip version should be accessed.

Please state the tool you used to generate the davidfavor.gif above and why the uncompressed version of files are continually opened/closed when a compressed version lives in the cache.

Also available in: Atom