On Sat, Sep 06, 2003 at 12:15:44AM +0200, Andr? Malo wrote:
> * Glenn wrote:
>
> > 1) Why does includes "virtual" sometimes fail with
> > "unable to include potential exec \"%s\" in parsed file %s"
> > when Options IncludesNoEXEC is used? Why is this check performed?
> > What is the reasoning behind it?
>
> Not to execute anything, as the option name may imply ;-)
> Anything may be a command, a CGI script etc.
I meant to emphasize that I don't think that a "#include virtual" should
be peeking down into the subrequest. It is a bona fide (sub)request and
any "#include virtual" could also be requested directly; it is visible in
the url-space. But "include"ing it is broken if the file is, for example,
/cgi-bin/foo.php.
> > - if (!error_fmt && (ctx->flags & FLAG_NO_EXEC) &&
> > - rr->content_type &&
> > - (strncmp(rr->content_type, "text/", 5))) {
> > - error_fmt = "unable to include potential exec \"%s\" "
> > - "in parsed file %s";
> > - }
>
> Hmm. Removing an insufficient check doesn't look reasonable to me. We should
> rather improve it, shouldn't we?
Doesn't the subrequest already takes care of the permission issue?
If a direct request to /cgi-bin/foo.php will work, why shouldn't
"#include virtual"? The returned content should be included as-is
in all cases.
> > 5) Can mod_include please export get_include_var() as an optional function?
> > How about as ap_ssi_get_include_var()? This is needed by modules to
> > access the mod_include lazily-evaluated variables.
>
> Why isn't ap_ssi_parse_string sufficient?
I am working on a custom module to handle <!--#exec cmd="..."-->
and wish to do a reasonably proper (but limited) word expansion,
a la shell command language:
http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap02.html
For proper field splitting after variable expansion it is necessary to know
whether or not a variable is being expanded within a double-quoted string,
which can only be done before the variable is expanded and the quotes are
removed.
If get_include_var() is exported as an optional function, I do not need
to copy it into my own code with an extra hack to call ap_ssi_parse_string()
on a dummy string whenever I need to expand one of those lazily-evaluated
variables.
Since mod_include maintains some extra env variables, it makes sense to
me to create an interface for other modules to call back and retrieve
needed values. Extension modules to mod_include might need access to
the variables in situations other than string expansion.
Thanks!
Glenn
