Ultimate Lua Script - Discussion

Posted by Garrett Albright on August 18, 2009 at 5:47pm

The script is here, but I figured I'd start a discussion about it too since there doesn't seem to be a way to comment on wiki pages on g.d.o.

Anyway, I recently updated the script, fixing the patterns (regular expressions) a bit and making it so redirects return an HTTP status code of 301 instead of 302, to more closely match the behavior of Drupal's .htaccess file. If you're already using the script, updating it isn't strictly necessary, but it shouldn't hurt.

Comments

I've posted the latest

Posted by Garrett Albright on December 22, 2009 at 4:18pm

I've posted the latest version, which is almost a complete rewrite. It now features easier, more clear configuration and support for the Boost module, and I seem to have somehow unintentionally fixed multi-lingual sites not working correctly.

The Boise Drupal Guy!

When I install Drupal on

Posted by AdrianB on February 11, 2010 at 8:59am

When I install Drupal on Apache i put all the files in a drupal subdirectory and keep a modified .htaccess file in the web root (and changes $base_url in settings.php). This make the installation cleaner and it's easy to swap between drupal directories when upgrading.

My question (without knowing anything about Lighttpd or Lua) is this easy to achieve with this Lua script and Lighttpd?

Well, I'm not quite sure what

Posted by Garrett Albright on February 11, 2010 at 4:44pm

Well, I'm not quite sure what you're asking, and possibly you don't either. Lua scripts and .htaccess files aren't really analogous, in that the former are full scripts which allow you to do loops, arithmetic, string manipulation, etc. Lua scripts can't really change configuration settings at runtime, but they can change what the web server outputs - to add a header to output based on a certain condition, for example.

There's not really an equivalent to .htaccess files in Lighty in terms of per-directory configuration files. You have one single lighttpd.conf file, and though you can include other configuration files on a conditional basis (if a file from a particular domain name is being requested, for example), it's not quite as flexible as Apache's .htaccess scheme.

Hope that answers your question…

The Boise Drupal Guy!

What my question really was

Posted by AdrianB on February 11, 2010 at 7:54pm

What my question really was was this:

Is it possible to run Drupal from a subdirectory when using Lighttd instead of putting all files directly in web root?

What I mean by that is that all Drupal files are in http://example.com/drupal/ but the URL is just http://example.com/, as it would if I'd just put the files in the web root. This is very easy to achieve with some URL rewrite "magic" i Apache.

I thought this Lua script enabled the clean URLs in Drupal and therefore did something similar to .htaccess, and maybe could be used to put Drupal in a sub directory just like .htaccess can on Apache. I don't know anything about Lighttd, or how it differs from Apache. If the Lua script is not what I'm looking for, then is it possible to do this from lighttpd.conf?

So your web root for

Posted by Garrett Albright on February 11, 2010 at 8:18pm

So your web root for example.com in your case is inside another site's web root?

That strikes me as bizarre, but I don't see why that shouldn't be possible. Your config file could look something like this (untested, but should point you in the right direction):

$HTTP["host"] != "example.com" {
  server.document-root = "/usr/local/www/"
}
else $HTTP["host"] == "example.com" {
  server.document-root = "/usr/local/www/example.com/"
}

Note that Lighty's config file syntax supports elseif-like statements, but no just generic else, which is slightly WTF but fairly easy to work around. Also note that we're not using the Lua layer at all here.

If you have a lot of different sites in different directories, though, you should consider using the mod_simple_vhost module, included by default with Lighty. It does virtual hosts, but is much easier to configure than Lighty's "full" virtual hosts module (and definitely easier than Apache's version). For example, check out what you can do with just these three lines in your config file (after enabling the module):

simple-vhost.server-root = "/usr/local/www/"
simple-vhost.default-host = "example.com"
simple-vhost.document-root = "/"

