* 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
