Re: [libmicrohttpd] Race condition when enqueing

[Christian Grothoff]

Hi Mike,

Without having seen your handler function, I suspect that it is (3).  MHD 
expects you to ONLY queue a response after you've either seen the full request 
(not the case here) or on the first call when 100 CONTINUE is still being 
"considered".  Since (based on your description of the type of request that is 
happening here) 100 CONTINUE is skipped, you need to wait with queuing a 
response until the entire request was processed.  This was a deliberate design 
decision since it seemed too messy to have an application give us a response 
and then continue to process the upload -- this would almost always be a bad 
idea since you could then not change the response to indicate an error 
anymore.

Naturally, I can only say for sure if I see your callback implementation, but 
this is what I suspect is going on right now.

Best,

Christian

On Tuesday 09 March 2010 05:20:17 pm Mike Crowe wrote:
> 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.
>