Date: Tue, 2 Sep 1997 00:06:56 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: Jim Chou <jchou@tivoli.com>
cc: apbugs@apache.org, new-httpd@apache.org
Subject: Re: mod_browser/1081: BrowserMatch variables not working in nested
 include files
In-Reply-To: <Pine.BSF.3.95q.970901114240.24224B-100000@valis.worldgate.com>
Message-ID: <Pine.LNX.3.95dg3.970902000301.31652W-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

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.
> 
> 
>