Variable passing in SSI

[Thom May <th...@planetarytramp.net>]

I have this filed bug via debian's bug system:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=157299&repeatmerged=yes

regarding the passing of SSI variables in fancy indexed pages using SSI
Header and Readme's.
Comments/thoughts/fixes?
Cheers,
-Thom

-- 
Thom May -> thom@planetarytramp.net

<Joy> it's a nifty surname if you ask me, but hey, you're talking to a 
      guy who picked a name common among old women for a nickname by 
      mistake <sigh>

Re: Variable passing in SSI

[Brian Pane <br...@cnet.com>]

On Mon, 2002-10-14 at 06:13, Thom May wrote:
> I have this filed bug via debian's bug system:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=157299&repeatmerged=yes
> 
> regarding the passing of SSI variables in fancy indexed pages using SSI
> Header and Readme's.
> Comments/thoughts/fixes?

In 2.0 (I'm not sure about 1.3), mod_include only uses the parent
request's context for SSI variables if the subrequest is invoked
from within another mod_include request.  Mod_autoindex pages
don't meet that criterion, so each subrequest (header and readme)
uses its own private context, and variables set in one subrequest
are unavailable in the next.

It might be reasonable to change mod_include so that it
always locates the topmost request_rec and uses that request's
subprocess_env for variables.  I'm somewhat wary of making
such a change, though, due to security concerns: shtml files
included by mechanisms other than mod_include (e.g., by
mod_autoindex or by custom modules) suddenly would gain
the ability to read and write the parent request's
subprocess_env, which they can't do today.

Brian