If you abort the connection and core_output_filter doesn't get called, the request/connection pool seems that it would be leaked. That's badness.No, we definitely need to do that cleanup in core_output_filter, because that's the only code that's guaranteed to still be runnable by the time we detect the aborted connection. The handler may have finished running long before the connection is aborted, and in an async MPM the thread that ran all the other request hooks is likely to have moved on to a new request.
Yes, if we're sitting in core_output_filter and just trying to shove data out (we've seen EOS and have all data ready), your solution works. Yet, I'm concerned about requests that are aborted before EOS and never make it to core_output_filter. Their pool needs to be cleaned up somehow. How do you plan on addressing this?
Forcing all of the output filters to run when we have an aborted request is not good. Your solution seems to require that. We should try to move away from doing this. -- justin
