You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@algroup.co.uk> on 1997/09/01 13:32:17 UTC
[Fwd: mod_browser/1081: BrowserMatch variables not working in nested include files]
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?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: mod_browser/1081: BrowserMatch variables not working in nested include files
Posted by Dean Gaudet <dg...@arctic.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.
>
>
>
Re: [Fwd: mod_browser/1081: BrowserMatch variables not working in nested include files]
Posted by Marc Slemko <ma...@worldgate.com>.
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.