From apwww@hyperreal.org Sun Aug 31 14:22:03 1997 Received: (from apwww@localhost) by hyperreal.org (8.8.5/8.8.5) id OAA24824; Sun, 31 Aug 1997 14:22:03 -0700 (PDT) Message-Id: <199708312122.OAA24824@hyperreal.org> Date: Sun, 31 Aug 1997 14:22:03 -0700 (PDT) From: Jim Chou Reply-To: jchou@tivoli.com To: apbugs@hyperreal.org Subject: BrowserMatch variables not working in nested include files X-Send-Pr-Version: 3.2 >Number: 1081 >Category: mod_browser >Synopsis: BrowserMatch variables not working in nested include files >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: closed >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Sun Aug 31 14:30:02 1997 >Last-Modified: Thu Nov 13 07:16:12 PST 1997 >Originator: jchou@tivoli.com >Organization: >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: From: Dean Gaudet To: Jim Chou Subject: Re: mod_browser/1081: BrowserMatch variables not working in nested include files Date: Tue, 2 Sep 1997 00:06:56 -0700 (PDT) Marc dug up the reasons for the mod_browser change, I've included them below. I'm not quite clear what's going wrong, I think I need to see an example #include that is broken, and the relevant config info. Thanks Dean On Mon, 1 Sep 1997, Marc Slemko wrote: > On Mon, 1 Sep 1997, Ben Laurie wrote: > > > Jim Chou wrote: > > > > > > >Number: 1081 > > > >Category: mod_browser > > > >Synopsis: BrowserMatch variables not working in nested include files > > > >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)? > > > > Good question. Was there? > > > > Dean said: > > >I add a new API phase -- post_read_request. It runs after read_request or > >internal_redirect are done setting up the request. It does not run for > >subrequests, because they inherit the environment of the parent. I > >proposed this phase a while back as the "correct" solution to the > >mod_browser/mod_setenvif dilemna that I had when fixing the MSIE 4.0b2 > >problems. Specifically, the header_parse phase occurs far too late to > >affect some aspects of the protocol (i.e. far too late for a nokeepalive > >env var to be set to stop a redirect response from being kept-alive). > > And: > > >The keepalive changes in the patch I posted yesterday are total crap. > >The force-response-1.0 part works, and is necessary because without it > >we'll do things like Transfer-Encoding: chunked, but send HTTP/1.0. > > > >Here are the two pr2 bugs I know of: > > > >1 seems to handle keep-alive only on 200 responses, all others need to be > > closed by the server before the client will continue > > > >2 the Java VM makes HTTP/1.1 requests but does not understand HTTP/1.1 > > responses, in particular it does not understand a chunked response. > > See PR#875, the user has a CGI which sends a response to a java applet. > > Naturally the response is chunked in 1.1. > > > >Now here comes the fun. Problem 1 is really painful on redirects. > >Redirects are generated during translate_name(). BrowserMatch is done > >during header_parse -- which occurs *after* translate_name. Hence > >set_keepalive does not have any nokeepalive variable to test, and it > >happily follows 1.1 and does keep-alive. > > > >So I ask myself, "why does header_parse come *after* a handful of other > >phases?" The obvious answer is that if it came before then you couldn't > >have per_dir modifications to header_parse routines. But the > >header_parser was added specifically so that we could use mod_browser to > >kludge around screwed up clients... well, we can't use it to work around > >this screwed up client. > > > >My suggestion for now: make mod_browser use translate_name instead of > >header_parse. A cleaner solution is to add yet another api phase. > >Note that this means mod_browser is going to run during a > >sub_req_lookup_uri(), but I don't think this is a problem (and using > >something like is_initial_request does not work, see next message). > > >Either way, we end up with a nokeepalive env var when we need it. Then we > >need to do the Right Thing with it in set_keepalive. I think what I do > >in the patch below is the Right Thing, I'm sure Roy will disagree :) > > >I have no solution (that I'm happy with) for problem 2. The user-agent > >is the same whether the browser is making a regular or a java request. So > >what I do below is a complete hack -- the env var "downgrade-request-1.0" > >causes the server to pretend it got a 1.0 request. > > > State-Changed-From-To: open-feedback State-Changed-By: dgaudet State-Changed-When: Thu Sep 18 12:31:54 PDT 1997 State-Changed-Why: Waiting for a complete example from user. FWIW, this shouldn't be a problem in 1.3 because of the addition of the new api phase to properly solve this problem. It can probably be hacked around in 1.2.4 by making mod_browser run both during translate_name and during header_parse. Dean State-Changed-From-To: feedback-closed State-Changed-By: coar State-Changed-When: Thu Nov 13 07:16:12 PST 1997 State-Changed-Why: This is definitely fixed as of 1.3b3. The fix may or may not be backported to 1.2; I have doubts. Thanks for the report, and for using Apache! >Unformatted: