At the heart of each webserver is the configuration file. It controls the whole behaviour and therefore has to be mighty but at the same time easy enough to get the desired results without hassle. In the lighttpd config you control how it reacts on requests. To achieve this you have to express some kind of logic - just like in a programming language.
1, "b" => 10 ]@ As with normal lists the final value can have a trailing @,@ too. You cannot mix simple values and key-value associations in one list (nesting them works). The @key => value@ operator is also only syntactic sugar for a @[key, value]@ list, the above example is the same as: * @[ [a, 1], [b, 10] ]@ This especially means that key-value lists are ordered too, although they can get converted to hash tables in certain function calls internally. ]]>
{ log "hello world"; if req.path =$ ".hidden" { static; } } The complete config is an action block too (but without the surrounding curly braces); conditionals also use action blocks for their branches. Each action block that is not a condition branch starts a new nested variable scope; ]]>
my_types = [".txt" => "text/html"]; php = { if phys.path =$ ".php" { fastcgi "unix:/var/run/lighttpd/php.sock"; } }; By default variables assignment overwrites an existing variable (in its previous scope) or, if it doesn't exist, creates a new one in the local scope (i.e. it will only be available in the current scope and nested descendants). You can explicitly create a new variable in the local scope (hiding variables in parent scopes with the same name) by prefixing the assignment with @local@:
				local wwwpath = "/var/www/example.com";
				
You can also create variables in the global scope by prefixing the assignment with @global@. The main config already is in a nested scope (i.e. *not* the global scope). The global scope is not destroyed after config loading, and can be used in delayed config loading (say from SQL in the future). If a variable name is used in a context it will always use the definition from the nearest scope. ]]>
This example illustrates that variables are evaluated while parsing the config. foo = "bar"; if req.path == "/somepath" { foo = "baz"; } # at this point foo will ALWAYS contain "baz" no matter if "/somepath" was requested or not This example illustrates scoping. foo = "bar"; php = { local foo = "baz"; # in this block (and nested blocks within) foo is now "baz" # ... }; # foo is now "bar" again
if req.host == "mydomain.tld" { if req.path == "/" or req.path == "/index.html" { static; } else if req.path == "/upload" { if req.content_length > 100mbyte { access.deny; } else { proxy "127.0.0.1:8080"; } } }
{ ... }@ * @if { ... } else { ... }@ * @if { ... } else if { ... }@ * @if { ... } else if { ... } ...@ (continue with @else@ or @else if@) A condition expression @@ is: * @()@ * @ and @ * @ or @ (@ and or @ = @( and ) or @; @and@ has higher precedence) * @ @ for @@ being a condition variable (with a type different from boolean), @@ an condition operator and @@ a string or a number. * @@ or @!@ for a boolean condition variable. ]]>
== | compares two values on equality | != | negative == | | <= | less than or equal | < | less than | | >= | greater than or equal | > | greater than | | =~ | regular expression match | !~ | negative =~ | | =^ | prefix match | !^ | negative =^ | | =$ | suffix match | !$ | negative =$ | | =/ | cidr match | !/ | negative =/ | ]]>