httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@worldgate.com>
Subject Re: [Fwd: mod_browser/1081: BrowserMatch variables not working in nested include files]
Date Mon, 01 Sep 1997 17:48:04 GMT
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.



Mime
View raw message