[libmicrohttpd] Race condition when enqueing

[Mike Crowe]

I'm seeing an occasional unit test failure in the code I'm using with
libmicrohttpd 0.4.5 when accepting a chunked POST request both with
and without the client expecting "100 continue." I'm using
MHD_USE_THREAD_PER_CONNECTION mode and I'm setting up the response
deliberately even before any body has arrived.

After adding some tracing code I believe the following is happening:

Post request comes in and gets as far as being in the
MHD_CONNECTION_HEADERS_PROCESSED state in MHD_connection_handle_idle.

call_connection_handler is called but it returns pretty quickly
because insufficient data is present (at the /* need more data... */
comment.)

In my particular test case need_100_continue() returns false so we
don't go into state MHD_CONNECTION_CONTINUE_SENDING.

connection->response is still NULL and
connection->remaining_upload_size is still MHD_SIZE_UNKNOWN so the new
state is set to MHD_CONNECTION_CONTINUE_SENT (even if "100 continue"
has not been sent.)

Later we come back into MHD_connection_handle_idle and call
call_connection_handler again. This time sufficient data appears to be
available and we call into the default handler. It tries to queue up a
response by calling MHD_queue_response but this fails because the
connection state isn't either MHD_CONNECTION_HEADERS_PROCESSED or
MHD_CONNECTION_FOOTERS_RECEIVED. :(

So, I'm wondering who is at fault here?

1. Should we never be going into state MHD_CONNECTION_CONTINUE_SENT in
   this case at all?

2. Should MHD_queue_response consider state
   MHD_CONNECTION_CONTINUE_SENT to be valid on entry too? If I change
   MHD_queue_response to accept that state then my problems go away.

3. Is my handler function misbehaving by calling MHD_queue_response
   even though the body hasn't turned up yet?

Thanks.

Mike.