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

[Bob Furber]

Thanks Kenneth & Christian,

The port of my program using microhttpd now works as it should. So, now we have at least 2 ports to 32 bit Arm-Linux devices running microhttpd.

In hindsight, my problems were of my own making and no shortcoming of microhttpd.

Thanks for your help and support.

BobF


On 15-02-27 01:25 PM, Kenneth Mastro wrote:

I doubt this will be of much help, but I have cross-compiled microhttpd (0.9.39) on a 64-bit Linux machine to run on a 32-bit ARM (running a buildroot/busybox-based Linux OS).  I created a reasonably sophisticated content-management system to serve up files, dynamically generate content, and accept/store file uploads.  I run and work with it every day with no problems.

My point is - it's definitely possible to do.

I didn't compile it on the ARM itself, though.  I do it in a 64-bit Linux VM (Ubuntu 12.04 LTS) running on x86 (host OS is Windows 7).  When running 'configure' for cross-compiling, I export several environment variables first, and specify a couple configure options.  E.g., something like this in a bash script in the root mhd directory:

---------------

CMAKE_C_COMPILER="<path to gcc cross compiler>"

export CMAKE_C_COMPILER

CC="<path to gcc cross compiler>"

export CC

CMAKE_CXX_COMPILER="<path to g++ cross compiler>"

export CMAKE_CXX_COMPILER

CXX="<path to g++ cross compiler>"

export CXX

./configure --prefix="<path where I want it installed so other code can link against it>" --host=arm-linux

---------------

Then, just run that script instead of a raw 'configure', followed by a 'make' and 'make install'

Again - I doubt this will be of much help, and setting up the cross-compiler toolchain will probably be a pain if you don't already have it.  The suggestion to try cross-compiling is about all I can offer, though.  That will bypass any (unlikely) problems introduced by gcc on your ARM device.  Microhttpd (and obviously the code that uses it) will definitely run without issue on 32-bit ARM Linux.

Ken

On Fri, Feb 27, 2015 at 3:57 PM, Bob Furber <address@hidden> wrote:

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?