Taking a Peek at mod_lua

By | August 9, 2013

Back in February of last year (2012), the Apache project announced the release of Apache HTTP Server 2.4, the first major release of the project in over six years. In the computer world, that may well as have been a century — even Debian, known for its rock stable releases and famously slow (and careful) release cycles managed to get a full three releases made in that interval.

Of course, it does make sense. Apache is server software — it needs to be absolutely stable before release or risk security breaches in the millions of servers that run it. The consequence of any vulnerability is dire. Furthermore, beyond speed and memory improvements,  it doesn’t really need any new features. At least I couldn’t think of anything. So, when 2.4 finally released, I went over to the Apache website to see what new features they could have possibly added.

I should probably point out that I’m not expert in web server management. I understand Apache to the point where I can make it run and maybe load a module or two that I need and not much more. As a result, I pretty much scrolled through that list of new features clueless as to what all of it meant — until I noticed mod_lua on the list of new modules to be introduced. Well, actually, to be honest, I still didn’t have a clue what it meant — I knew what Lua was and had been using it with CGI and the Kepler framework for over a year by that point, so I wasn’t quite sure what the difference was. I knew PHP could be run with both CGI and mod_php as well, but I never figured out what the difference was besides not being able to change PHP settings in .htaccess files when under CGI. I figured it would make no difference and just left it at that.

Now, over a year later, I’m revisiting mod_lua and Apache 2.4 after deciding to migrate my web development platform to my hard-earned installation of Debian.

Actually, the whole process of installing Apache 2.4 itself was surprisingly easy. It was a matter of executing sudo apt-get install apache2 and waiting for the installation to complete. I was originally just planning to install PHP which I did with sudo apt-get install php5 libapache2-mod-php5 and enabled it with sudo a2enmod php5 as per the instructions. However, enabling the PHP module gave me the idea to enable and test out mod_lua as well, so right afterward, I ran sudo a2enmod lua followed with a restart of Apache: sudo service apache2 restart. I then wrote up a simple Lua script index.lua to print “hello world” and moved it into /var/www which is set as the server index. To my disappointment, when I tried to load http://localhost/index.lua, instead of a nice page saying “hello world,” the Apache just spit out the raw Lua code without doing anything at all. Time to check the manual…

As it turns out, I needed to tell Apache that .lua files are “lua-scripts” which, for some reason, the module doesn’t do by default. I went into /etc/apache2/mods-enabled and added AddHandler lua-script .lua” to the end of lua.load and restarted Apache again. I tried again at loading index.lua and encountered a 500 error which generally indicates an error in the code. Running the code directly from Lua shows no errors though. Hm…

After a closer reading, I found that mod_lua scripts aren’t structured like normal Lua CGI-scripts. In CGI, I would write:

print "Content-type: text/html\n"
print "Hello world!"

and a page would appear with “Hello world!” written on it. With mod_lua, the action happens in a callback function. From what I can understand, Lua isn’t running my code directly; Lua is running mod_lua which happens to require() my code and then calls a function named handle() which it expects my code to have. As a result, the code above must be broken because the mod_lua calls handle() which doesn’t exist and therefore Lua generates an error causing the 500 error.

With that all settled, I modified the code to conform to the new format. The program above now becomes:

function handle(r)
    r.content_type = "text/html"
    r:puts("Hello world!")
    return apache2.OK
end

It sure feels more abstraction than before; not quite so much as PHP, but there’s definitely less of the do-everything-yourself tone present in plain CGI — sort of like what Kapler does. Indeed, there’s a significant degree of overlap between what the two projects do.

Both have features to parse arguments, encode URLs, build hashes and even connect to various database systems (note that additional packages, like libaprutil1-dbd-mysql are needed for database connections). Naturally though, mod_lua is much better integrated with Apache, also being able to directly retrieve a list of loaded modules, manipulate Apache’s .htpasswd files, write log messages among other things on its long and impressive list of features.

With its superior performance compared to PHP and Python, Lua holds a lot of potential in the field of web development with the advent of mod_lua, Will it grow and become the new PHP or Python of tomorrow’s web? I think it just might.

Leave a Reply

Your email address will not be published. Required fields are marked *