httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: Options & SSIs
Date Mon, 10 Nov 1997 00:13:44 GMT
On Sun, 9 Nov 1997, Rodent of Unusual Size wrote:

> >From the fingers of Marc Slemko flowed the following:
> >
> >On Sun, 9 Nov 1997, Rodent of Unusual Size wrote:
> >
> >>     I still don't like "IncludesNoExec" as an option keyword (or
> >>     functionality, for that matter); it's like saying, "This vehicle has
> >>     the following options: wheels, brakes, no airbag, windows, ..."
> >
> >No.  It says it has everything you would expect except wheels.  It is
> >silly to have to list a vehicle as having brakes, windows, doors, steering
> >wheel, etc. just to say it has no wheels.
>     I think you missed the point.  IncludesNoExec isn't an option, it's
>     an UNoption.  Options are things that are available, not things that
>     aren't.  Or maybe *I'm* missing the point.

You are missing the point that, in general, to enable server side includes
(which include all functionality) you need options Includes.  Some people
do not want some of the functionality, so a special directive was added to
allow them to do what they want.  IncludesNoExec is not an "unoption"; it
is simply the easiest possible description of what the option does: it
does everything Includes does, except allow for the exec command.  Read
what I wrote above about it being silly to say every thing a car has just
to say it doesn't have one thing.

> >>     I *do* use include virtual instead of exec cgi.  But don't tell me,
> >>     tell the hundreds of thousands of Apache users out there.  I trust
> >>     CGIs [marginally] more than I do arbitrary shell scripts, and it
> >>     bothers me that the config language treats them as requiring more
> >>     caution.  AND as a subset of shell-command.
> >
> >No, the config language treats exec anything as requiring more caution.
> >include virtual isn't execing anything, it isn't reading anything from
> >disk, it isn't accessing a database for anything: it is just making a
> >request somehow.  How doesn't matter.
>     We're definitely miscommunicating here.  "Options Includes" turns on
>     "exec cmd", but not "exec cgi".  You need to take another step to
>     turn on the latter, and "Options IncludesNoExec" turns them *both*
>     off.

Huh?  No.  Just because saying something is a CGI _requires_ another step
doesn't mean "Options Includes" doesn't enable exec cgi.

> >>     If exec cgi is legacy, then let's either take the plunge and
> >>     document it as deprecated and possibly to be removed in the future,
> >>     or else support it correctly.
> >
> >It is documented as not being the best way:
> >
> >                The include virtual element should be used in preference
> >                to exec cgi.                                           
>     Not at all the same thing as saying it's deprecated/going away.

Erm... it does say it is deprecated.  "it should not be used" ==
expressing disapproval of == the meaning of deprecated. 

Why should it be going away?  Just because it isn't recommended and can't
do everything is no reason to break backwards compat.

> >> >Where do you get the idea that ExecCGI allows "exec cgi"?
> >> 
> >>     From the documentation, testing, and experimentation.
> >
> >I'm afraid I don't follow.  If you want to use exec cgi, you need ExecCGI
> >or a ScriptAlias.  However, just having ExecCGI enabled doesn't allow you
> >to do an exec cgi.
>     Erm, 'fraid it does - at least for me.  Put it this way: when I have
>     an "exec cgi" that refers to a CGI script in my own directory, I get
>     a null substitution string UNLESS I have "Options Includes ExecCGI".
>     With that, however, the CGI works and is included properly.

Sigh.  Try using "Options IncludesNoExec ExecCGI".  You can't use exec
cgi.  Try "Options ExecCGI".  You can't use exec cgi.  Therefore, just
because ExecCGI is enabled doesn't allow you to do an exec cgi.  "Options
Includes" allows you to exec CGIs, period.  For something to be a CGI, in
this case, it is defined as a directory either with ExecCGI enabled or
with a ScriptAlias.  That is the definition that mod_include uses for a

I see no gain from changing the directives to something completely
incompatible, which requires people to use _THREE_ directives to get full
SSI functionality, and which does not let you do anything that you can't

The only point of confusion with the current ones is possibly the way
error messages are or are not generated in some cases and the inability of
include virtual to execute CGIs in non-scriptalised directories.

View raw message