You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Jim Chou <jc...@tivoli.com> on 1997/08/31 23:30:03 UTC

mod_browser/1081: BrowserMatch variables not working in nested include files

>Number:         1081
>Category:       mod_browser
>Synopsis:       BrowserMatch variables not working in nested include files
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache (Apache HTTP Project)
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Sun Aug 31 14:30:02 1997
>Originator:     jchou@tivoli.com
>Organization:
apache
>Release:        1.2.4
>Environment:
All
>Description:
In 1.2.4, it appears two changes were made to mod_browser:
 - the parse_header_browser_module routine was renamed to browser_match
 - this routine was moved from the header parser phase to the file translation phase

The latter causes a problem with nested include files, (at least in the case
when a previous module has also done filename translation). When a nested include
file attempts to use a variable set by a BrowserMatch directive it cannot
find the variable. It appears this is because in nested includes, mod_include
searches r->subprocess_env, which has been set to r->main->subprocess_env so
subrequests share the main's environment, but when browser_match set the
variables it set them in its own r->subprocess_env, which was not r->main->subprocess_env

>How-To-Repeat:

>Fix:
I guess this could be fixed by making browser_match always set variables in
r->main->subprocess_env if there is an r->main, but it seemed easier just
to move the handler to the header parser phase.

Was there a reason it was moved from the header parser phase to the filename
translation phase in 1.2.4? (or somewhere between 1.2.0 and 1.2.4)?
%0
>Audit-Trail:
>Unformatted: