libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] Issue with response processing in 0.9.38


From: Christian Grothoff
Subject: Re: [libmicrohttpd] Issue with response processing in 0.9.38
Date: Fri, 21 Nov 2014 13:38:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0

Dear Nikhil,

Are you, by any chance, modifying the response's header (using calls
like MHD_add_response_header()) after queuing the response? If you do
this (especially in another thread), that would explain the problem.

Once you queue a MHD response, you must not modify it anymore. However,
this is not enforced by the library. But if you do such concurrent
modifications, that would explain triggering the assertion in
connection.c:906.  Aside from that, I can't see how/what would trigger
the assertion.

Happy hacking!

Christian

On 11/20/2014 04:25 AM, Nikhil Saraf wrote:
> Earlier, I was using 0.9.25 version of MHD and requests were getting
> successfully processed by MHD. For instance, a POST request was getting
> successful and "HTTP/1.1 201 Created" response was being generated.
> 
> 
> Recently, I upgraded to MHD 0.9.38 and ever since I did that, I've
> started to observe some issues with MHD while sending responses back to
> the client.
> 
> 
> When we send multiple requests on a single connection in synchronized
> manner, MHD encounters a fatal internal error and calls panic function
> set by *MHD_set_panic_func()*, during response processing. There is no
> specific occurrence pattern for this problem - sometimes it occurs only
> after 4-5 requests and sometimes after 100.
> 
> 
> Logs suggest that problem occurred during execution of
>  *MHD_queue_response()* function which resulted in calling
> *MHD_set_panic_func ()* and it indicates reason behind fatal error
> at connection.c :906.
> 
> 
> At client side, instead of "HTTP/1.1 201 Created", following HTTP header
> is being received:
> 
> "Continuation or non-HTTP traffic".
> 
>  
> 
> Please suggest if it's a bug? Or is there any extra handling that I need
> to add?
> 
> 
> Thanks,
> 
> Nikhil.
> 

Attachment: 0x48426C7E.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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