Thank you for clarifying. Damon Earp
________________________________ From: Christian Grothoff Sent: Thursday, January 7, 2021 16:12 To: libmicrohttpd@gnu.org; Earp, Damon N. (GSFC-619.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] Subject: Re: [libmicrohttpd] [EXTERNAL] Re: 0.9.71+ Connection Idle and Reuse Issue when Suspending and Resuming Connections On 1/7/21 9:58 PM, Earp, Damon N. (GSFC-619.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] via libmicrohttpd wrote: > 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. Partially ;-). > 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. It is fine to do so on the 2nd, but there are two exceptions: 1) if there is upload_data -- then you have to wait until the upload is done -- but that's not the case in your scenario; or 2) if you suspend during the 1st call, then that 1st call doesn't count _because_ you suspended (so it never 'finished') ;-) > 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. What is important is that you return MHD_YES once _without_ also suspending. So if you didn't do that thread-activity, you could queue the response on the 2nd call already. > Thanks again for your time and help. Sure. As I said, we know this part of the API can be a bit confusing and needs improving ;-). Happy hacking! Christian
