httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul J. Reder" <>
Subject Question about moving cgi code out of mod_include.
Date Mon, 18 Dec 2000 20:35:37 GMT

In looking at the cgi code in mod_include I have several alternatives.
Ordinarily I would expect an external module to register an ssi directive
handler with mod_include for a specific directive. In this case that
would be "exec". Exec however handles both "cgi"s and system shell "cmd"s.
Cgis are handled by creating a subrequest to process the specified 
script value via the cgi(d) module. The shell command is handled by passing
the pipe from locally called apr_create_process as a pipe bucket. Cmds will
work whether mod_cgi(d) is installed or not. Cgis will only work if
mod_cgi(d) is installed.

If I move the handle_exec code to mod_cgi(d) then both cgi and cmd processing
must move. Now both cmds and cgis require mod_cgi(d) to work. Also, this requires
that I either externalize the get_tag_and_value and parse_string code or duplicate
this function in mod_cgi(d). I would be inclined to externalize them.

The alternative to moving the handle_exec code would be to leave the handle
exec code in mod_include and move the include_cgi (and include_cmd?) function(s)
to mod_cgi(d). This is not what the registered handler work was all about. This
would require that the "exec cgi" be handled differently than the "exec cmd" and
would require that mod_cgi(d) externalize a function that mod_include could call
directly (yuck!).

So it seems that I either move handle_exec (and both "cmd" and cgi" processing)
or I move none of it. Any alternatives to externalizing get_tag_and_value and
parse_string? I suppose I could move them to a commonly linked library somewhere.

Thoughts? Ideas?


Paul J. Reder
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein

View raw message