[Top][All Lists]

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

Re: [libmicrohttpd] problems with callack replies

From: Christian Grothoff
Subject: Re: [libmicrohttpd] problems with callack replies
Date: Wed, 29 Apr 2020 16:57:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

Dear Viktor,

Your code snippet looks fine. So I just tried and failed to reproduce
your problem.  I basically simply used Wireshark and the existing code
from here:

(Note: I fixed a relevant typo in the example logic that I found when
looking into this, so please use the version from Git master.)

With this, MHD does add the right header *and* proper chunked encoding.
Now, MHD has many options (threading loop logic, etc.) and maybe you are
doing "something" different that triggers a bug in MHD.

Could you please try to modify the above example, moving it closer to
what you do in your code, to see if/when you can trigger the bug with
some reasonably minimal code?

Happy hacking!


On 4/29/20 2:55 PM, Viktor Paramonov wrote:
> I use the following sequence of commands:
> |MHD_Response* resp = MHD_create_response_from_callback (
> asyncReplyCleaner ); MHD_add_response_header (c->mConnection,
> "Content-Type", "application/json" ); MHD_queue_response (
> c->mConnection, MHD_HTTP_OK , resp ); MHD_destroy_response (resp); |
> The callback function does approx. the following:
> |<1 or more times: copy data to provided buffer and return data length >
> return MHD_CONTENT_READER_END_OF_STREAM; /* when data is finished */ |
> In general this code works, but with problems:
> 1. Despite the library adds the "Transfer-encoding: chunked", there is
> no chunk formatting in data. All, what is returned from callback, is
> transmitted "as is".
> 2. The response header is not set. (Content-Type) 
> 3. The browser does not know, when data is finished. It shows that this
> connection is loading forever. The javascript object XmlHttpRequest
> never gets the state "ready". I have impression, that this connection
> (this socket) will be never reused by browser for subsequent requests.
> Is there any way to handle the reply from callback properly? 
> http <>

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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