Re: the mod_include problem...

[Howard Fear <hs...@pooh.pageplus.com>]

Dean Gaudet writes:
> I'm convinced mod_include is at fault regarding this problem between it
> and the new table api.  My reason is that mod_include makes the assumption
> that it is the *only* module which is using run_sub_request()... which is
> bogus.  If another module were to run_sub_request() on something which
> invoked mod_include then it would muck around with the environment of a
> request it shouldn't be touching. 
> 
> I have an idea how to deal with it.  My fix will allow #included SSI
> documents to modify the environment, but won't allow any other type of
> include to modify the environment.  To draw a parallel with /bin/sh,
> "#include" of an SSI document is similar to "source" of another shell
> script.  But you can't "source" a binary program and expect it to modify
> the environment of your shell. 

Yes, you understand the problem.  It was clearly labelled a kludge that
was probably necessary for backward compatibility with the
pre-'modularized' apache and ncsa.  (I don't know, that pre-dates my
work on mod_include).  Any layered request handler will have to handle
this as a 'special case' as you note in the case of the shell.  I would
be surprised if this doesn't have to be kludged in to the 2.0
architecture as well.

If I understand you correctly, the change is allowing anything that
might be included to change the environment to allowing only ssi files
to do that.  While there is some justification for considering a
document and anything it includes to be atomic wrt the environment, this
probably works from a user's point of view.  Most included text is html
(which can't really do anything about it now), shtml (which will still
be able to), and cgi (which also can't do anything about it now).
Custom modules might make use of this, but few work through the env.
And this behavior would probably be an unpleasant surprise to their
authors anyway.

(Actually, I recall being amazed that this worked when I first wrote
xssi.  it is useful to create a common environment-setting file.  I got
several emails at the time from users who figured this out, but I doubt
most did since it was never really documented.  And, its really more of
an xssi issue since the earlier ssi really didn't let you set much in
the way of variables.)

> By way of contrast, apache-1.2 and earlier allows a #included object to
> muck with the environment.  (And even that can be buggy for other
> reasons).

Yes, but I suspect that's less of a problem than you're giving
it credit for.  There aren't that many things that muck with the env
on a per-request basis and (currently) they pretty much stay out
of each other's hair - i.e. they set and use their own limited set
of variables.

--
Howard Fear      I'm just a country perl hacker Jim.        hsf@pageplus.com
                    http://www.pageplus.com/~hsf/           hsf@redcape.com