[Top][All Lists]

[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: Christian Grothoff
Subject: Re: [libmicrohttpd] [EXTERNAL] Re: 0.9.71+ Connection Idle and Reuse Issue when Suspending and Resuming Connections
Date: Thu, 7 Jan 2021 22:12:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

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!


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]