libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] Messages queued by MHD not received by client


From: Bob Furber
Subject: Re: [libmicrohttpd] Messages queued by MHD not received by client
Date: Fri, 27 Feb 2015 12:57:10 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Thanks Christian, but, while it appears to be a 32/64 bit issue, I am not aware of having encountered AC_SYS_LARGEFILE.

microhttpd was installed on the 64 bit LinuxPC with sudo apt-get install libmicrohttpd-dev , so I am unaware of any special configurations during installation.

microhttpd was installed on the 32 bit Arm-Linux platform by downloading the latest libmicrohttpd (libmicrohttpd-0.9.39.tar.gz <http://ftp.gnu.org/gnu/libmicrohttpd/libmicrohttpd-0.9.39.tar.gz>) from http://ftp.gnu.org/gnu/libmicrohttpd/, expanding it and blindly following the configure, make, make install recipe. T hen copied libmicrohttpd.a and microhttpd.h back to the LinuxPC where they could be accessed by the cross-compiler. Again, I never came across AC_SYS_LARGEFILE.

I grepped my LinuxPC for AC_SYS_LARGEFILE, without success. Neither am I any wiser after googling AC_SYS_LARGEFILE.

I am at a loss as to how to address the possible off_t issue. The only place I can find it is a parameter in microhttpd.h > MHD_create_response_from_fd_at_offset() and a "Be careful! `off_t` may have been compiled to be a 64-bit variable for MHD" warning. Where would this have occurred? On the Arm-Linux device, following the configure, make, make install recipe? If so, how could I correct this?

I should mention that I am dealing with relatively small files ( < 1MB).

I wonder if anyone could suggest some questions, avenues or experiments that may shed more light on how to un-stick microhttpd transmit response queue or how to feed it appropriately?


On 15-02-27 12:25 AM, Christian Grothoff wrote:
Maybe you have an off_t 32-bit/64-bit confusion in your code (did you
build your main C application with AC_SYS_LARGEFILE?).  If that is the
case, it might be that the "content-size" returned by your server is
larger than what the callback is able/willing to provide. Then, when the
server dies and closes the TCP connection, the HTTP client will
interpret that as the 'end of response' and ignore content-size, which
would explain your observation.

I would suggest looking at the network traffic with wireshark, and my
guess is that the HTTP server will have delivered the full response and
the client is just waiting for more.


Happy hacking!

Christian

On 02/27/2015 05:10 AM, Bob Furber wrote:
I have a microhttpd based server program (mhdServer ) that happily
serves files and more, when run on a 64-bit LinuxPC and is accessed
through requests such as http://localhost:8080/filename.html.

However, porting this program to a remote 32-bit Arm-Linux platform is
proving to be a challenge: It ALMOST WORKS:
* It replies with a “404 File not found” response to requests for
non-existing files ..as it should

But, requests for existing files do not get the anticipated reply:
* Client hangs waiting for requested web page files
* However, the web page is displayed by the client as soon as the
mhdServer program is terminated!!

Examination of the mhdServer program with a remote debugger indicates that:
* All client requests are being received
* The requested files are indeed located and fopen'ed
* MHD_create_response_from_callback() returns MHD_YES (1)
* MHD_queue_response() returns 1, indicating success ..yet the client
keeps waiting patiently for its response ..which only arrives upon
mhdServer's dying breath

I have been banging my head against this for days. Can anyone suggest
any tests that might shed light on this strange behaviour?





reply via email to

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