httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: mod_browser/1081: BrowserMatch variables not working in nested include files
Date Tue, 02 Sep 1997 07:06:56 GMT
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