[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!
Cristian
> 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
>> returns MHD_CONTENT_READER_END_OF_STREAM.
>>
>> 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
>
>