httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn <>
Subject Re: server-side includes "virtual" and "exec" questions/patches
Date Fri, 05 Sep 2003 23:32:33 GMT
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,

> > -                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:
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

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

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.


View raw message