Lighttpd

Please make the 25 limit a configuration option, or use a different loop detection method. It's perfectly valid/safe to have one file which includes more than 25 ssi include statements. With this patch that is not possible.

-- rob

The last patch included is against latest trunk (1.5.0). VERY EASY to apply against trunk.

-- marc

I just installed the Windows version of lighttpd, LightTPD-1.4.16-Win32-NoSSL.exe (the ssl version didn't install, but that's another story). I downloaded it from http://wlmp.dtech.hu/. BTW, Why can't I find the windows version on the lighttpd site?

Anyways, SSI doesn't recurse. It runs the include in the top level page, but doesn't process the SSI in the included pages. I know it's not a screw up in my SSI code because the site works fine on other servers, and I know it's not a config issue, because it does process the first page (unless there is some max-recurse setting? but I couldn't find one).

here's my version info:
brian@brian-PC /cygdrive/c/LightTPD
$ ./LightTPD.exe -v
LightTPD-1.4.16 (Win32)
A fast, secure and flexible webserver...

This version is built for WLMP Project - http://wlmp.dtech.hu/
Build-Date: Jul 27 2007 10:32:13

Maybe I should be talking to the WLMP people instead of posting here? It seems that I've got a version that should have this bug fixed though.

The (P.O.S.) operating system is Windows Vista if it matters.

Oh!, and I just remembered, I also installed the cygwin version (through the cygwin installer, but have since uninstalled it), ... It was version 1.4.16-1. SSI didn't recurse using that cygwin version either, so it's not just some problem with that WLMP auto-installing executable version.

Thanks,

-brian

-- nairbv

there is a 3rd party patch which hasnt be included so far.
that said the issue is still open.

The patch added 2007-05-11 19:34:07 "recursive SSI for 1.4.15 (minus whitespace garbage from previous patch)" inadvertently removed this line:

URIHANDLER_FUNC(mod_ssi_physical_path);

from around line 294, which causes it to fail to compile.

-- C Snover

This really needs to be implemented! Not even 1.5.0-svn2282 has it.

A problem that arises from this actually makes SSI useless! Because you can not include another SSI file that uses variables you defined previously or split web page design into multiple layers of smaller building blocks. (Not everyone uses PHP for simple file inclusions, because it's overhead.)

In Apache the currently implemented behavior is for ``. To follow I think the patch is missing an if statement (to only use this nested includes if using virtual).

-- gw.lighttpd

My previous patch is only a version of previous ones made to compile in 1.5.0-svn r2299, but it has a problem with SSI variables (they get reset) and as rob said 2 years ago it doesn't limit the depth of recursion (what would one expect from its name).

Therefore I made a new patch that implements the limitation of recursion depth correctly and also doesn't reset some structures at each include. It is avalible from: http://gw.tnode.com/0036-LighttpdDevelopment/Files-Patches/

But beware that this patch implements recursive SSI include virtual directives, but it doesn't limit the number of include directives per request. This means that someone who can create new pages can create a DoS page just by putting millions of include statements in it and freezing Lighttpd while it processes them (theoretically also possible with other instructions). This attack is also possible in the original mod_ssi implementation (so don't blame me)! It could be prevented by introducing a ssi.max_statements option that would count how many SSI statements were processed during a request and stop processing new ones when limit is hit. This issue should go in another ticket.

-- gw.lighttpd

kjikaqawej wrote:

These patches don't compile at all with 1.4.22. Seems mod_ssi_physical_path changed type, or should get an explicit cast:

mod_ssi.c: In function ‘process_ssi_stmt’:
mod_ssi.c:610: warning: implicit declaration of function ‘mod_ssi_physical_path’
mod_ssi.c: At top level:
mod_ssi.c:1132: error: conflicting types for ‘mod_ssi_physical_path’
mod_ssi.c:610: error: previous implicit declaration of ‘mod_ssi_physical_path’ was here
make³: * [mod_ssi.lo] Error 1
make³: Leaving directory `lighttpd/lighttpd-1.4.x-build/src'
make<sup>2</sup>: [all] Error 2
make<sup>2</sup>: Leaving directory `lighttpd/lighttpd-1.4.x-build/src'
make¹: ** [all-recursive] Error 1
make¹: Leaving directory `lighttpd/lighttpd-1.4.x-build'

This is with "mod_ssi_recursion-1.4.15.2.patch"

Well in the if statement, it gets used as an boolean (TRUE/FALSE) but it's declared (is that the right terminology?) as something else... obviously I don't have much clue, but I do know it doesn't compile ;).

I've also tried the other patches, they all bomb out on my source tree - r2410 from the 1.4 branch - in more or less the same way. The other ways it bombs out is in addition to the error noted above, the compiler complains of redefinition of mod_ssi_physical_path, or other issues.

I changed that mod_ssi_physical_path to the 'tmp' defined above, and it compiles, but absolutely no SSI processing gets done.

This patch Fails To Build. It's not resolved, though I'm going to try something.

kjikaqawej wrote:

This patch Fails To Build. It's not resolved, though I'm going to try something.

Finally builds, was a bug in patching, due to having to port it forward, and some other issues.

It works, that's the good news, but there are some issues still, like disallowing "../foo.shtml", and not parsing .html included from the requested file (but IIRC apache also did that latter).

I don't have a patch yet, because a) I'm still testing b) it's changed a bit since, and I'm trying to get to do exactly what I want ;).

Thank you, BTW, to the people putting this up, for their work.

Instead of using con->loops_per_request, it would be clearer if a new member 'include_depth' were added to mod_ssi.h plugin_data and the count stored there.

It might be useful to set an inclusion limit on max num files included, rather than a recursion limit. Such a max num included files limit would limit total num files included and that would impose a max recursion limit as well.

Should con->uri.path be updated, too, for each processed 'virtual' inclusion?
Should DOCUMENT_NAME and DOCUMENT_URI change for each processed 'virtual' inclusion?
(I'm not saying they should or shouldn't be, but asking for the answer to be specified)

@eworm: are you still interested in this patch? I'm willing to help get this patch ready.