where is HTTP_IN for internal redirect? (daedalus segfault today)

[Jeff Trawick <tr...@attglobal.net>]

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.

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

Maybe Greg played with a fix already; I was lazy/hungry and bailed
out.

Thoughts?

to reproduce:

two requests on the connection
first is POST/PUT with body to URI which is redirected internally

you'll see that there is no HTTP_IN for handing out body
bytes... ap_get_client_block() will call CORE_IN directly

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Re: where is HTTP_IN for internal redirect? (daedalus segfault today)

[Greg Stein <gs...@lyra.org>]

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/

Re: where is HTTP_IN for internal redirect? (daedalus segfault today)

[Greg Ames <gr...@remulak.net>]

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