httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: svn commit: r711886 - /httpd/httpd/branches/2.2.x/STATUS
Date Fri, 07 Nov 2008 12:35:19 GMT
Joe Orton wrote:

>> What is the problem at all?
>> mod_proxy_http uses a a conn_rec to communicate with the backend. It somehow reverses
>> the meaning of input and output filters and uses them to send the request and receive
>> the response. In order to use persistent SSL connections to the backend it is needed
>> to keep this conn_rec (and thus its bucket allocator) alive and tied to the backend
>> connection. Thus it is no longer destroyed at the end of a client request / connection.
>> So the conn_rec and especially the bucket allocator for the backend have a lifecycle
>> that is disjoint from the one to the client. Especially it can happen that due to
>> a faulty backend connection the conn_rec to the backend *lives* shorter than
>> buckets that are still buffered somewhere in the output filter chain to the client
>> (see comments in removed code below). This causes segfaults when these buckets are
>> accessed then or if brigades that contain them get cleaned up later on due to a parent
>> pool cleanup.
> Not sure if I've got my head round this correctly, but...
> Would it be possible to substitute the backend ("fake") conn_rec's 
> ->bucket_alloc pointer with the "real" r->connection->bucket_alloc, for 
> the duration of the request/response to the backend?  Wouldn't that 
> ensure that all the buckets in question exactly have the correct 
> lifetime?

What looks broken to me is the fact that there is a link between the 
backend connection_rec and the frontend request_rec at all.

Both of these structures have completely independent and unrelated 
lifecycles, and either structure might outlive the other structure.

Ideally there needs to be a way of passing data that "belongs" to the 
backend across to the frontend without making any assumption that one 
will outlive the other. If this isn't possible, then we'll just be 
forced to copy the data.


View raw message