www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: mod_browser/1081: BrowserMatch variables not working in nested include files
Date Tue, 02 Sep 1997 07:10:18 GMT
The following reply was made to PR mod_browser/1081; it has been noted by GNATS.

From: Dean Gaudet <dgaudet@arctic.org>
To: Jim Chou <jchou@tivoli.com>
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
 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. 
 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
 > > > 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.

View raw message