Lighttpd rewrite rules wanted

As I don't myself need Lighttpd support presently, I have no plans for this right now. It will have to wait for somebody who is interested in running Drupal + Boost on Lighttpd and volunteers to figure it out.

I use this in my lighttpd.conf:

Hope it helps ;). You should enable mod_rewrite in the server.modules section. This should work with any version of Drupal, I tested on 5.
Cheers.

I forgot to add a rule for the home link, "^/$"=>"/index.php?q=node", so here it is:

Cheers.

Hi, has anyone made these rules? I have setup lighttpd using this tutorial:

http://joshhuckabee.com/drupal-lighttpd-and-xcache-debian-2

I would like to add the boost capability for it.

I am also looking for lighttpd rules for the boost rewrite rules. I tend to think it is possible since lighttpd does have mod_rewrite and using the mod_magnet we might be able to get to some logic in a lua extension.

ok here is some lines of code I added to my existing lua rules for lighty to work with boost.

Lighty Env Assumption:
==================
you are running lighty enabled with fast-cgi and with mod_magnet module enabled and using lua to process conditionals and/or clean URLs.

Need to patch:
===========
There is one additional patch you will need (unless the current version already has it) to get a handle on lighty.env["request.method"]. Due to a bug this table was rendered empty in mod_magnet. I used the patch from this link : http://trac.lighttpd.net/trac/changeset/2137.

So after patching to add the steps for MAGNET_ENV_REQUEST_METHOD and MAGNET_ENV_REQUEST_PROTOCOL don't forget to recompile lighty again with the lua path.

The LUA Conditionals and approach
===========================
Some of this code especially the part that hands control over to drupal to render physical path at index.php, I already had from an earlier source and you are probably using it too. The additions I made are to handle the boost rules. So far its working nicely for me after some hair pulling .. and I have tested for as many conditions I can think of .. essentially accomplishing the functionality similar to the .htaccess rules that boost comes with. Pls provide comments / opinion to improve this further or maybe even another better approach.

A Word on performance
==================
I have researched a bit on the string functions and how costly they are as opposed to the REGEXP rules processing .. lua should be much more efficient as long as its not processing/reading in a big files for input. Also in the rules conditions matching I tried to follow the least travelled path to get from point A to B. So first, I evaluate for static files like jpg, css etc. and if it finds it get lighty to serve it up. Next I apply the first combined filter "anonymous user" ? AND "not a query string" ? AND "GET" ? and in that order since I want to try to avoid any unnecessary evaluations and thus using the most restrictive filter criteria first (assumption is dependent on site type). Since this is an AND'ed evaluation I need to find the likelihood of any of the 3 criteria that will MOST likely give me false at the earliest point in time and help me avoid the other two evals .. for me that is the logged in user, since query strings will be quite prevalent and GET paths will be MOST prevalent. The next is the PATHS type filter for "/user" ? OR "/cache" ? OR "/admin" and in that order again based on the path most likely to be true first.. and then onwards..

I may consider the use of LPEG as another lua library for the expression matching , but given the simplicity of the patterns we are after here, the string functions should be quite efficient. In any case unless you are looking at trying to serve up > 1000 req/sec I dont think that lua performance will hold us back . If someone using lighttpd have a way to benchmark I'd love to hear more on this.

So here is the code attached .. If you see ways to improve for performance/functionality I would most appreciate it. I compacted the code as much as I could at this initial pass but there may be more iterations needed to get to an even smaller footprint. Also I am hoping that any bugs will come to surface as you try out different conditions. I can guarantee some bugs will be site dependent that is related to caching rules and some erratic behavior with caching (you have to test and tweak .. one thing I learnt about boost ) and may require individual tweaking for your own site but it would help to know if there any universal type bugs (fundamental logical flaw or any other type of performance improvement).

Attachment	Size
boost_lighttpd_luaRules_ver1.txt	2.58 KB

Hi drupdrips,

thank you for this great work, it's good to know that someone cares about Lighty ;)

I tried to get this to work on Debian GNU/Linux "Etch" for several hours; to save others the tedious work, some notes: "Etch" comes by default with Lighty 1.4.13-4 that does not include the Patch mentioned above. However drupdrips' modified "drupal.lua" won't harm Lighty, but Drupal doesn't use the Boost cache either.

Lighty version 1.4.19-5 - which should include the crucial patch - is available in Etch Backports; this package is broken at the time of this writing and includes several critical bugs; it can neither be easily fixed (dpkg --configure -a) nor overriden by the usual options (--force etc.). As far as I can see at the moment, running Drupal with Boost and Lighty on Etch requires currently to build it from source - if there's no fix for Lighty 1.4.13-4.