When a request for example.net hits your server, Lighty will check to see if /usr/local/www/example.net/ exists. If so, it will use that directory as the web root; if not, it will use /usr/local/www/example.com/. (Whatever you've set for your "normal" web root with server.document-root is ignored.) Creating a new site is as easy as creating a new directory which matches the domain name for the site you wish to host.

The Boise Drupal Guy!

So your web root for

Posted by AdrianB on February 11, 2010 at 8:31pm

So your web root for example.com in your case is inside another site's web root?

That strikes me as bizarre, but I don't see why that shouldn't be possible.

In my case the web root has been a public_html folder on shared hosting. Now that I think about this it would probably be a non issue if you control the server and therefore can choose whatever web root you want.

And btw, thanks for taking

Posted by AdrianB on February 11, 2010 at 8:39pm

And btw, thanks for taking your time to answer me!

Boost Support if lighttpd port != 80?

Posted by mikedance on February 19, 2010 at 12:13pm

Hello,

Does this configuration support running lighttpd on a different port?

I am running lighttpd on port 81 on my development setup, the configuration appears to be working fine, except it does not appear to be serving the boost cache files (I do not see the boost comment in the bottom of the file).

I know boost is configured correctly on the database side because when I visit the same url on port 80 (apache) it services the boost cache file no problem.

To tell the truth, I've not

Posted by Garrett Albright on February 19, 2010 at 5:51pm

To tell the truth, I've not tested Boost support on non-standard ports. That being said, I'm not sure why it wouldn't work, assuming all other things are working correctly. Could you try taking down Apache and then testing if Boost works with Lighty on port 80? If not, then I suspect something else is askew somewhere in your configuration besides this script.

The Boise Drupal Guy!

I just updated the script

Posted by Garrett Albright on March 10, 2010 at 6:06pm

I just updated the script again. This new version fixes a bug where dirty URLs would not work with Drupal on the server if index.php wasn't explicitly in the URI (so http://example.com/index.php?q=foo would work, but http://example.com?q=foo would just go to the front page of example.com), and also adds very simple cross-server hotlink/leeching protection.

The Boise Drupal Guy!

Can't seem to get boost

Posted by cybe on April 8, 2010 at 8:56am

Can't seem to get boost working. Any ideas how to find out why? Any way to get lighttpd give me useful logs?

I tried modifying the lua script with something I found on the mod_magnet manual but it didn't give me much

 print("Host: " .. lighty.request["Host"])
 print("Request-URI: " .. lighty.env["request.uri"])
 

Other things in the script are working, love_www, boost_header, but X-Boost-Path is always miss. New version of boost, creates files in cache/ successfully
Lighttpd chrooted to /webroot
Using simple-vhosts

What do you mean by "useful

Posted by Garrett Albright on April 8, 2010 at 9:01pm

What do you mean by "useful logs?" Look in Lighty's .conf file for the server.errorlog directive to see where it's logging errors to - is that enough for you?

Are you still seeing "miss" when you are logged out of the site?

Once you've found Lighty's error log, the print() command in Lua can be used to print data to the error log, which is useful for debugging - though I've removed all such lines from the script. You may be able to use that to trace through the script and find where things are going wrong. Try putting one in the check_exists() function to see which paths the script is checking for the existence of cached files at.

The Boise Drupal Guy!

Well I mean more detailed

Posted by cybe on April 8, 2010 at 9:14pm

Well I mean more detailed logs. Not enough in the errorlog. Yes, also "misses" when logged out. I'll try modifiying the .lua script like you recommended tomorrow, thanks for the help.

I'm just not able to figure

Posted by cybe on April 9, 2010 at 1:07pm

I'm just not able to figure out where/how to add the prints, could you, when you have the time, give me some examples please?

Edit: now i'm getting somewhere...

I've added this:

print("physical.path: " .. lighty.env['physical.path'] )
print("uri.path: " .. lighty.env['uri.path'] )
print("physical.rel-path: " .. lighty.env['physical.rel-path'] )

which spits out this:

2010-04-09 16:04:54: (mod_magnet.c.170) (lua-print) physical.path: /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/css/css_7e803f5f82ae862a864b9a852521e87a.css_.css.gz 
2010-04-09 16:04:54: (mod_magnet.c.170) (lua-print) uri.path: /cache/perm/example.org/sites/default/files/css/css_7e803f5f82ae862a864b9a852521e87a.css_.css.gz 
2010-04-09 16:04:54: (mod_magnet.c.170) (lua-print) physical.rel-path: /cache/perm/example.org/sites/default/files/css/css_7e803f5f82ae862a864b9a852521e87a.css_.css.gz 
2010-04-09 16:04:54: (mod_magnet.c.170) (lua-print) physical.path: /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/js/js_a8515b8ca74b60f490a9c4554004d16f.js_.js.gz 
2010-04-09 16:04:54: (mod_magnet.c.170) (lua-print) uri.path: /cache/perm/example.org/sites/default/files/js/js_a8515b8ca74b60f490a9c4554004d16f.js_.js.gz 
2010-04-09 16:04:54: (mod_magnet.c.170) (lua-print) physical.rel-path: /cache/perm/example.org/sites/default/files/js/js_a8515b8ca74b60f490a9c4554004d16f.js_.js.gz 
2010-04-09 16:04:54: (mod_magnet.c.170) (lua-print) physical.path: /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/js/js_6c191291e5b6b7d11ad222ac2c66748d.js_.js.gz 
2010-04-09 16:04:54: (mod_magnet.c.170) (lua-print) uri.path: /cache/perm/example.org/sites/default/files/js/js_6c191291e5b6b7d11ad222ac2c66748d.js_.js.gz 
2010-04-09 16:04:54: (mod_magnet.c.170) (lua-print) physical.rel-path: /cache/perm/example.org/sites/default/files/js/js_6c191291e5b6b7d11ad222ac2c66748d.js_.js.gz 

The files do exist. I see two // after htdocs, I wonder if that has an effect, and where the extra / has been defined.

No mention of the /cache/normal paths above though?

That's not really useful

Posted by Garrett Albright on April 9, 2010 at 3:28pm

That's not really useful info… Look at the check_exists() function which begins on line 161, and add print(stats.physical) right after line 162:

  local check_exists = function(paths)
    for idx, stats in ipairs(paths) do
      print(stats.physical)
      if lighty.stat(stats.physical) then
        lighty.env['physical.path'] = stats.physical

The Boise Drupal Guy!

Thanks.... gives out very

Posted by cybe on April 9, 2010 at 4:05pm

Thanks.... gives out very similar output, it's serving the stuff from perm ok, but nothing from normal...

2010-04-09 19:01:35: (mod_magnet.c.170) (lua-print) /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/js/js_26f325d634b16f17a1e1766f23441e70.js_.js 
2010-04-09 19:01:35: (mod_magnet.c.170) (lua-print) /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/js/js_26f325d634b16f17a1e1766f23441e70.js_.js.gz 
2010-04-09 19:01:35: (mod_magnet.c.170) (lua-print) /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/js/js_26f325d634b16f17a1e1766f23441e70.js_.js 
2010-04-09 19:01:36: (mod_magnet.c.170) (lua-print) /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/css/css_28474dc66e964e09cb05d86637860aa2.css_.css.gz 
2010-04-09 19:01:36: (mod_magnet.c.170) (lua-print) /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/css/css_28474dc66e964e09cb05d86637860aa2.css_.css 
2010-04-09 19:01:36: (mod_magnet.c.170) (lua-print) /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/css/css_28474dc66e964e09cb05d86637860aa2.css_.css.gz 
2010-04-09 19:01:36: (mod_magnet.c.170) (lua-print) /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/css/css_28474dc66e964e09cb05d86637860aa2.css_.css 
2010-04-09 19:01:37: (mod_magnet.c.170) (lua-print) /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/js/js_f83a66514e5116dcb24fa2976aa29b41.js_.js.gz 
2010-04-09 19:01:37: (mod_magnet.c.170) (lua-print) /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/js/js_f83a66514e5116dcb24fa2976aa29b41.js_.js 
2010-04-09 19:01:37: (mod_magnet.c.170) (lua-print) /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/js/js_f83a66514e5116dcb24fa2976aa29b41.js_.js.gz 
2010-04-09 19:01:37: (mod_magnet.c.170) (lua-print) /var/www/example.org/htdocs//cache/perm/example.org/sites/default/files/js/js_f83a66514e5116dcb24fa2976aa29b41.js_.js 

Any ideas?

So you're saying the stuff

Posted by Garrett Albright on April 9, 2010 at 4:14pm

So you're saying the stuff being served from "perm" does have an X-Boost-Path header of something other than "miss?"

The Boise Drupal Guy!

Yes, checked with

Posted by cybe on April 9, 2010 at 6:22pm

Yes, checked with LiveHTTPHeaders...

CSS/JS has this in the headers:

X-Boost-Path: /cache/perm/example.org/sites/default/files/css/css_28474dc66e964e09cb05d86637860aa2.css_.css.gz

X-Boost-Path: /cache/perm/example.org/sites/default/files/js/js_26f325d634b16f17a1e1766f23441e70.js_.js.gz

but the rest just "in normal":

X-Boost-Path: miss

more header copy/paste here: http://pastebin.com/rx1z2WZf

I set up my server to serve

Posted by Garrett Albright on April 10, 2010 at 7:17am

I set up my server to serve Nocturban through Boost again using this script, and it seems to be working just fine. I've enabled the header feature, so check it out for yourself on that site. (If you do see a "miss" on a page, try reloading - the first hit on any given page will cause "miss" because Boost hasn't generated the cache file yet (Boost's spidering feature aside).)

I'm not familiar with LiveHTTPHeaders, as I prefer to use Firebug's header browsing feature myself - do you know if that program checks headers by sending a "HEAD" request to the server? The script as it is currently will only behave correctly to "GET" requests. This is sort of wrong, but I'm not sure if it's worth fixing. Anyway, if you have Firebug, try using that (you can use the "Net" tab to view net connections, then open the disclosure triangle to look at the headers that were exchanged). Or, if you are on a Unix/Linux box and aren't afraid of the command line, try curl -i http://example.com and check out the top of the output for the headers the server sent (don't use curl -I or you'll have the same "HEAD" problem).

If after all this, it's still not behaving as normal for you… sorry, I'm out of ideas…

The Boise Drupal Guy!

@cybe: Would the double

Posted by andrewsuth on July 31, 2010 at 10:44am

@cybe: Would the double backslash between htdocs and cache you've got in the path make a difference?
../htdocs//cache/..

I think lightty normally corrects these issues but maybe it makes a difference in this case?

Using the latest version of

Posted by theongrey on April 9, 2010 at 8:43pm

Using the latest version of your Lua script but our Lighty won't serve cached pages. Boost creates all the cache files correctly though. I wonder if the script is even being loaded... because enabling/disabling the Boost Header doesn't change anything (can't see the X-Boost-Path header either way)... but clean URLs still work, so I don't know.

theongrey, maybe this is a

Posted by Garrett Albright on April 10, 2010 at 7:16am

theongrey, maybe this is a dumb question, but did you also enable Boost support (boost_on = true) before enabling the header feature?

If so, but you're still not seeing the header, check to make sure that the script is indeed not being loaded and there's not something else that's doing the clean URL work. Playing with the print() command and examining Lighty's error log as described above may help.

The Boise Drupal Guy!

Yes, I made sure to enable

Posted by theongrey on April 23, 2010 at 8:44pm

Yes, I made sure to enable boost in the script but I still saw the same behavior.

Unfortunately, I had to switch to the Apache web server to get this working. I didn't have any more time to mess around with it.

I just posted an update to

Posted by Garrett Albright on May 3, 2010 at 10:15pm

I just posted an update to the script which changes the way the leech detection of the anti-leech feature works. It worked using Lua patterns, but URLs which featured reserved characters for Lua patterns - such as the hyphen! - would always cause false positives. Unfortunately, there doesn't seem to be an easy way to escape a bit of text for pattern matching as there is in PHP, so the rewrite uses standard string handling functions - painful for a regex fan like me, but it works.

The Boise Drupal Guy!

Why this not works for me?

Posted by Rockland Steel on May 4, 2010 at 6:52pm

This is what Im doing:

Install lua, and uncomment mod_magnet
"mod_magnet",
adding link to lua script
magnet.attract-physical-path-to = ( "/var/www/html/boostdru.lua" )
I also tried
magnet.attract-physical-path-to = ( server.document-root + "boostdru.lua" )
upload the Lua script and restart lighttpd (no error message)

the cache files created in the "cache" directory, but anonymous visitor still seeing uncached

Well, clearly, you're not the

Posted by Garrett Albright on May 4, 2010 at 8:26pm

Well, clearly, you're not the only one who can't seem to get Boost to work for them… Sorry, but without being able to sit down and play with your server, the best I can say at this point may be, "it works for me." Enabling the debugging headers may help you suss out the problem, though. Good luck.

The Boise Drupal Guy!

The recent addition of

Posted by Garrett Albright on May 28, 2010 at 9:04pm

The recent addition of url.rewrite-if-not-file to Lighty's configuration file syntax means that basic URL rewriting for Drupal on Lighty can now be done in the basic .conf file:

server.modules += ("mod_rewrite")

url.rewrite-if-not-file = (
  "^/(?!favicon\.ico)(.*)" => "/index.php?q=$1"
)

I'm experimenting to see if Boost rewriting can now be done at the .conf level as well. A lot of the mess in my Lua script is due to the fact that I've had to work around Lua's weak not-quite-RegEx pattern matching; however, .conf files seem to support every RegEx trick I throw at them, as evidenced by the sexy negative lookahead above. So besides being faster (since we don't have to run things through the Lua layer), a pure .conf approach should be a lot more succinct as well.

One issue I'm running into is that there's no way (that I can find) to check a request's headers at the .conf file level, so we can't check to see if a browser supports gzip (which they specify by sending an "Accept-Encoding" header) so we can send it the Boost-compressed gzipped version of a requested page. However, I'm thinking this may not be a problem in most cases, because, unlike Apache, it's a fair assumption that, if a site is running on Lighty, the operator of that site has control over the server (isn't on shared hosting, in other words) and can therefore enable Lighty's mod_compress and handle the gzipping that way. In other words, we just send it the normal uncompressed version of the page, and let mod_compress do the gzipping.

The Boise Drupal Guy!

To follow up on this… There's

Posted by Garrett Albright on June 25, 2010 at 4:36pm

To follow up on this… There's a show-stopper in that there doesn't seem to be a way to check for the existence of multiple files successively using rewrite-if-not-file. I posted about it on the Lighty forum, but haven't received a response. We need to be able to do this to support Boost. So it looks like a pure .conf solution is out of the picture, at least for Boost fans.

I'm thinking of a re-implementation of this in both Lighty config file and Lua script form, instead of doing everything in Lua. The former gives us better regular expression support and speed (at least, I'm assuming that executing stuff in the config file is faster than firing up the Lua interpreter and executing stuff there… I'm hoping someone smarter than me will do some benchmarking of this at some point), while the latter gives us more control to do OS-level things like check for the existence of files - they each have unique strengths, and the best solution may be to take advantage of the strengths of each instead of just using Lua's strengths but suffering Lua's weaknesses.

The Boise Drupal Guy!

Experimenting more with

Posted by Garrett Albright on July 2, 2010 at 9:15pm

Experimenting more with url.rewrite-if-not-file…

It lets you conditionally rewrite, but it doesn't conditionally stop the Lua script from running; on the contrary, using it seems to cause the Lua script to run twice! Once with the pre-rewriting path data, and once with the rewritten data. So it looks like that if we're going to use the Lua script for some things - like, say, Boost support, for which I still see no good way to do at the conf level - then it's best to still do the rewriting in Lua as well.

The Boise Drupal Guy!

Only Serves from cache/perm, cache/normal isn't accessed.

Posted by ThetaJoin on June 25, 2010 at 3:18pm

Garret,

I've been debugging this issue for a couple of hours. My issue was like cybe's above - I'm only getting paths for files in cache/perm directory. I'm on lighttpd 1.4.19, Ubuntu 9.04. From what I can tell inserting print statements into your script is that this if statement is never entered:

if not bad_path == true and lighty.env['request.method'] == 'GET' and lighty.env['uri.scheme'] ~= 'https' and lighty.request['Cookie']:find('DRUPAL_UID', 1, true) == nil then

When I try to print lighty.env['request.method'], I get an error about the request.method being nil, so I removed that check, making the if statement look like this:

if not bad_path == true and lighty.env['uri.scheme'] ~= 'https' and lighty.request['Cookie']:find('DRUPAL_UID', 1, true) == nil then ...

This now works, serving html pages from cache/normal. I'm leaning towards a bug with lighttpd not providing request.method in Lua. I'm very new to Lua, so not exactly sure. Upgrading to the latest lighttpd would be an interesting test.

Hope this was helpful.

Mark Schoonover
http://www.thetajoin.com
High Performance Drupal Hosting & IT Services

Hmm. I wonder if it has to do

Posted by Garrett Albright on June 25, 2010 at 4:22pm

Hmm. I wonder if it has to do with your older version of Lighty… 1.4.19 is over two years old. Do you think you could try updating to the most recent version and try again with an unmodified version of the script? 1.4.26 is the most recent non-pre-release version.

cybe, Rockland, if you're still following this thread; what versions of Lighty are you guys using?

The Boise Drupal Guy!

I moved back to using Apache

Posted by cybe on June 25, 2010 at 6:36pm

I moved back to using Apache again, it does't seem like such a hog afterall.

Yes, I believe I was using 1.4.19

Ugh. And are you also using

Posted by Garrett Albright on June 25, 2010 at 7:31pm

Ugh. And are you also using Ubuntu?

This seems to indicate that only "lucid" has an up-to-date Lighty package available. Theta, it looks like Ubuntu 9.04 corresponds to "jaunty," for which 1.4.19 is indeed the most recent package available.

If upgrading Ubuntu is not an option, you should at least look into compiling Lighty from source or finding an updated package some other way. The upgrade path between 1.4.19 and 1.4.26 has included a handful of security updates…

The Boise Drupal Guy!

Debian Lenny...

Posted by cybe on June 25, 2010 at 7:41pm

Debian Lenny...

Ugh… same problem. Not very

Posted by Garrett Albright on June 25, 2010 at 8:38pm

Ugh… same problem. Not very reassuring that apparently the most recent version of Lighty is only available for branches of Debian labeled "testing" and "unstable." Good Going, Debian…

For the record, I'm using OS X 10.4 (at work) and 10.6 (at home) and FreeBSD 7.3 (on the server), for which ports of Lighty 1.4.26 are all available.

The Boise Drupal Guy!

Upgraded to Karmic/lighttpd 1.4.22

Posted by ThetaJoin on June 27, 2010 at 4:30am

Garret,

I upgraded the server to Karmic which included lighttpd 1.4.22. I dropped in your original script and all is working. So, there's something up with lighttpd 1.4.19. For now, Karmic is as far as I can go due to the problems Drupal has with PHP 5.3. With the combination of APC and Boost, I'm seeing almost 500% increase in performance.

I did find another issue with the script, which I'll post in a new comment.

Mark Schoonover
http://www.thetajoin.com
High Performance Drupal Hosting & IT Services

For what it's worth, as far

Posted by Garrett Albright on June 28, 2010 at 3:20pm

For what it's worth, as far as I've experienced, Drupal itself doesn't really have any problems with PHP 5.3… Particular contrib modules may have issues, though - and if they do, please lean on the maintainers hard to upgrade them already.

The Boise Drupal Guy!

Non-Drupal URLs

Posted by ThetaJoin on June 27, 2010 at 10:59pm

I couldn't post this to g.d.o because it was always getting flagged as spam. Tried rewording, different times, different browsers - no luck.

Here's the link: http://blog.thetajoin.com/content/non-drupal-uris-and-lighttpd-drupallua...

If anyone knows how to move the conversation back to g.d.o, that would be great. I'll remove it from my site.

Mark Schoonover
http://www.thetajoin.com
High Performance Drupal Hosting & IT Services

I simply don't include a copy

Posted by Garrett Albright on June 28, 2010 at 3:31pm

I simply don't include a copy of the script at the .conf level if a domain name hosting a non-Drupal site is being used.

$HTTP["host"] !~ "^(foo|bar|baz)" {
  magnet.attract-physical-path-to = ("/path/to/drupal.lua")
}

This says, "Only use the Lua script if the domain name doesn't begin with 'foo,' 'bar' or 'baz.'" This works well if you have more Drupal sites on your server than non-Drupal ones. If the inverse is true, you can go the other way around by switching the ~! in the script above with =~. It's a bit of a pain to have to maintain a list of sites which are or are not powered by Drupal, but it's fast, and it's a good solution if you aren't creating new sites very often.

EDIT: Also, this approach can be adapted if you have different versions of the Lua script you want to apply to different sites; perhaps you want Boost on for some of your Drupal sites, but not others.

The Boise Drupal Guy!

Helpful for Multi-Site

Posted by ThetaJoin on June 29, 2010 at 3:31am

Garrett,

I'll keep this in mind for sites I don't require boost - can have a boost=true version, boost=false version. Would it be possible to pass the script a parameter value?

The issue I've run into is with non-existing urls getting redirected from port 80 to 443 causing redirection loops. A concrete example would be the url http://domain.com/awstats. I need http://domain.com/awstats to get redirected to https://domain.com/awstats. The drupal.lua script causes all kinds of redirects to happen. That's why I've checked the uri.path and if true, simply returned from drupal.lua.

I know I could do it via http://awstats.domain.com with the slight addition of DNS configuration, but that's not going to scale very well.

Mark Schoonover
http://www.thetajoin.com
High Performance Drupal Hosting & IT Services

Would it be possible to pass

Posted by Garrett Albright on June 30, 2010 at 3:25pm

Would it be possible to pass the script a parameter value?

If you're thinking the way I think you're thinking, then no, not that I know of.

The Boise Drupal Guy!

Creating but not serving cached files

Posted by andrewsuth on July 31, 2010 at 8:14pm

Just to add some more spice to cached files not being served..

HTML page is always X-Boost-Path: miss in the header.
CSS and JS files have no reference to X-Boost-Path at all. (yes, caching for .css and .js is enabled in Boost)

I've got the following setup:
O/S: Ubuntu 10.04 LTS
Lighttpd: 1.4.26
Drupal: 6.17
Boost: 6.x-1.18

boost_on = true is set in the lua file.

The output from print(stats.physical) is:

2010-07-31 10:38:21: (mod_magnet.c.245) (lua-print) /var/www/drupal/cache/normal/example.com/.html.gz
2010-07-31 10:38:21: (mod_magnet.c.245) (lua-print) /var/www/drupal/cache/normal/example.com/.xml.gz
2010-07-31 10:38:21: (mod_magnet.c.245) (lua-print) /var/www/drupal/cache/normal/example.com/.json.gz
2010-07-31 10:38:21: (mod_magnet.c.245) (lua-print) /var/www/drupal/cache/normal/example.com/.html
2010-07-31 10:38:21: (mod_magnet.c.245) (lua-print) /var/www/drupal/cache/normal/example.com/.xml
2010-07-31 10:38:21: (mod_magnet.c.245) (lua-print) /var/www/drupal/cache/normal/example.com/.json

(There is an underscore before each of the file names (eg. _.html.gz)but it does not come out in the above example.. weird.)

print(lighty.env['request.method']) (as ThetaJoin mentioned above) is returning GET as expected.

Can you give me some advice as to where I should start the debugging?

Additional Debugging

Posted by ThetaJoin on July 31, 2010 at 9:29pm

I've not moved up to 10.04 myself, having settled on Ubuntu 9.10 which is using 1.4.22 and the lua script works. I haven't tested with 1.4.26 that comes with Ubuntu 10.04.

Another approach to debugging is to restart lighttpd using the -D option, then lightty will just send what's going on at the console. Other than sprinkling print statements throughout the lua file, it's the only other approach I know of to debug lua scripts under lightty.

HTH

Mark Schoonover
http://www.thetajoin.com
High Performance Drupal Hosting & IT Services

clean urls

Posted by karthick62 on December 28, 2010 at 9:04am

Hi,

I have started using drupal on lighttpd for the few days.. My directory set up goes like this .

1./document-root/site
2./document-root/site/subsite1
3./document-root/site/subsite2
I am able to get the clean urls for the above sites using lua scripts. I have no problem on accessing the pages using both apache and lighttpd (using lua scripts)

But I got another site,like

4./document-root/site/subsite3/subsite3.1

When I click the pages on the subsite3 and subsite3.1 I am getting page not found errors when I use lighttpd. but it works fine with apache2. I want to know that if we can access a subdiirectory inside a subdirectory using lighttpd?

Thanks in advance...

Can't Browse Site While Logged In With Clean URLs On

Posted by spflanze on May 13, 2011 at 2:29pm

When I have your LUA script in effect I am not able to browse the site with clean URLs on. I can get to the front page only. What appears in the URL field of the browser is:
http://www.example.com/index?destination=node%2F43080
This results in the display of a "404 - Not Found" error.

I have seen this problem before when I developed my lighttpd.conf file to work with clean URLs (without Boost). I had to do a work around in for it that I describe at: http://drupal.org/node/1085380.

There are others who have had this problem: http://drupal.org/node/243539, so I believe it to be a Drupal bug.

I need your LUA script to do the same work around.

This is solved. The LUA script was not being executed.

Posted by spflanze on May 15, 2011 at 1:29pm

This is solved. The LUA script was not being executed. The problem was in the lighttpd.conf file where I had:

$HTTP["host"] =~ "^(example.com)" {
  magnet.attract-physical-path-to = ("/etc/lighttpd/drupal.lua")
}

I was not getting matches because the URLs had the www subdomain. The solution was a regex expression of the form:

$HTTP["host"] =~ "^(((www|sub1|sub2).)?example.com)" {
  magnet.attract-physical-path-to = ("/etc/lighttpd/drupal.lua")
}

Where sub1 and sub2 are example subdomains. This says the URLs "example.com", "www.example.com", "sub1.example.com" and "sub2.example.com" will be processed by the LUA script. Anything else will not be.

The Ultimate LUA Script is capable of handling "destination=" for logged in users.

Script Additions I Needed

Posted by spflanze on June 26, 2011 at 12:51am

I have had two problems with the LUA script.
At login I there is this same problem I have had before using your script that I describe here:
http://drupal.org/node/1085380
Also, if the URL has no URI the page gets displayed without any themes.
I figure others should have had these same difficulties by now and so it appears only I have them. I can't figure why. To solve them I had to make these additions to your LUA script right under the Stop advisory:

-- ---- Stop! You should not need to edit anything else below this line. ---- --
-- Work around Drupal 6 clean URL login bug issue http://drupal.org/node/1085380:
if lighty.env['uri.query'] ~= nil and lighty.env['uri.query']:match('^destination=') then
  lighty.env['uri.query'] = 'q=' .. lighty.env['uri.path']:match('[^/]*$')
  lighty.env['uri.path'] = '/index.php'
-- If there is no uri.path the content is delivered without a theme:
elseif lighty.env['uri.path'] == '/' then
  lighty.env['uri.path'] = '/index.php'
  lighty.env['physical.path'] = lighty.env['physical.path'] .. 'index.php'
end

I have found this script only

Posted by spflanze on June 26, 2011 at 6:01pm

I have found this script only works for the home page.

Also I have found this problem of no them happens when Boost is enabled.

Clean URLs are also enabled.

Ultimate Lua Script - Discussion

Comments

Group organizers

New groups

Group notifications