[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] [EXTERNAL] Re: 0.9.71+ Connection Idle and Reuse Iss
From: |
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 |
Date: |
Thu, 7 Jan 2021 20:58:11 +0000 |
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
- Re: [libmicrohttpd] [EXTERNAL] Re: 0.9.71+ Connection Idle and Reuse Issue when Suspending and Resuming Connections,
Earp, Damon N. (GSFC-619.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] <=