> On 29 Nov 2020, at 14:48, Florian Wagner <flor...@wagner-flo.net> wrote:
>
> Hi everyone!
>
> I was wondering if someone with a better understanding of httpd and
> mod_proxy could review my module idea and prototype implementation and
> warn me of any unforeseen pitfalls looming ahead before I commit to
> implementing this fully.
The main thing that springs to mind is security when you spawn a process.
CGI and fastcgi are battle-hardened by decades of operational use.
> Wanting to switch to mod_proxy_http for deploying backend applications
> (and opening the way for WebSockets through mod_proxy_wstunnel) I'm
> missing the process management provided by mod_fastcgi [1].
fastcgi is an unusual model, with a very specific purpose. It's more usual
for backends to be self-managing.
> While fully understanding that one can be of the opinion that process
> management is best kept out of httpd, I personally like the convenience
> and more importantly clarity offered by having the complete command,
> arguments and environment required to run the backend application in
> the httpd configuration. Authentication, URL rewriting and whatelse
> will already be setup there, anyway.
If it's in the config then at least it's [probably] coming from a trusted
source,
but then why run per-request?
> So I took a shot at seeing if I could implement a module to do just
> that. My current idea/prototype:
>
> 1. Register a hook to run before mod_proxy.c:proxy_handler and have a
> look at the request filename and handler to see if they start with
> "proxy:spawn://".
Big red flag for security there. Hope you're paying very careful attention
to your input: there's nothing to that effect in what you attached.
Also I'd consider hooking it earlier in the request cycle, or into mod_proxy
instead. How does mod_proxy_fcgi fit your vision?
--
Nick Kew
