[PATCH] HTTP: include SSI header only where it's needed

Maxim Dounin mdounin at mdounin.ru
Tue Oct 27 02:34:42 UTC 2015


On Mon, Oct 26, 2015 at 02:46:33PM -0700, Piotr Sikora wrote:

> Hey Maxim,
> > I don't think this change is needed.  Current approach is in line
> > with what's done for other headers, and I see no serious enough
> > reasons to change things.
> Except that other headers (i.e. cache, ssl, v2) need to be included in
> "core" http, because the functions they expose are used in "core"
> http, whereas SSI is not. Basically, cache, ssl & v2 are all
> compile-time options of the "core" http, whereas SSI is just an http
> module and pulling SSI header in "core" http breaks layering &
> separation of the modules.

The SSI module is expected to be available for other modules to 
allow them to add their own SSI commands (like the perl module does).  
I don't see how making it available "breaks layering & separation 
of the modules".

The question is only how you'll make it availble - either 
automatically as of now, or via additional #include when needed.

> This doesn't really matter if you compile nginx as a big monolith, but
> if you want to go DSO route or build modules separately from "core"
> http, then "core" http (i.e. ngx_http.h) shouldn't be pulling headers
> from non-"core" http modules.

There are no plans to build all modules separately from core 
http.  Rather, we are working on to allow building _some_ modules 
separately.  And this mostly applies to modules with external 
dependencies (like perl, xslt, geoip) and 3rd party modules.

And as perl depends on SSI, I don't think it will be possible to 
load SSI dynamically without significant changes to SSI's interface.

Maxim Dounin

More information about the nginx-devel mailing list