mod_compress bug solved in .30?
Added by simonlange over 12 years ago
Hi,
when using mod_compress for application/xml we get the compressed content but at tail throwing a 403 error page.
we are using debian repo and therefore we using 1.4.28. before we attempt to upgrade by compile (and leaving the repo) 1.4.30 wed like to now if this particular bug has been fixed meanwhile. if not there is no such need for leaving repo. ;)
just for info: NO, we dont get a 403 im compression is for for application/xml files.
regards
Simon
Replies (12)
RE: mod_compress bug solved in .30? - Added by stbuehler over 12 years ago
http://packages.debian.org/search?keywords=lighttpd - 1.4.30-1
btw: a good bug report sometimes leads to getting the bug fixed; as mod_compress doesn't care about the mimetype, your description so far is not helpful.
RE: mod_compress bug solved in .30? - Added by simonlange over 12 years ago
helpful is relative. the bug is known.
in case u didnt knew:
http://redmine.lighttpd.net/boards/2/topics/4816
but ur answer isnt useful. is it or is it not fixed? in .30?
and btw: 1.4.30-1 is NOT stable. stable repo's most recent is as i wrote 1.4.28.
so back to topic. question is and was: is the bug fixed in .30 or not.
tyvm
Simon
RE: mod_compress bug solved in .30? - Added by patrickdk over 12 years ago
a known bug, would be listed in the bug tracker, not a forum.
My testing atleast on 1.4.26 shows no issue.
RE: mod_compress bug solved in .30? - Added by stbuehler over 12 years ago
i know 1.4.30-1 is not in stable, but it is a package, so no need to compile it yourself. check GetLighttpd too.
as the bug wasn't in the tracker i have no idea whether it got fixed somehow.
RE: mod_compress bug solved in .30? - Added by simonlange over 12 years ago
.30 still has it. (did compile the most recent version which was available yesterday evening)
compression for static xml files sometimes works, sometimes not. no idea why this happens.
if compress with xml works you get the file delivered code 200. everything fine
then suddenly you get a 403. funny about the 403: in fact was delivered using compress BUT at the tail is the 403 appended. strange.
yes, lighty's user can write and is owner of the cache directory. the file is readable and was not changed nor the posix rights. this is some very strange bug. so for now i wouldnt count on compress on live-systems if you deliver xml files.
here a snippet what comes when you get the content AND the 403 the very same time. ;)
<root count="8018">
<file name="config\engine_config.xml.aup" pack="0" length="355" md5="054f2af910aed0f882780af2505d27ef" md5x=" 05 4f 2a f9 10 ae d0 f8 82 78 0a f2 50 5d 27 ef" />
<file name="config\localsetup.xml.aup" pack="0" length="419" md5="8f549e719d10cd9bc752cf7507f44df3" md5x=" 8f 54 9e 71 9d 10 cd 9b c7 52 cf 75 07 f4 4d f3" />
<file name="d3dx9_37.dll.aup" pack="0" length="2062093" md5="cfbe657a6eb32e9f10fdeaa804631006" md5x=" cf be 65 7a 6e b3 2e 9f 10 fd ea a8 04 63 10 06" />
<file name="data\actiondesc.xml.aup" pack="1" length="316" md5="59feb5dfb410b960c3ad8f8a8322477c" md5x=" 59 fe b5 df b4 10 b9 60 c3 ad 8f 8a 83 22 47 7c" />
</root><?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>403 - Forbidden</title>
</head>
<body>
<h1>403 - Forbidden</h1>
</body>
</html>
note: i have shorten the xml (removed most of the branches). in fact the complete 8018 branches are delivered. ;)
this is observed under 1.4.28-1 and source distribution of 1.4.30
Simon
RE: mod_compress bug solved in .30? - Added by simonlange over 12 years ago
with compression result "403"
xxx.xx.xxx.xx - - [11/Jan/2012:14:24:09 +0100] "GET /autopatchlong01/update_filelist.xml HTTP/1.1" 456836 "457066 +" 403 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-"
compression disabled result 200
xxx.xx.xxx.xx - - [11/Jan/2012:14:32:03 +0100] "GET /autopatchlong01/update_filelist.xml HTTP/1.1" 1463813 "1464011 +" 200 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-"
-rw-r--r-- 1 git git 1463813 Jan 11 11:35 update_filelist.xml
457066 bytes send (the file is 1463813 on disk). so compression works so far - well - at least until the 403 is thrown AFTER the file itself was send.
RE: mod_compress bug solved in .30? - Added by darix over 12 years ago
1. can you join #lighttpd on freenode for a bit more interactive debugging?
2. does deleting the cached file on disk help?
3. are the permissions for the mod_compress cache directory correct?
RE: mod_compress bug solved in .30? - Added by simonlange over 12 years ago
sorry dont have a irc client installed here. ;)
the cached file isnt on disk. at least not at the defined place so far. /var/cache/lighttpd/compress
lighttpd and subs are 777 and the lighty-user "www-data" is owner. (www-data.www-data)
the funny thing about this is that its running sometimes without throwing a 403 at the tail.
but if compress is enabled it always DOES compress (as you could see at the log entries.).
thats why i dont think its an actual posix problem. i suspect some kind of bug, especially because im not the only one who did observe this strange behavour (see the link i did refer in my second post).
but of course i did double check all permissions ownerships. since its a critical live system i cannot debug it that much (every downtime is instantly noticed). im going to try at some idle time to strace it. maybe this points to the right direction.
but keep in mind. usually if access is forbidden you get ONLY the page itself (403 page) and NOT the content of the requested file.
in this case i get not only the content, its even compressed as configured. usually i would expect at the end a solid 200. but instead i do get a 403 i cannot explain. oO
compress.cache-dir = "/var/cache/lighttpd/compress" compress.filetype = ( "application/x-javascript", "text/css", "text/html", "text/plain", "text/xml", "application/xml" )
of course i also tried using only text/xml or only application/xml. but lighty itself declares *.xml files as text/xml by distribution. so text/xml should be correct. anyway, there is no difference if i have both or just one of it in the filetype definitions. ;)
RE: mod_compress bug solved in .30? - Added by stbuehler over 12 years ago
- can the www-data user access all directories in the cache-dir path? 777 is a bad idea. (try "su -s /bin/sh www-data", and then try to access the directory with the absolute path).
- did you disable etags?
- i guess you update the file very often - do you use atomic updates? (create new tmp file in same directory, write it, then rename it)
if etags are enabled and a cache-dir is set, it will try to use the cache dir - if it can't create files it won't compress anything.
if etags are disabled cache-dir isn't used (there is a bug which might explain what you are seeing: it will compress in memory, as the cache dir isn't used, but will forward the request to mod_staticfile). this bug should be fixed in current svn now (git sync might take some minutes).
RE: mod_compress bug solved in .30? - Added by simonlange over 12 years ago
stbuehler wrote:
if etags are disabled cache-dir isn't used (there is a bug which might explain what you are seeing: it will compress in memory, as the cache dir isn't used, but will forward the request to mod_staticfile). this bug should be fixed in current svn now (git sync might take some minutes).
bingo! that solved it. we had it disabled because we have geolocation based loadbalancing running. thats why we had etags disabled. no real problem until the r&d department did request compression. ;)
i guess u fixed it in 1.5 (unstable) branch? will it be shipped with 1.4.31+?
tyvm. i appreciate ur help.
Simon
RE: mod_compress bug solved in .30? - Added by stbuehler over 12 years ago
no idea whether 1.5 even has the problem, but 1.5 isn't maintained anymore. (we are working on 2.0)
workarounds: either enable etags (size+mtime should be the same on all mirrors, just disable inode), or disable compress.cache-dir.