Comment 1 for bug 497191

This problem gets a little complex. Moving the set_close_after_request() call into Connection (so that it can be registered after it exists in Server) still has the problem of when the request is created and destroyed within the call to Server.add_request(), which is the current case with Server.default_on_new_request(). The other solution is to remove the check in set_close_after_request() - this makes things work but there exists the potential for race conditions. Really, the only solution would be to make adding the new request and registering it in Connection an atomic operation - ugly as things currently stand.

However, I think the real solution is that list of current request id's need to be managed in Connection, not Server. This is especially true when you consider that different web servers may all be communicating with a single libvfcgi-based application server, so that there exists the very likely possibility that we need to handle duplicate request id's simultaneously (the FGCI spec also aludes to this - "...the application keeps track of the current state of each request ID on a _given_ transport connection...").