[PATCH] HTTP: include SSI header only where it's needed
Maxim Dounin
mdounin at mdounin.ru
Tue Oct 27 02:34:42 UTC 2015
Hello!
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
http://nginx.org/
More information about the nginx-devel
mailing list