Lighttpd

I know, that this can be achieved with mod_magnet and a lua script, but on a backend with thousands of requests the proposed solution is much more efficient.

mod_magnet with lua can be very, very fast, e.g. mod_magnet is faster serving a small static response than using mod_staticfile to serve a small file. In any case, both are very, very fast and the difference is measurable in microbenchmarks, but not noticeable in real-world use.

I think that you're right that a specialized directive will be slightly faster than mod_magnet in microbenchmarks, but I am not sure it will be noticeably faster in practice (... yes, base memory use will be a bit higher with lua). Still, let's test that. You can hard-code a response code in mod_access.c and compare performance to mod_magnet and a lua script. I'll test performance of a url.deny-status this weekend.

The naming url.deny-status might be confused as applying to more than just mod_access, so that is another consideration.

https://www.rfc-editor.org/rfc/rfc9110#name-405-method-not-allowed

15.5.6. 405 Method Not Allowed

The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target > resource. The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.

According to the RFC quoted above, 405 Method Not Allowed also requires response header Allow. While that might be achieved with additional config using mod_setenv, this is another reason against your proposed feature for a new url.deny-status config option. lighttpd aims to be compliant with HTTP and related RFCs, and as currently described, this new config directive seems too narrowly focused. It is likely to be misused without also setting the "Allow" response header.

I do understand that there is a barrier to entry of learning some lua in order to use mod_magnet. That is why I have tried to provide many examples in ModMagnetExamples and in AbsoLUAtion.

Also, the overhead of using lua is amortized if you have more than one conditional in the lua script which is handled per-request. Using a lua script with mod_magnet might actually be faster than a complex set of regular expressions in lighttpd config syntax.

The following lua script (quickly written; untested) might be just as fast as using a regular expression in your $HTTP["request-method"] !~ "^(GET|HEAD)" { url.access-deny = ("") }

local r = lighty.r

local method = r.req_attr["request.method"]
if (method ~= "GET" and method ~= "HEAD" and method ~= "POST") then
    r.resp_header["Allow"] = "GET, HEAD, POST" 
    r.resp_header["Content-Type"] = "text/plain" 
    r.resp_body:set("405 Method Not Allowed")
    return 405
end

-- (could add additional request conditions here)

return 0

Aside: for those looking to implement application level firewalls, mod_magnet can be much faster than using libmodsecurity. However, you have to write your own policy.

For those looking to use libmodsecurity and libmodsecurity policies:

You can use libmodsecurity from mod_magnet if you think it can help protect your site, but using libmodsecurity has a large CPU and memory cost and reduces performance. AbsoLUAtion mod_security

Another libmodsecurity option: I have an experimental branch "mod_security3" in my github gstrauss/lighttpd1.4 repo, with the commit message

    [mod_security3] new module using libmodsecurity

    (experimental)

    ./configure --with-libmodsecurity

    Note: libmodsecurity has a humongous list of dependencies

    libmodsecurity is not near the performance level of lighttpd,
    but that is also not the goal of libmodsecurity.  Using mod_security3
    will result in higher memory use, higher CPU use, and slower responses
    compared to using lighttpd without mod_security3.

• small file: 73.2k req/sec
• small file with url.access-deny: 71.1k req/sec
• small file with lua-script: 63.4k req/sec
• small file with lua-script (luajit): 66.5k req/sec
  (lighttpd does not build without patching with luajit, but this would be another issue ...)

To be fair: my SCGI-backend can only deliver up to 8k req/sec on the same hardware, so in real world use this NOT an issue.

So my assumption much more efficient is not true, ticket can be closed.

Hah! The original lua script I posted, which checks the method string in lua rather than using lighttpd conditions, is slightly faster (290k+ req/s) in the microbenchmark.

I (erroneously) wrote:

FYI: luajit is based on Lua 5.1. Using Lua 5.4 is generally recommended unless you are doing something very specific and have tested and measured that using luajit is substantially faster. [Edit: apparently this is incorrect; see post below]

https://github.com/LuaJIT/LuaJIT/issues/929 (comment by author of LuaJIT) suggests LuaJIT is more popular and more stable.

@flynn did you need any modifications besides something like the following to build with LuaJIT? This appears to work for me (along with build system detection modifications)

--- a/src/mod_magnet.c
+++ b/src/mod_magnet.c
@@ -202,6 +202,12 @@ SETDEFAULTS_FUNC(mod_magnet_set_defaults) {
 #endif

 #if !defined(LUA_VERSION_NUM) || LUA_VERSION_NUM < 502
+#ifdef __has_include
+#if __has_include(<luajit.h>)
+#include <luajit.h>
+#endif
+#endif
+#if !defined(LUAJIT_VERSION_NUM) || LUAJIT_VERSION_NUM < 20005
 static lua_Integer
 lua_tointegerx (lua_State * const L, int idx, int *isnum)
 {
@@ -211,6 +217,7 @@ lua_tointegerx (lua_State * const L, int idx, int *isnum)
     return *isnum ? lua_tointeger(L, idx) : 0;
 }
 #endif
+#endif

 #if !defined(LUA_VERSION_NUM) || LUA_VERSION_NUM < 502
 /* lua5.1 backward compat definition */

• src/mod_magnet.c
• configure.ac

In your latest checkins you set lua_min_ver=0 in the LuaJIT case, this should be lua_min_ver=2.1 to get the current LuaJIT release.

In your latest checkins you set lua_min_ver=0 in the LuaJIT case, this should be lua_min_ver=2.1 to get the current LuaJIT release.

LuaJIT is based on Lua 5.1 and I handle whether or not LuaJIT 2.0.5 or later is used (which provides lua_integerx()), or else provide lua_integerx() myself. That's why lua_min_ver=0 (disabling the version check) is fine when ./configure --with_lua=luajit is specified.