[Top][All Lists]

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

Re: [libmicrohttpd] HEAD and Keep-Alive Problems

From: Cristian KLEIN
Subject: Re: [libmicrohttpd] HEAD and Keep-Alive Problems
Date: Fri, 26 Jun 2015 08:43:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 25.06.2015 21:11, Christian Grothoff wrote:
> Hi!
> The 'correct' answer is that you should not even have to treat HEAD/GET
> any different in your application logic, by design MHD should just
> notice it's a HEAD request and not send the body.
> I just modified 'src/examples/demo.c' to support HEAD requests
> (basically previously it checked for method matching 'GET' and
> otherwise denied, so all I did was allow GET or HEAD).
> I checked it, and it does keep the connection alive as it should,
> including with both response_from_buffer and response_from_fd ---
> as long as the client does request http/1.1 (or keep-alive).
> I hope this helps!
> Happy hacking!
> Christian

Hi Christian,

Thank you for your answer.

Could you please also check MHD_create_response_from_callback()? The
connection was dropped for me only when using this function.

Also, my callback is called once with max=0. Is this behaviour intended?
I was expecting the callback not to be called at all.

Happy hacking!


> On 06/24/2015 02:22 PM, Cristian KLEIN wrote:
>> Hello all,
>> I am having some problems implementing HEAD requests in a way that keeps
>> the connections alive. I am unsure how to properly implement HEAD
>> requests, so as to send the client a correct "Content-Length" and not
>> breaking keep-alive. I tried two options:
>> (1) using MHD_create_response_from_callback(), i.e., maintaining almost
>> the same application code as for GET. For HEAD, microhttpd calls the
>> callback with max=0, for which my callback simply
>> The problem with this approach is that the HTTP connection is dropped
>> after sending the HEAD headers. This is perfectly legal and clients can
>> deal with it, but incurs a large performance overhead. I'm not sure if
>> this is bad usage of microhttpd on my side or a bug in microhttpd.
>> (2) using MHD_create_response_from_buffer(). Since I sometimes return
>> large files (1GB is not uncommon) it does not make sense to create a
>> large, empty buffer to pass to MHD_create_response_from_buffer, so I
>> have two options:
>> (2a) MHD_create_response_from_buffer(0, "", MHD_RESPMEM_PERSISTENT) ->
>> the client gets an incorrect "Content-Length"
>> (2b) MHD_create_response_from_buffer(contentSize, "",
>> MHD_RESPMEM_PERSISTENT) -> scary, looks like the largest buffer overflow
>> ever. :) Valgrind does not seem to complain, so it seems that microhttpd
>> does not actually access that buffer.
>> Tested with libmicrohttpd 0.9.33 and 0.9.42.
>> Can somebody point out an example HEAD implementation? Which of the
>> above usages is recommended?
>> Thanks,
>> Cristian

reply via email to

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