modules.conf order unhelpful (setenv vs. redirect)
When implementing HSTS headers, I found that setenv.add-response-header was ineffective for URLs which match url.redirect and are therefore answered with a 301 response. This is typical in a setup when example.com is redirected to www.example.com (best practice), and delivering HSTS for the domain while redirecting to www is an important step in establishing HSTS effectiveness.
Some research lead me to https://redmine.lighttpd.net/issues/1895 which pointed out that the order of modules in server.modules (in modules.conf) is decisive on whether this will work. And indeed, raising mod_setenv to the top position in the server.modules list made it work.
Unfortunately the modules.conf provided in the last 8 years or so (later than bug 1895 which would indicate that at the time the order was more helpful, I was unable to pinpoint it in the source history as modules.conf seems to have been introduced afterwards) has the modules ordered alphabetically, resulting in this lack of functionality when an admin only uncomments the modules as needed.
So I suggest that the order of modules in doc/config/modules.conf is changed to raise mod_setenv near the top (maybe there are other dependencies also which I didn't run into), to make it easier for users to get things right.
Perhaps other positions in the documentation should also stress this dependency.
(of course this helps very little for existing installations, as people tend to keep the existing config files during updates, and removing the dependency on server.modules order would do people a much bigger favour, but I assume this is a consequence of the modules architecture and cannot be changed easily. But it is certainly better to have good example configs from now on.)
My version in use is 1.4.53.
- Tracker changed from Bug to Feature
Thank you for your suggestion. Your suggestion may help improve the documentation. However, this is not a bug. It would be a bug if an incorrect statement was made, and which would then need to be fixed. #1895 was marked invalid for the same reason. Instead, you have suggested an improvement.
Also available in: Atom