Christian, I've tested your version and indeed I see the expected behavior. I believe the disconnect is my lack of knowledge of the flow requirements of the access handler. I was under the impression that in a non-100 continue requests queueing a response on the 2nd callback was fine, but I see from your changes I need to wait till the 3rd callback.
Access handler flow from your updated main.c: Call 1. Increment the request access handler call count and return MHD_YES Call 2. Create the thread, suspend the request and return MHD_YES Call 3. queue the response return result It appears that I've been combining the first 2 calls incorrectly. I updated my main.c to do nothing on the first call, suspend and create thread on second call, and queue response on third and now am seeing the correct behavior. > The problem is that your logic queues a response during the *first* > callback to 'access_handler' Was that supposed to be *second* not *first*? I added extra logging and confirmed I am queuing on the second callback to the access_handler. As long as I moved the queuing of the response to the third call I saw proper reuse and idling of the connection. So to clarify: On all requests, regardless of method and existence of the Expect: 100 header, queuing a response on the first or second call to the access handler is "early" and leads to a forced closing of the connection. Therefore on all non-"Expect: 100" requests, making the first call to the access handler a NOOP is a simple way to avoid queueing a response too early. Thanks again for your time and help. Damon Earp
