On 11/29/2013 12:12 PM, Nick Kew wrote:
There is the modules-dev list.
I tried there first but got no response and it seems like a very low volume
list with very few participants.
I guess you're asking how to manage a resource that'll
outlive Requests and (client) Connections?
That is correct good sir.
Take a look at apr_reslist. It may be even better than you'd hoped.
I shall do so after typing this message.
Indeed, your thought process looks not unlike
http://conferences.oreillynet.com/presentations/euos2006/kew_nick.pdf
Actually, not so much. In fact I want to do exactly one of the things that
paper is trying to avoid: I *want* a 1:1 mapping between workers and the
FastCGI application. What I am trying to avoid is the overhead of doing a
connect() -> send() -> shutdown() on every request. Rather for the lifetime
of the thread / process I want a persistent connection between that
thread/process and the external FastCGI application. The FastCGI spec does
allow for multiplexing streams, but that is poorly supported out there.
php-fpm doesn't support it for example, and as far as I can tell neither
does the FastCGI "reference" library from fastcgi.com. If this multiplexing
was better supported then the N:1 connection described in that paper would
be more feasible.
and mod_proxy_fcgi relies on the proxy framework, which has security
implications according to Apache's own docs, and it doesn't provide any AAA
capabilities.
Erm, what do you mean?
The FastCGI spec provides for 3 roles: responder (i.e content production),
authenticator and filter. mod_proxy_fcgi only supports the first of those
three. If I wanted the FastCGI application to do authz / authn I can't use
mod_proxy_fcgi. mod_fcgid sort of supports these roles but not by hooking
into the standard AAA framework. Rather it provides its own directives
which mimic that behaviour (mostly). My module (called mod_extfcgi btw)
allows you to do things like:
AuthBasicProvider extfcgi
AuthExtfcgiServer localhost:9000
Here AuthExtfcgiServer is the moral equivalent of AuthUserFile.
And you can:
Require extfcgi otherhost:1234
for doing authz.
You mean a fastcgi-based alternative to mod_ext_filter? Sounds like
a worthwhile addition!
Yup its exactly like that.
I started this journey of writing this module mostly for this reason, as
well as wanting something that implemented as much of FastCGI as possible
without being burdened down by also being a process manager. That way you
are not tied to a given process manager implementation. mod_proxy_fcgi
gives you that, but misses out on the authenticator and filter roles, and
carries with it the extra "burden" of needing mod_proxy, which I do not
even want to compile into my server (I compile the modules statically).
Thank you for the response, and an especially big thank you for your book,
which has been an invaluable resource. I am going to go read up about
apr_reslist now.
Sincerely,
Kean
