Bug #3150


Lua keeps adding http header over requests

Added by flynn 9 months ago. Updated 9 months ago.

Target version:


I use lua to to add sometimes (!) Location header and a return code 302.

But now I get the following behaviour:
  • after a fresh start of lighttpd everything is ok
  • most reuqests do no get a Location header added
  • after the first adding of a Location header lighty.header["Location"] = ... all following requests add the same Location header too
  • this results in return 200 with wrong/unwanted Location header, which is maybe misinterpreted by some clients

Is really all request-data resetted in Lua after the request?

Lua-script is activated via magnet.attract-physical-path-to = ...

I cannot say if this new with lighttpd version 1.4.64 or was present in erlier versions, It was detected by a (misbehaving) client, which now downloads both urls: the original and the one in the Location header

Actions #1

Updated by flynn 9 months ago

For debugging I added


at the beginning of the script.

It shows: after a fresh start it is null, but if the header is set once it remains for all following requests.

Actions #2

Updated by gstrauss 9 months ago

  • Status changed from New to Fixed

Unfortunately, this is a regression since lighttpd 1.4.60.
I had discovered this, too, and it is fixed on lighttpd git master branch.

Actions #3

Updated by flynn 9 months ago

Is it possible to create an optional deprecation warning for lua scripts, if the old/legacy tables are used?

Actions #4

Updated by gstrauss 9 months ago

This bug was introduced by me trying to optimize for the newer interfaces added in lighttpd 1.4.60. There is no fault in using the older interfaces.

There are no current plans to remove the older interfaces, and keeping them costs a handful of extra CPU instructions per request.

I do not get much feedback on lua use and I do not have much information about who is using mod_magnet or how.

Is it possible to create an optional deprecation warning for lua scripts, if the old/legacy tables are used?

I could add some trace upon script load if a simple strstr() returns a match, but do you think it necessary? What would you like to see? Advertise the newer interfaces?

Actions #5

Updated by flynn 9 months ago

I'm a heavy user of the mod_magnet and I already used the features of the new interface, e.g. writing to req_attr["uri.authority"].

If there is no plan to remove older interfaces there is no need for a deprecation warning.

Actions #6

Updated by gstrauss 9 months ago

That is nice to hear. :)

The new interface makes changes immediately to the underlying request state. The old interface save changes in an intermediate table and applies those changes when the script exits. Using both old and new interfaces can lead to surprises for the script writer, which is why I would like to discourage future use of the old interfaces.

The new interface is more efficient and does not modify the lighty lua table. The old interface modifies the lighty table. Therefore, lighttpd mod_magnet needs to spend some cycles checking if the lighty table was modified and cleaning up the lighty table before reusing the lighty table for the next script run.

You can quickly check if your scripts are using the old interfaces (which modify the lighty table) by grep for lighty.header or lighty.content. That is a good heuristic and catches typical use, though it will not catch if the script writer assigned the lighty table to an intermediate before accessing the header or content tables.


Also available in: Atom