httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: where is HTTP_IN for internal redirect? (daedalus segfault today)
Date Tue, 30 Oct 2001 18:52:38 GMT
Jeff Trawick wrote:
> 
> Greg Ames and I spent some time today looking at a core dump on
> daedalus where httpd got confused about the boundary between request
> body and the header for the following request.

in addition to looping until we get a humongous core dump (500M+) with
pipelined requests, this is causing the extra read+timeout with POSTs
that people have noticed recently.

> It appears that with the input filter rewrite we stopped using HTTP_IN
> for internal redirects.  HTTP_IN is now added in ap_read_request()
> instead of a more general place.  I think we need it also in
> internal_internal_redirect() 

this one works.  I'll commit once cvs.apache.org becomes pingable.

>                               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.

Greg

Mime
View raw message