Hello,
I have updated "0.9.53" to GIT - maybe a week ago.
There is a recursive lock to "daemon->cleanup_connection_mutex"
__owner=6065 holds the lock - but tries to lock again in
"connection.c:2837"
The callstack:
"resume_suspended_connections()" at daemon.c:2908
"MHD_conne
Dear Evgeny,
Maybe because the request-headers contain "Connection: close"?
This is what I could determine with `gdb`:
(gdb) frame 4
(gdb) p *connection->headers_received
GET / HTTP/1.1
Host: server.name
Connection: close
Content-Length: 4
Accept-Encoding: gzip
Accept: */*
Content-Type: application
Thanks a lot!
Best wishes
Am Sonntag, den 21.05.2017, 18:58 +0300 schrieb Evgeny Grin:
> IE 4.01 on Win95? Cool. :)
>
> Should be fixed in master.
> Could you check it?
>
Hello,
I have a problem with this commit:
https://github.com/Karlson2k/libmicrohttpd/commit/b93ddc6b5ebb76fbe0a4b
eb73901ad2c4c7e8ca8#diff-c5e0aecb44767e9dda5a88f49b24a3c5
void NotifyConnectionCallback( ... )
{
const union MHD_DaemonInfo *daemoninfo = MHD_get_daemon_info(
daemon, MHD_DAEMON_I
A cosmetic change:
Configured:--enable-https=no
Could you shield this line with an "#ifdef HTTPS_SUPPORT"?
File:mhd_send.h
#include "connection_https.h"
Weitergeleitete Nachricht
Von: Christian Grothoff
Antwort an: libmicrohttpd development and user mailinglist <
lib
When passing a unix-socket to MHD via 'MHD_OPTION_LISTEN_SOCKET':
Every request alerts this message from daemon.c:3266 (called from
daemon.c:4515)
MHD_DLOG (daemon,
_ ("Failed to disable TCP Nagle on socket: %s\n"),
MHD_socket_last_strerr_ ());
Weiterg
Hello,
Is there a reliable way to detect 'continution' in
'MHD_PostDataIterator()'?
To detect the beginning of a new variable I have tested: 'off == 0'.
But this is not reliable. It is a rare case but sometimes the iterator
stops right
before the first content-byte (if helpful I will provide a tes
ack, asyou say). It's an interesting corner case, which we
may want to documentand/or fix in the v2.0 API -- unless someone has a
good proposal for howto do address this case in a binary-API compatible
way.
Happy hacking!
Christian
On 4/21/20 4:17 PM, Markus Doppelbauer wrote:
> Hello,
> Is
t's an interesting corner case, which we
may want to documentand/or fix in the v2.0 API -- unless someone has a
good proposal for howto do address this case in a binary-API compatible
way.
Happy hacking!
Christian
On 4/21/20 4:17 PM, Markus Doppelbauer wrote:
> Hello,
> Is there a reliable
I think this patch was wrong.
The post-processor fails to parse url-encoded post-data.
A testcase is attached: The value of should be .
Best wishes
Markus
Weitergeleitete Nachricht
Von: Christian Grothoff
Antwort an: libmicrohttpd development and user mailinglist <
li
'MHD_queue_basic_auth_fail_response()' should also return 'enum
MHD_Result'
Best wishes
Weitergeleitete Nachricht
Von: Christian Grothoff
Antwort an: libmicrohttpd development and user mailinglist <
libmicrohttpd@gnu.org>
An: libmicrohttpd
Betreff: [libmicrohttpd] libmicrohttp
There is a second issue parsing url-encoded post requests.
I have attached a testcase (same ugly code as last time).
"text" should be "text, text" not "text%2C text".
Best wishes
Weitergeleitete Nachricht
Von: Christian Grothoff
Antwort an: libmicrohttpd development and user m
> In the future, it would be better to preserve the API, and maybe add
> new named functions instead of this sort of thing.
Disagree. Code duplication must be avoided.
Otherwise it creates a huge mess.
ohttpd] libmicrohttpd 0.9.71 releasedDatum: Fri, 10 Jul
2020 15:08:47 +0200
Fixed in 8c773704..9b39de8d. Thanks for reporting! -Christian
On 7/6/20 7:15 PM, Markus Doppelbauer wrote:
> There is a second issue parsing url-encoded post requests.I have
> attached a testcase (same ugly code as last
Hello,
The percent-encoded post-processor (current git ) segfaults.
ASAN reports: global-buffer-overflow
A testcase is attached.
Best wishes
Markus
Weitergeleitete Nachricht
Von: Christian Grothoff
Antwort an: libmicrohttpd development and user mailinglist <
libmicrohttpd@gn
leased
Datum: Fri, 11 Sep 2020 22:09:46 +0200
Hi Markus,
Thanks for reporting, fixed in c7fce141..16c13329.
Happy hacking!
-Christian
On 9/11/20 2:04 PM, Markus Doppelbauer wrote:
> Hello,
> The percent-encoded post-processor (current git ) segfaults.ASAN
> reports: global-buffer-overfl
> ... because valgrind point out ...
You should replace (slow) valgrind with (fast) address-sanatizer.
Simply tell GCC (or clang) to compile with: -fsanitize=address -fno-
omit-frame-pointer
Since a websocket handshake hashes only 16 bytes you don't need an
implementation that provides incremental updates. The attached SHA1
is slower than the openssl implementation, but quite short.
Just in case.
Weitergeleitete Nachricht
Von: "Gausmann, David"
Antwort an: libmicro
> + Added '--enable-sanitizers[=address,undefined,leak,user-poison]'
>configure parameter (instead of '--enable-sanitizer'),
>implemented custom memory poisoning for memory pools.
We get strange asan aborts (maybe once per 30min):
ERROR: AddressSanitizer: use-after-poison on address 0xd
fixed by
https://git.gnunet.org/libmicrohttpd.git/commit/?id=1a46bfd6e0929e2004ffda318282cbf21d9f5299
Please check whether it fixed the issue for you.
-- Evgeny
On 07.03.2022 20:11, Markus Doppelbauer wrote:
> > + Added '--enable-sanitizers[=address,undefined,leak,user-poison]&
Hello,
Is there some benefit using 'mmap()' in 'memorypool.c' instead
'malloc()'?
It somehow pollutes VRAM - inspecting with: `pmap -x `
(even if we have plenty of VRAM on x64)
Best wishes
Markus
actual problems
withthe current situation, or is this "cosmetic" because your pmap
output islong-ish?
Happy hacking!
Christian
On 3/10/22 11:36, Markus Doppelbauer wrote:
> Hello,
> Is there some benefit using 'mmap()' in 'memorypool.c' instead
> 'malloc(
Hi,
Investigating some long-living CLOSE_WAIT connections.
Question: Since MHD uses "edge triggered" behavior (EPOLLET), maybe MHD
should
also set the EPOLLRDHUP flag?
Thanks a lot!
Markus
Should be quite easy to investigate:
gdb -p
> info threads
> thread 1
> bt
Am Samstag, dem 14.01.2023 um 13:31 +0100 schrieb klemens:
>
> Hi all,
>
> I'm struggeling with MHD_USE_POLL. Starting the daemon on debian8 with
>
> daemon = MHD_start_daemon ( MHD_USE_INTERNAL_POLLING_THREAD
Hello,
Is there a chance to make chunked transfer encoding
work out of the box in libmicrohttpd?
https://en.wikipedia.org/wiki/Chunked_transfer_encoding
Thanks a lot
Markus
HTTP 1.1) and necessary (i.e. unknown response size).
>
> Happy hacking!
>
> -Christian
>
> On 06/21/2015 05:29 PM, Markus Doppelbauer wrote:
> > Hello,
> >
> > Is there a chance to make chunked transfer encoding
> > work out of the box in libm
Hi Christian,
Thanks a lot for your answer.
Your software is superior (all the "alternatives" from your website
are not fit to hold a candle to you).
Greetings from Austria!
Markus
Am Montag, den 22.06.2015, 10:42 +0200 schrieb Christian Grothoff:
> On 06/22/2015 09:41 AM, Marku
Hello,
Most of the examples contain the comment:
/* do never respond on first call */
Is this a strict rule? If not, what is the reason?
Thanks a lot!
Markus
Hello,
Is it allowed/safe to suspend a connection via
"MHD_suspend_connection()" inside a
"MHD_ContentReaderCallback()" handler?
I am asking because
a) the docs say:
"The only safe time to suspend a connection is from the
MHD_AccessHandlerCallback."
b) the "MHD_ContentReaderCallback()" d
Hello,
The header "microhttpd.h" misses:
#define MHD_HTTP_HEADER_CONTENT_DISPOSITION "Content-Disposition"
Thanks a lot
Markus
Hello,
I think there is a race condition and I have no clue how to fix it:
Main-Thread calls "MHD_quiesce_daemon()"
Main-Thread sleeps until last connection is closed
Poll-Thread wakes up the Main-Thread from "MHD_OPTION_NOTIFY_CONNECTION"
because of "MHD_CONNECTION_NOTIFY_CLOSED"
Main-Thread
Hello,
If I add http-headers to a response via "MHD_add_response_header()", the
headers are written in reverse order - first in last out. Is there a
special
reason?
Thanks a lot
Markus
Hello,
Maybe there is a race condition between suspending/resuming connection.
This happens only if I use "poll()" - not with "epoll()". Requests were
created using "wget" (http 1.0) - one after the other.
What I did:
The MHD-Thread calls "MHD_suspend_connection()" inside
"MHD_ContentReaderCallb
Hello,
Sometimes I get some segfaults - after calling "MHD_quiesce_daemon()".
My setup:
MHD with epoll parses requests from a http-socket - and fills a queue.
A worker thread takes the requests from the queue and fills the buffer.
After 'quiesce()' the worker threads checks on every requests if th
Hello,
Maybe simply nullify "pos->pool" after MHD_pool_destroy()"?
Should avoid this double-free().
Or is there a chance to get the number of open connections
without calling "MHD_cleanup_connections()"?
Thanks a lot
Markus
}
}
MHD_pool_destroy (pos->pool);
+
Hello,
Maybe simply nullify "pos->pool" after free()?
Thanks a lot
Markus
}
}
MHD_pool_destroy (pos->pool);
+ pos->pool = NULL;
#if HTTPS_SUPPORT
if (NULL != pos->tls_session)
gnutls_deinit (pos->tls_session);
quot;MHD_cleanup_connections()"
in "MHD_DAEMON_INFO_CURRENT_CONNECTIONS".
Thanks a lot
Markus
Am Donnerstag, den 16.07.2015, 22:13 +0200 schrieb Markus Doppelbauer:
> Hello,
>
> Maybe simply nullify "pos->pool" after MHD_pool_destroy()"?
> Should
cribe, it could cause non-termination to not call cleanup).
>
> Now, the MHD_pool_destroy in connection.c, that one should be truly
> harmless to remove, so you could safely play with that...
>
>
> Happy hacking!
>
> -Christian
>
> On 07/17/2015 09:57 AM, Marku
Hi,
Maybe it is not allowed to call
MHD_get_daemon_info( MHD_DAEMON_INFO_CURRENT_CONNECTIONS )
at any time from any thread? Maybe only from
MHD_NotifyConnectionCallback() ?
Thanks a lot
Markus
Am Samstag, den 18.07.2015, 17:18 +0200 schrieb Markus Doppelbauer:
> Hi,
>
> Sorry
Doppelbauer:
> Hi,
>
> Maybe it is not allowed to call
> MHD_get_daemon_info( MHD_DAEMON_INFO_CURRENT_CONNECTIONS )
> at any time from any thread? Maybe only from
> MHD_NotifyConnectionCallback() ?
>
> Thanks a lot
> Markus
>
>
>
> Am Samstag, den 18.07.2015,
Great! Thanks a lot.
Markus
Am Mittwoch, den 16.09.2015, 11:28 +0200 schrieb Christian Grothoff:
> Dear all,
>
> I'm happy to announce the release of libmicrohttpd 0.9.43, which
> is mostly a bugfix release.
>
> GNU libmicrohttpd is a small C library that is supposed to make it easy
> to run a
Hello,
Thanks a lot.
For me, 0.9.49 does not work - it never enters the
"AccessHandlerCallback()" handler. I have attached
a small testcase.
Steps to reproduce:
g++ -o testmhd test.cpp -I/tmp/libmicrohttpd-0.9.49/src/include/
-L/tmp/libmicrohttpd-0.9.49/src/microhttpd/.libs/ -lmicrohttpd
LD_LIBRA
ot; work. Maybe he went a bit overboard,
> I
> certainly agree that _if_ there was a change like that it probably
> was
> unintentional and should have been avoided.
>
> Evgeny: could you check, and re-add the logic to make the listen
> socket
> explicitly non-blocking also IF
Hello,
Maybe there is an other issue in 0.9.49. It works with 0.9.48.
The attached testcase tries to:
a) create a socket on port 8080
b) a connection is suspended
c) a thread waits a second, then resumes the connection
d) error: the connection is never resumed (third call).
OS: Ubuntu gnome 15.10,
Hi Evgeny,
Great code!!
Thanks a lot!
Markus
Am Donnerstag, den 14.04.2016, 13:28 +0300 schrieb Evgeny Grin:
> On 13.04.2016 12:18, Markus Doppelbauer wrote:
> > Maybe there is an other issue in 0.9.49. It works with 0.9.48.
> >
> > The attached testcase tries to:
> >
Hello,
It seems that there is an other issue (is neither works with 0.9.48):
a) The connection creates a "callback" response
b) The connection is suspended after every byte - then resumed (by a
thread)
c) The daemon get stalled after 33 requests
I have attached a small testcase.
Commandline:
g++
Sorry - wrong testcase. The attached is the proper one.
Am Donnerstag, den 14.04.2016, 13:55 +0200 schrieb Markus Doppelbauer:
> Hello,
>
> It seems that there is an other issue (is neither works with 0.9.48):
> a) The connection creates a "callback" response
> b) Th
Hello,
You are right. But there is an issue (at least on Linux). It works with
"MHD_USE_EPOLL_LINUX_ONLY" - but not with "select()"/"poll()".
Sooner or later the daemon gets stalled. Maybe a race condition?
I have attached the patched testcase.
Thanks a lot!
Markus
Am Donnerstag, den 14.04.2016, 1
Hi Evgeny,
I am deeply impressed. I rather die than to search
this kind of bug... You are an excellent engineer.
Markus
Am Montag, den 18.04.2016, 22:45 +0300 schrieb Evgeny Grin:
> Markus,
>
> Thanks again for report and test.
> Should be fixed in SVN 37052.
>
> On 14.04.
Yes it does.
Thanks a lot!
Am Dienstag, den 19.04.2016, 00:26 +0300 schrieb Evgeny Grin:
> Thanks, Markus!
> Did it really fix bug for you?
>
> On 18.04.2016 22:57, Markus Doppelbauer wrote:
> > Hi Evgeny,
> > I am deeply impressed. I rather die than to search
> >
Hi Christian,
Thanks a lot. A small issue: I can't build the lib with
"./configure --disable-messages"
daemon.c: In function ‘MHD_accept_connection’:
daemon.c:2088:23: error: ‘err’ undeclared (first use in this function)
if ( (EMFILE == err) ||
^
daemon.c:2088:23: not
The daemon could run into an infinite loop if used I use
"poll" (no issue with epoll).
The backtrace:
#0 0x003d912df283 in __poll (fds=,
nfds=, timeout=) at
../sysdeps/unix/sysv/linux/poll.c:87
#1 0x00455e4b in MHD_poll_all (daemon=0x2bd48f0,
may_block=) at microhttpd/daemon.c:2645
#
Great! Thanks a lot! A small patch to remove the "unused 'urh'-
variable" warning if
compiled without https-support:
*** daemon.c-old 2016-10-17 19:07:46.0 +0200
--- daemon.c 2016-10-17 21:10:59.969913792 +0200
*** process_urh (struct MHD_UpgradeResponseH
*** 1151,11
I am getting a MHD panic (from daemon.c:5257):
"Failed to add inter-thread communication channel FD to epoll set to
signal termination"
This happens after calling "MHD_quiesce_daemon()".
Thanks a lot!
Marcus
Am Montag, den 17.10.2016, 19:21 +0200 schrieb Christian Grothoff:
> Dear all,
>
>
> I'm
s release is mostly experimental, we need to stabilize new
> functionality.
> New API may also will be slightly changed.
>
> Please report about all rough edges, especially on non-GNU/Linux
> platforms.
>
> --
> Best Wishes,
> Evgeny Grin
>
> On 17.10.2016 22:36, M
Hello,
Is the "protocol upgrade" API finalized? I can live with that, but this
way I need a second event loop. I would prefer an API where the MHD
event loop waits for websocket-data and - if new data arrives - calls
a handler. Something like:
MHD_SocketHandle *
MHD_create_response_for_upgrade(
t
loop? So that MHD could tell me if data arrives?
Thanks a lot!
Markus
Am Sonntag, den 13.11.2016, 21:39 +0100 schrieb Christian Grothoff:
> On 11/13/2016 08:47 PM, Markus Doppelbauer wrote:
> >
> > Hello,
> >
> > Is the "protocol upgrade" API finalized
Dear Evgeny,
Thanks a lot for your answer.
I will have to live with this API - but I don't like it. A great API
would be
something similar to "MHD_create_response_from_callback()" and
"suspend/resume_connection()".
But I understand that this is very difficult to implement.
Maybe I am wrong, but thi
Dear Evgeny,
> The best what MHD could do with "upgraded" sockets - is
> to forward data to application and back to remote.
Yes - as much as data until the socket blocks. And it
should hide everything else from the application, e.g.
"sha1('Sec-WebSocket-Accept')".
Is is easy to figure out, whether
All major browser support Websockets nowadays so it would be a
great step ahead.
My skills are limited when it comes to low level programming, so
my estimation could be wrong: But if it is only a small piece of
code maybe it would be useful to be integrated in MHD.
>From a user perspective I would
Current git does not compile without "HAVE_MESSAGES":
This is the context in "daemon.c":
if ( (0 != (daemon->options & MHD_USE_THREAD_PER_CONNECTION)) &&
(MHD_NO != ret) )
{ /* Wake up suspended connections. */
if (! MHD_itc_activate_(daemon->itc,
What was your issue? How did you fix it?
I am getting "Assertion failed" from "connection.c:6864": case
MHD_CONNECTION_CHUNKED_BODY_UNREADY:
mhd_assert (0);
This happens if I create a response from callback, e.g.:
struct MHD_Response *response = MHD_create_response_from_callback(
MHD_SIZE
kus,
> Can you share a larger piece of code or give more details, like used
> mode (internal polling or external polling), polling function, other
> relevant information?
> -- Evgeny
> 27-Feb-2024 17:58 (UTC+0100), Markus Doppelbauer via libmicrohttpd
> wrote:
> > What was you
63 matches
Mail list logo
