| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
| |
(previous formulation was wrong)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
reported by Cristian Klein on the mailinglist
|
| |
|
|
| |
MHD_create_response_from_fd_at_offset64() instead of MHD_create_response_from_fd_at_offset()
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
complaining about a memleak in libmicrohttpd.
In check_argument_match() a buffer is allocated using strdup() but freed nowhere.
I wouldn't have noticed this leak if it wasn't for valgrind because if a URI is requested without any arguments (my usual case)
the buffer that gets allocated has 'only' a length of 1 byte, thus memory usage will build up very slowly over time.
The patch attached fixes it.
Btw. the indentation of that file is a mess, tabs and spaces are mixed :-|
Regards,
Andreas
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hey,
I'm debugging a problem with a crash in MHD_select_thread. We had
MHD_start_daemon_va fail while creating worker threads with the following
error: "file descriptor for worker control pipe exceeds maximum value". We
know what caused this error and are fixing it. But the problem was that a
MHD_select_thread worker thread was left running in the background after
MHD_start_daemon_va returned failure. I think the problem is from this
code in the thread_failed case in daemon.c:
/* Shutdown worker threads we've already created. Pretend
as though we had fully initialized our daemon, but
with a smaller number of threads than had been
requested. */
daemon->worker_pool_size = i - 1;
MHD_stop_daemon (daemon);
return NULL;
From the code, it looks like "i" is actually the number of threads that
were successfully created, so the "i - 1" in this code will leave an extra
thread hanging since MHD_stop_daemon will clean up one less thread than it
should. I'll probably try to work up a test to verify removing the "- 1"
is correct, but that could take me some time so I wanted to make sure I
wasn't missing something obvious before heading down that path.
~JareD
He is right, this patch fixes it.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
select()/poll()/epoll() must always be non-blocking
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MHD goes in a busy loop when it is configured with MHD_USE_POLL_INTERNALLY and a connection times out.
When the connection times out, the connection is closed at connection.c:2646, which sets connection->event_loop_info = MHD_EVENT_LOOP_INFO_CLEANUP.
When the loop info is set to MHD_EVENT_LOOP_INFO_CLEANUP, the main function of the thread loop, MHD_poll_all, never calls back the connection idle callback, which would have cleaned the connection and exit the loop.
I resolved the issue in my development code by adding pos->idle_handler (pos) at daemon.c:2477 in MHD_poll_all (SVN 35533).
The busy loop could be tested using a small enough connection timeout and netcat:
nc -v -w 100 <IP ADDRESS> <IP PORT>
CPU usage will reach 100% in one of the CPU and will remain at that level even when the netcat has closed its end of the connection.
Thanks,
Louis Benoit
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hi,
I am doing test with HTTPS at low bit rate for large files using:
wget -v --no-check-certificate --limit-rate=1000 https://....
When the MHD daemon is configured with MHD_USE_EPOLL_INTERNALLY_LINUX_ONLY, I noticed that the thread takes 100% CPU, whereas
the MHD_USE_POLL_INTERNALLY configuration show a normal CPU usage.
Adding logs I see that the busy loops takes place at daemon.c, line 2605 (0.9.38):
daemon->eready_tail never gets NULL most probably due to connection.c, line 2671 to 2721
Thanks,
Louis
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RF flag should simply have been "==".
Louis wrote:
There is a change of behavior between 0.9.37 and 0.9.38.
When a client adds a "Connection: close" header in 0.9.37, MHD adds a "Connection: close" header to its response and then
close the connection (as suggested in rfc2616, section 8.1.2.1).
The "Connection: close" header is not added in 0.9.38.
I looked into the 0.9.38 code and the code that prevents the inclusion of the "Connection: close" header is at line 773 of connection.c.
if ( ( (NULL != client_requested_close) ||
(MHD_YES == connection->read_closed) ) &&
(NULL == response_has_close) &&
(0 != (connection->response->flags & MHD_RF_HTTP_VERSION_1_0_ONLY) ) )
must_add_close = MHD_YES;
Shouldn't it read
if ( ( (NULL != client_requested_close) ||
(MHD_YES == connection->read_closed) ||
(0 != (connection->response->flags & MHD_RF_HTTP_VERSION_1_0_ONLY) ) ) &&
(NULL == response_has_close) )
must_add_close = MHD_YES;
Thanks,
Louis Benoit
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Can't test POLL mode as MHD didn't support POLL on W32. The reason - winsock implementation is somehow different from POSIX one. libcurl initially added poll support for win32 but later it was removed. I didn't check specific reason so for safety MHD didn't use POLL on W32. However I leave changes for POLL code "as is" in case that we will add support for POLL on win32.
SELECT mode now works perfectly. Shutdown processed without any delay.
May be some comments will be good addition.
Patch is attached.
--
Evgeny
09.04.2015, 17:28, "Christian Grothoff" <christian@grothoff.org>:
> Hi Evgeny,
>
> I've tried to put together a patch for the issue, but as I'm on
> GNU/Linux, I cannot even test if the patch compiles... Please let me
> know if it works (and please test with POLL and SELECT separately), at
> least in principle I think this is roughly what the patch should look
> like...
>
> Happy hacking!
>
> Christian
>
> On 04/09/2015 03:25 PM, Evgeny Grin wrote:
>> If HAVE_LISTEN_SHUTDOWN is not defined (as on win32), pipe is used
>> automatically.
>> But pipe is monitored only in main "select()" thread. It's not
>> monitored in "connection" thread.
>>
>> Best Wishes,
>> Evgeny Grin
>>
>> On 04/09/2015 12:56 PM, Evgeny Grin wrote:
>>> Hi Christian!
>>>
>>> Another issue on win32, 100% reproducible.
>>> When running Kodi unittests, MHD always takes 120 seconds to shutdown.
>>>
>>> How to reproduce:
>>> * Start MHD with THREAD_PER_CONNECTION | DEBUG and some static
>> response,
>>> * Generate one http 1.1 request with libcurl. Notice that libcurl
>> always add keep-alive for http 1.1.
>>> * Let MHD to process request and answer with response.
>>> * MHD will stay with master thread and one connection thread waiting
>> for additional requests from same client.
>>> * Call MHD shutdown. Main thread will shutdown all sockets, but
>> additional connection thread will stay at MHD_sys_select_ and will get
>> notification about socket shutdown only after 2 minutes. May be it's
>> after libcurl will close connection.
>>> Again - have no idea how to fix it properly. Use pair of sockets
>> (emulated pipe) for each connection thread? Add daemon pipe FD to
>> select() in connection thread?
|
| |
|
|
|
|
|
|
|
|
| |
I was trying to use MHD_suspend_connection() and MHD_resume_connection() to implement long polling on a request. I am using options MHD_USE_SELECT_INTERNALLY and MHD_USE_POLL options. I noticed the server thread went to 100% CPU after the first MHD_resume_connection() call. Looking at the code in MHD_poll_all() I can see that the file descriptor from daemon->wpipe[0] gets inserted into the list of file descriptors to poll but this file descriptor is never read so every time this function is called it returns immediately. The code works fine if I drop to using just MHD_USE_SELECT_INTERNALLY.
The patch below fixes the problem.
Regards,
Denis
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
gnutls not even supported
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I am using libmicrohttpd in a multithreaded application in the
thread-per-connection mode. In order to maintain statistics and such on
the various clients, the application should be notified about
connections being started and stopped. Something like the
MHD_OPTION_NOTIFY_COMPLETED for requests, but then for connections. As
far as I could find libmicrohttpd does not (yet) provide that functionality.
Attached is a patch that does add this functionality by registering a
connection notification callback function: MHD_OPTION_NOTIFY_CONNECTION
(inspired by the MHD_OPTION_NOTIFY_COMPLETED option).
Could this be included in libmicrohttpd?
=>
The patch was only working for multithreaded apps, so I adjusted it
to cover other threading models, fixed a merge issue and added the
ability to associate a void* with the callbacks (and obtain it via
MHD connection info). And I updated the manual & ChangeLog. Now
I think it can be included ;-).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem using MHD_OPTION_HTTPS_MEM_DHPARAMS in MHD_OPTION_ARRAY
From:
Denis Dowling <Denis.Dowling@hsd.com.au>
Date:
02/26/2015 01:52 AM
To:
"libmicrohttpd@gnu.org" <libmicrohttpd@gnu.org>
Hi,
I was trying to add a Diffie Hellman key to the libmicrohttpd server using the MHD_OPTION_HTTPS_MEM_DHPARAMS option. I was putting this option into a vector and then passing this to MHD_start_daemon using the MHD_OPTION_ARRAY argument. This was failing and I tracked the problem down to a missing option in the switch statement in parse_options_va().
diff --git a/external/libmicrohttpd-0.9.39/src/microhttpd/daemon.c b/external/li
index 0816a4a..ce76a3b 100644
--- a/external/libmicrohttpd-0.9.39/src/microhttpd/daemon.c
+++ b/external/libmicrohttpd-0.9.39/src/microhttpd/daemon.c
@@ -3178,6 +3178,7 @@ parse_options_va (struct MHD_Daemon *daemon,
case MHD_OPTION_HTTPS_MEM_KEY:
case MHD_OPTION_HTTPS_MEM_CERT:
case MHD_OPTION_HTTPS_MEM_TRUST:
+ case MHD_OPTION_HTTPS_MEM_DHPARAMS:
case MHD_OPTION_HTTPS_PRIORITIES:
case MHD_OPTION_ARRAY:
case MHD_OPTION_HTTPS_CERT_CALLBACK:
Regards,
Denis
|
| | |
|
| |
|
|
| |
header was set
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Junker, Gregory" <gregory.junker@intel.com>
Date:
12/04/2014 12:30 AM
To:
"libmicrohttpd@gnu.org" <libmicrohttpd@gnu.org>
Hi all
I need a tiny addition made to connection.c.
In keepalive_possible(), can we change the line that says
if (0 == strcasecmp (end, "close"))
to
if (0 == strcasecmp (end, "close") || 0 == strcasecmp (end, "upgrade"))
?
This would make it possible to use libmicrohttpd in a WebSocket (RFC6455) environment. Currently, the way that the WebSocket protocol works, it sends "Connection: Upgrade" in the headers with the initial handshake, which causes this check to fail and (ultimately) insert "Connection: Keep-Alive" in the response headers (which cause any compliant WebSocket client to fail the handshake, since it needs "Connection: Upgrade" in the response headers, and there is no way to remove this keepalive header from the response from outside of MHD, as it is added automatically to the response buffer).
Note that this is only an HTTP/1.1 issue, AFAIK (I am pretty sure, though not positive, that WebSocket is not compatible with HTTP/1.0).
Thanks!
Greg
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the recently added MHD_DAEMON_INFO_CURRENT_CONNECTIONS can return quite
outdated values in MHD_USE_THREAD_PER_CONNECTION mode. The reason is
that closed connections are collected in MHD_cleanup_connections, which
is called only from the select thread. In the
MHD_USE_THREAD_PER_CONNECTION mode that happens only after accepting an
connection -- therefore, the last connection is always not collected and
MHD_DAEMON_INFO_CURRENT_CONNECTIONS returns >= 1, even when there are no
connections. That makes it very unusable to detect whether all
connections have been handled.
Would you consider the attached patch, which calls
MHD_cleanup_connections whenever MHD_DAEMON_INFO_CURRENT_CONNECTIONS is
called? It makes MHD_DAEMON_INFO_CURRENT_CONNECTIONS slower, but the
returned value is much more accurate.
Cheers,
Milan Straka
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I attach the first attempt on SO_REUSEPORT. The patch is available
either at https://github.com/foxik/libmicrohttpd/commit/9ce9422742e10458f87275ea202a982e00c2b88c
or attached. (It is against the version with
MHD_DAEMON_OPTION_CURRENT_CONNECTIONS, but I can rebase it to current
SVN HEAD if you want.)
It seems that a reasonably multiplatform way of detecting SO_REUSEPORT is
#ifdef SO_REPOSEPORT
which is used for example by Perl. For SO_EXCLUSIVEADDRUSE, the same
strategy seems to work too, according to Windows SDK headers and MinGW
WinAPI headers.
The current patch adds an option to allowing/disallowing address:port
reuse. One remark:
- currently both nonexisting SO_xxx and setsockopt failure are fatal and
MHD_start_daemon fails. That may be too harsh -- maybe the
MHD_OPTION_LISTENING_ADDRESS_REUSE should be only a hint.
Nevertheless, as one can freely not use
MHD_OPTION_LISTENING_ADDRESS_REUSE option, I chose the "fail on error"
behaviour.
Thanks,
cheers,
Milan Straka
Original patch modified to get rid of some redundant USE_DEBUG
checks, fix indentation, and #ifndef SO_REUSEPORT on Linux,
we try be #defining it to 15 ourselves.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Date: Wed, 29 Oct 2014 09:59:09 +0100
Subject: [PATCH 2/2] Add MHD_DAEMON_INFO_CURRENT_CONNECTIONS to
MHD_DaemonInfoType.
The MHD_DAEMON_INFO_CURRENT_CONNECTIONS returns number of current
connections handled by the daemon.
Useful after MHD_quiesce_daemon to find out whether all connections
have been served.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
have open connections
|
| |
|
|
| |
response to add extra headers, only add them into the connection output buffer
|
| | |
|
| |
|
|
| |
call to MHD_run (see mailinglist)
|