Happy hacking! -asb

If you can't get the patch to be able to do eval for lighty.env["request.method"] == "GET" or using another way to check the request method within the lua code environment (if you are using lua for conditional evals and clean URLs) , the boost rules will not work with lighty. From my observation, the patch did not seem to be Linux distro specific, although I could be wrong.

One thing I would say, nothing worked for me initially and I had to debug the hell out of it to get it to work. What I mentioned above is the packaged solution that is working for me, but you may have some other tweaks you have to invest some time in, but I do not think it should be unworkable.

You probably already tried debugging, but if not, try putting in a bunch of print statements at the beginning (under local prefix = '' line) to see if the variables values are as you expect them to be and at the end try to print the Final path also. Something like this is what I was using but also print statements in between wherever there is a transition or an important assignment taking place.

print (" ")
print ("********************************************")
print ("Initial Variable Values are: ")
print ("env.uri.query is : " .. (lighty.env["uri.query"] or "nil"))
print ("env.request.uri is : " .. (lighty.env["request.uri"] or "nil"))
print ("env.request.method is : " .. (lighty.env["request.method"] or "nil"))
print ("request.cookie is : " .. (lighty.request["Cookie"] or "nil"))
print ("request.Host is : " .. (lighty.request["Host"] or "nil"))
print ("uri path is " .. lighty.env["uri.path"] .. " -- physical path is " .. lighty.env["physical.path"])
print ("Referer is " .. (lighty.request["Referer"] or "nil"))
print ("Cache-Control is " .. (lighty.header["Cache-Control"] or "nil"))
print ("Expires is " .. (lighty.request["Expires"] or "nil"))

Without the mod_magnet patch the value for lighty.env["request.method"] will be empty and then boost rules will not work. So one way or the other you have to be able to patch it or use a version that already includes it. (I am using 1.4.19) and I still had to patch it. Not sure if the latest 1.4.20 has it or not.

BTW pls don't modify the Issue Title. I changed it back.

I'm using 1.4.20, drupal.lua works fine for me,
but when I add "boost_lighttpd_luaRules_ver1.txt" inside drupal.lua I've got "500 - Internal Server Error"
is it seem that I need to patch it?

To make it clear to me,.. how to use the patch?
is it used to patch the lighttpd tar ball source? so I should re compile and re install the lighttpd?

thanks in advanced

Note that if you want the power of Boost and you are willing to still run Apache for your dynamic pages, you can set up a ProxyPass that directs all requests for pages in the cache directory to Lighttpd. Just put something like the following in the VirtualHost record:

Check your memory limit in php.ini file. Is it at least 16mb ? The default 8mb is too small especially if you are enabling CCK and Views etc. Not having enough memory will be a cause for the 500 error.

you can try putting the print statements in the lua file and check for the debug output from lighttpd.error.log file to see what values you are getting.

If you do patch the lighttpd to include the patch for mod_magnet so you can get a handle on request_method, then yes you have to recompile lighty. I just ran sudu, make, make install after the patch is applied. Also make sure the config includes path to lua .. You can do the following :

./configure --with-lua PKG_CONFIG_PATH=/path/to/lua/
sudu
make
make install

Hi, does anyone confirm that http://drupal.org/node/150909#comment-695427 works for D6 version? Thanks.

If someone wants to write the rules for lighttpd, here's the bare minimum apache rules. I've been able to get everything down to this one rule, if your using the 6.x-1.x-beta1 or above.

If you want gzip support here are the rules for that

Looking at #6 and it's not supper clear on how to modify it to work with the new rules.

Just adding the lines suggested in #10 doesn't work (using 127.0.0.1:81, where lighttpd is listing my home files)
It gives me this error

but the URL at that page is still the correct one: http://localhost/family/white-eyes-zosteropidae
Removing these 4 lines and reloading results in apache serving the boosted html page.

It looks like I need to change the .htaccess file, not just the httpd.conf.

@ferrangil
your error is related to permissions. Try this patch #500944: internal umask overriding system defined umask & set your file permissions to something like 0644.

@ferrangil
Looks like your using 5.x so the above patch will not work in your case. Sorry about that.

Yes, I'm on 5.x. I'll try to look at the patch and adapt it to 5.x if possible. Thanks

After a file is written @chmod($filename, 0664); is all you need to do.

This would be nice to add to the release archive as something like boosted/lighttpd/boosted1.txt with a little documentation.

@andrewsuth
What's the standard way to do it?

@mikeytown2: Well, I actually didn't read the thread closely enough, I thought they'd already come up with a working and tested script for lighttpd.

I guess the stard procedure would be to make sure the community is happy with the code then add it to the CVS for future releases.