httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Malo ...@perlig.de>
Subject Re: server-side includes "virtual" and "exec" questions/patches
Date Fri, 05 Sep 2003 22:15:44 GMT
* 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.

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

> The documentation for IncludeNoEXEC (with the Options directive) states:
>   IncludesNOEXEC
>     Server-side includes are permitted, but the #exec command and
>     #exec CGI are disabled. It is still possible to #include virtual
>     CGI scripts from ScriptAliase'd directories.

Yes. The docs describe the *real* behaviour of the code, not the *desired*
behaviour (Fixed a while ago).

> Can this be backported to 2.0 and 1.3?

No way. It would not be backwards compatible, besides the (so called)
"freezed" status.

> 2) Should <!--#exec cgi="..."--> be officially deprecated?

+1 from here. Other opinions?

>    Is there any reason "#exec cgi" should remain in Apache 2.1?  If people
>    support removing it, I'll whip up a quick patch to mod_cgi/mod_cgid.
>    Backwards compatibility is one thing, but this is cruft.  Current
>    documentation says:
>      "The include virtual element should be used in preference to exec cgi"
>    but does not go so far as to deprecate it, indicating that it might be
>    removed in the future.

I'd deprecate it in 2.1 and remove it in 2.3. This seems more gentle to me.

> 3) Apache2 mod_include performs lazy evaluation of a few environment
>    variables: DATE_GMT, DATE_LOCAL, LAST_MODIFIED, and USER_NAME
>    These variables end up being empty strings ("") in a CGI environment
>    unless they are used in the include document prior to the virtual or
>    exec include, e.g. the noop
>      <!--#if expr="$DATE_LOCAL"--><!--#endif-->
>    Can this be documented somewhere?  What pages should be updated?
>    mod_include documentation, the SSI tutorial, others?

Hrm. In fact this is IMHO a general design flaw of mod_include. We should not
mix include variables with the normal environment at all. If we once decide
to fix this, these variables would completely disappear for external
programs. Opinions?

> 4) Minor nit.  Should USER_NAME be inherited from the base document, just
>    as the LAST_MODIFIED time is done?  If USER_NAME was generated from the
>    lazy value before a sub-include, then it is inherited.  If it was not
>    generated before a sub-include, then it will be set with the value of
>    the document when it is actually used, leading to inconsistencies.

ehm... yes?

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

nd

Mime
View raw message