httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: where is HTTP_IN for internal redirect? (daedalus segfault today)
Date Tue, 30 Oct 2001 23:08:49 GMT
On Tue, Oct 30, 2001 at 01:52:38PM -0500, Greg Ames wrote:
> Jeff Trawick wrote:
>...
> >                               or it is needed in some more general
> > place *or* when added in ap_read_request() NULL should be passed for
> > the request_rec parameter so that it is tied to the conn_rec.  That
> > should make it available for the redirect too (though I don't know if
> > the right thing will happen for subrequests in that case).
> 
> the latter would be slightly more efficient, but a more complex change. 
> In addition to what you mentioned above, HTTP_IN couldn't depend on
> f->r->pool.  We don't want multiple instances of the filter either when
> there are pipelined requests.  So if we took this approach, we would
> have to move the ap_add_input_filter from ap_read_request to somewhere
> connection related.

Attaching HTTP_IN to the connection would break a lot of things. We insert
the thing *after* we read the header. That means the filter doesn't have to
"get out of the way" when the higher levels are reading the header -- it
just isn't there to begin with. Once we read the header, then we add it.

Go back a few revs of the HTTP_IN filter. You'll see the nastiness that we
had to do to get out of the way. Things were dramatically simplified by
delaying its insertion into the filter stack.

But yes: it does mean that if the request filters are blown away, that it
must be reinserted.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message