Impossible to loop through the lighty.request or lighty.env fields
|Missing in 1.5.x:||No|
In order to log all request headers or matching their names against a given pattern (i.e. proxy), it should be possible to traverse the lighty.request and lighty.env tables.
The following debug code however only processes what seems to be empty tables. Requesting a field directly, returns the value as exptected (see last line of output):
print('--------- BEGIN OF DUMP -----------') -- loop through main "lighty" table and output its -- type and contents (including subtables) for key,val in pairs(lighty) do if type(val) == 'table' then print('TABLE: ' .. key .. '(Length: ' .. #val .. ')') -- loop through sub-table of "lighty" for key2,val2 in pairs(val) do if val2 == nil then print(' - ' .. key2 .. ': (NULL)') else print(' - ' .. key2 .. ': ' .. val2) end end -- end of subtable elseif type(val) == 'string' then if val == nil then print ('STRING: ' .. key .. ': (NULL)') else print ('STRING: ' .. key .. ': ' .. val) end else print ('ISTYPE: ' .. key .. ': ' .. type(val)) end end print('--------- END OF DUMP -------------') print(lighty.request['User-Agent'])
GET / HTTP/1.1 Host: localhost User-Agent: This is my User-Agent Connection: close
--------- BEGIN OF DUMP ----------- ISTYPE: RESTART_REQUEST: number TABLE: header(Length: 0) ISTYPE: stat: function TABLE: request(Length: 0) TABLE: env(Length: 0) TABLE: content(Length: 0) TABLE: status(Length: 0) --------- END OF DUMP ------------- This is my User-Agent
Tested on 1.4.16 (Linux x86_64).
#1 Updated by Anonymous over 6 years ago
The attached patch against 1.4.19 defines the lighty.request.fields() function, which can be used as iterator in a generic for loop.
State data is passed through an additional C struct.
for field in lighty.request.fields() do print(field .. ': ' .. lighty.request[field]) end
#2 Updated by norganna over 6 years ago
The patch "lighttpd-1.4.19-iterablemagnet.patch" is one that I wrote to enable us to iterate over the lighty variables using the pairs() function. It incorporates some modifications to the lua pairs() function inspired by the following article: http://lua-users.org/wiki/GeneralizedPairsAndIpairs
The changes imposed are basically the addition of an __pairs metatable entry which returns an iterator for the associated object.
We then go on to add pairs metafunctions to the lighty objects.
Additionally, this patch adds in the request.method and request.protocol entries to the lighty.env table, which were documented as being present, but not functioning.
I also added a request.remote-ip entry to the lighty.env table, since I couldn't seem to find it elsewhere. (Basically I wrote the iteration code to make sure it wasn't hiding somewhere obvious)
I've also added a function lighty.acl(source, destination, netmask) which takes as parameters an IPv4 address in string dotted quad, or numerical equivalent, a destination network in string dotted quad, or numerical equivalent and optionally a netmask in string dotted quad, or numerical equivalent or string CIDR size.
It subsequently returns result, source_numerical, destination_numerical, netmask_numerical.
Result is true if source is in destination+netmask, or false if it is outside.
the additional *_numerical items returned on the stack are the numerical equivalents to the input variables. This is to speed up execution of processing many thousands of ACL entries since you don't need to reinterpret the IP addresses every time (we currently are using this to block botnets from our servers and have in excess of 100000 IP addresses that are being blocked. Traditional ACL blocking (in-config) does not help us as we need live blocking/unblocking.
While this functionality is not anything to do with the current bug, I included it in the patch on the off-chance that someone else finds it useful / worthy of inclusion. Also I would have had to extract it from the patch otherwise.
Also available in: Atom