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 e.g. 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.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
