On 03/18/2017 01:44 AM, John Duncan wrote:
> Websockets and RFC6455. I noticed the test_upgrade.c unit test code
> doesn't provide the accept handshake key combination hashing specified on
> page 8 of the RFC, in the section "opening handshake."
>
> Apparently we're supposed to combine the websoc
glibc < 2.17 requires -lrt for clock_gettime(), older versions do not.
I've added "-lrt" in Git commit ed6509bf6ca46e39e3514680bfb81216e2a825bf
but without testing (as I don't have an ancient glibc on this system and
I am on a train...). Please let me know if it does not work...
Happy hacking!
C
On 03/17/2017 01:10 PM, Vitaliy T wrote:
> Hello,
>
> On 17 March 2017 at 10:03, Evgeny Grin wrote:
>> Please note that even if you suspend connection, you must process at
>> least some data (preferably - all data) and decrement value of
>> 'upload_data_size'.
>
> Yes, this was my mistake. Befor
On 03/26/2017 10:36 PM, Evgeny Grin wrote:
> On 26.03.2017 8:33, silvioprog wrote:
>> I found the following related message:
>>
>> https://lists.gnu.org/archive/html/libmicrohttpd/2014-09/msg00012.html
>>
>> I've used a similar logic, but with item X below, because I need to wait
>> the client proc
On 03/27/2017 08:03 PM, Alex Reynolds wrote:
> I have an API that reads a subset of data from an archive and writes it to
> a FILE*. I can use this API to write this data subset to a temporary file
> via mkstemp() and fdopen().
>
> I am currently using MHD_create_response_from_callback() to read c
Hi John,
You're expected to pass data via "cls", you have no influence on
"extra_in". "extra_in" is there in case MHD "accidentally" read already
more data than the HTTP header from the Web socket, thereby making it
available to you (you are to treat it as if you read it from 'sock').
So in your
Jose,
Have you considered doing
if upgrade-requested-for(req) then
my_cls = create-websocket-for(req)
if my_cls created then
MHD_create_response_for_upgrade (&my_handler, my_cls);
else
reply "internal error"
end
else
end
Basically, use the
Hi John,
The raw request data is unavailable as MHD processed it in-place
(zero-copy!) to give the parsed headers to the application.
However, it should be relatively easy to modify MHD to just return the
number of bytes in the header, if that would be sufficient?
Happy hacking!
Christian
On 0
You forgot to update doc/libmicrohttpd.texi, otherwise looks OK even
though I'm not convinced SHUTDOWN/QUESTCED are useful: an application
can trivially track those itself, so these two are definitively just API
bloat.
On 05/04/2017 03:59 PM, silvioprog wrote:
> Done. So dudes, what do you think a
On 05/07/2017 09:20 PM, Nicolas Mora wrote:
> Hello,
>
> I'm still working on a websocket implementation based on MHD, the non
> secure websocket works fine, but the secure websocket doesn't work yet.
>
> I'm having problems with the socket and the tls session. I get my
> inspiration from the tes
On 05/07/2017 10:20 PM, Nicolas Mora wrote:
>
> Any I retried it without any gnutls call on the MHD_sock and I still
> have problems reading and writing the socket, nothing is transmitted,
Hmm. Try 'strace' on IO operations (only, i.e. "strace -e
trace=network,ipc,desc"). When you 'send' to the
Dear John,
Just wanted to let you know that this has now been implemented.
See:
https://gnunet.org/git/libmicrohttpd.git/commit/?id=76cf7d7f5877a3ce0f3bb131aa6e6f420d5b98eb
Happy hacking!
Christian
On 04/26/2017 12:02 AM, John Duncan wrote:
> That would be great, thanks!
>
0xE29FC3CC.asc
De
Hi,
Sleeping in THREAD_PER_CONNECTION mode is fine --- if you want to really
just throttle the response generation and basically create latency.
-Christian
On 05/19/2017 12:22 AM, Miguel Sancho wrote:
> Hi,
> using the MHD_USE_THREAD_PER_CONNECTION mode,
> are there any issues in "sleeping" the
Hi Miguel,
There are two contexts, the "socket context" and the "request context".
The access handler is given the "request context", to get the socket
context there we would have to extend the MHD_get_connection_info() API
to allow you to get it during the access handler. I guess that's an
overs
Sorry, was mistaken, the API does already exist as it should. The
argument you need to pass is aptly named:
MHD_CONNECTION_INFO_SOCKET_CONTEXT.
-Christian
On 06/01/2017 05:33 PM, Christian Grothoff wrote:
> Hi Miguel,
>
> There are two contexts, the "socket context" and t
On 06/02/2017 04:23 PM, Miguel Sancho wrote:
> Christian, thanks for your answer,
> I need to recheck, already doing the following in the
> #MHD_AccessHandlerCallback and the *socket_context appears to be NULL:
> /MHD_get_connection_info(connection,MHD_CONNECTION_INFO_SOCKET_CONTEXT);/
>
> Regards
On 06/05/2017 06:01 PM, Miguel Sancho wrote:
> Christian,
>
>> Eh, what is that "*" doing in the "if" line?
>
> reason is that in definition of the MHD_ConnectionInfo union, I see
> socket_context defined as "void**", maybe it should be just "void*"
It is indeed "void *" in more recent versions
Maybe I missed something, but why should the MHD dependency become
_mandatory_? Why not conditionally-compile and run the tests only if MHD
is present? MHD does the same for libcurl. Making the dependency
optional also avoids the obvious possibility of circular dependencies if
we ever were to add
On 06/13/2017 05:42 AM, Didik Setiawan wrote:
>- Last check failed when the test try to resolve URL with question mark.
> E.g: "/subdir1/subpage1.html?query¶m", when I debug, it return just
> "/subdir1/subpage1.html" so the result is 404 not found. I also check
> using
> logging
MHD_create_response_from_callback() is the API you are looking for.
src/examples/chunked_example.c (and various others) is one example for
how this API is used. Admittedly, it's not in the tutorial (yet), and I
agree it would be good to add it.
On 06/18/2017 10:38 AM, Alex Reynolds wrote:
> I have
On 08/21/2017 07:25 PM, silvioprog wrote:
> Hello duddes. :-)
>
> I'm very exited with this news and I'm following each new commit. I
> would be glad to read these discussions because I've learned a lot with
> them.
Well, to be honest I am more frank (both in terms of admitting that I'm
wrong as w
Thanks, fixed now (sorry for the delay, was on the move). -Christian
On 07/20/2017 07:42 AM, Allan Wind wrote:
> https://github.com/criticalstack/libevhtp
>
>
> /Allan
0xE29FC3CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Hi Avner,
We never supported 'gcrypt-only'. We always required GnuTLS, just some
very long time ago we tried to include parts of the GnuTLS code with
MHD. However, that version never worked well with HTTPS/TLS, so it is
definitively not advisable to go there. If you cannot build GnuTLS, you
could
On 09/13/2017 07:18 PM, Avner Flesch wrote:
> Hi,
>
> Thanks for the answer.
> Anyway I did it and manage to build libmicrohttpd with HTTPS
> but, I get a core dump in MHD_start_daemon (only with HTTPS support)
> Now I am checking maybe something is wrong with my arguments, but
> another direction
Fixed, thanks for reporting! -Christian
On 09/27/2017 11:17 AM, Maru Berezin wrote:
> Hello, in commit 243e8fcd6054e4c0d2964b0d4b29e0c15861498d (5 Jun 2017), the
> definition of MHD_TLS_CONNECTION_INIT was deleted.
>
> Please find attached a patch.
>
> Regards,
> maru
>
signature.asc
Descri
Great. Please inform the developer mailinglists of GNU nettle and GnuTLS
about the regression(s).
On 09/29/2017 03:24 PM, Svein Olav Bjerkeset wrote:
>> But I suspect that problem comes from outdated RHEL5 GnuTLS lib.
>> MHD on git master is able to use modern GnuTLS without gcrypt. As next
>> ste
Well, I'm pretty sure there is nothing _wrong_ about your code. The MHD
API doesn't actually specify whether it will call you one last time
before the timeout, but what happens right now is that the timeout
triggers the select() to unblock, and MHD goes over all "pending"
connections, and _afterwar
Hi Tim,
We definitively don't have MHD_free() today.
I'm not aware of any API call where MHD returns a pointer to the
application that the application is expected to free.
There is one case in reverse, where for a response the application can
give a pointer to MHD which MHD will then free(), nam
On 10/09/2017 07:24 PM, Tim Rühsen wrote:
> Hi Christian,
>
> On Montag, 9. Oktober 2017 17:46:32 CEST Christian Grothoff wrote:
>> Hi Tim,
>>
>> We definitively don't have MHD_free() today.
>>
>> I'm not aware of any API call where MHD returns a p
Ok, added and documented in 181ac3c5..6c4c13ef. -Christian
On 10/09/2017 09:41 PM, Tim Rühsen wrote:
> No better way comes to my mind. Most C libraries have a similar function out
> of the same reason. It would be consistent to have it as well.
> Think of gnutls_free, idna_free, idn2_free, psl_fr
Hi Gauthier,
I agree with Evgeny, good job. However, there is one (modest) change I
would like to see, which is that the TLS backend(s) should be loaded via
dlopen()/dlsym()/libltdl instead of hard-linked with MHD. That way, we
could actually have one "libmicrohttpd.so" binary installed and the
ap
Hi,
Might it be that you are using 'select()' in your event loop? (The rest
of the answer does not apply if you do not, but it is almost certain
that this is your problem). There, the FD_SIZE limit applies (not just
the ulimit), so once you hit near 1000 FDs open from mmap, the server
won't be ab
Yes, that is exactly what I would like to see, and AFAIK Evgeny has
started to hack on it.
-Christian
On 10/25/2017 04:20 PM, Gauthier Haderer wrote:
> Hi Christan,
>
> I'm not sure I really understand your point.
>
> Regarding the detection of TLS backend's availability, one can use the
> func
Eh, no, microhttpd2.h has _nothing_ to do with HTTP 2.0. It is simply
about building a better interface for the existing HTTP 1.x.
In fact, I personally do not have plans to work on HTTP 2.0-support.
Happy hacking!
Christian
On 10/26/2017 01:23 AM, silvioprog wrote:
> Hi Yuyong.
>
> An interfa
You could use MHD_CONNECTION_INFO_CONNECTION_FD to obtain the socket of
a client, and then call poll/select/epoll on that yourself. Running
'recv' is likely to have unintended side-effects ;-).
Happy hacking!
Christian
On 11/02/2017 08:40 AM, Andrew Oseredchuk wrote:
> Hello,
>
> Im writing se
Dear all,
I'm glad to announce the release of GNU libmicrohttpd 0.9.56.
GNU libmicrohttpd is a small C library that is supposed to make it easy
to run an HTTP server as part of another application. GNU libmicrohttpd
is fully HTTP 1.1 compliant and supports IPv6. Finally, GNU
libmicrohttpd is fast
Eh, yes.
Should be fixed in 98cd69d1..867c58ad, please report if not.
Happy hacking!
Christian
On 01/03/2018 12:10 PM, Tim Rühsen wrote:
> Hi,
>
> I see these annoying from the user-included file libmicrohttpd.h (latest
> git master). Could you fix it, please ?
>
> /usr/oms/src/wget2/x86_64-w
Dear all,
Please contribute ideas for GSoC students (especially those you might be
able to supervise) around GNU libmicrohttpd.
We should collect first on the mailinglist and then send the finished
HTML to Guiseppe.
Happy hacking!
Christian
Forwarded Message
Subject:
Hi Pascal,
There are several "limits" that may apply.
(1) MHD_OPTION_CONNECTION_LIMIT -- usually 1020 (or FD_SETSIZE - 4) is
likely the first one you may hit. You can pass a different value to
MHD_start_daemon() in the varargs;
(2) FD_SETSIZE is another limit you are likely to hit if yo
-1 can be *normal*, as MHD calls 'accept()' (possibly via multiple
threads when using a thread pool) until there are no more clients. You
should check what errno says.
Also, in case accept4() is buggy on your platform, it is an
optimization; so you could #undef HAVE_ACCEPT4 if accept() +
setsocko
Hi Moritz,
Removing tabs might be desirable, but this patch destroys indentation
(see stark example below), which is not.
My 2 cents.
Happy hacking!
Christian
On 01/24/2018 02:23 PM, Moritz Warning wrote:
>if (url == NULL)
> {
> - MHD_stop_daemon (d);
> - return 16;
> + MHD
Hi silvioprog,
One of the issues was clearly real (fixed in Git), the other three I
don't get. Looking at the code, the flag can clearly go in either
direction, and the incremented dest pointer cannot be NULL (was checked
just a few lines above).
Regardless, running such tools is always a good i
Hi Jan-Benedict,
This is very strange, the loop should not fix this, as pthread_join
should simply block (not race!) until the thread is done. In fact, I
generally think the right answer to ESRCH would be to die, as to me this
indicates some kind of memory corruption or other severe invariant
vio
On 02/04/2018 03:19 AM, lingweicai wrote:
> Dear all:
>
> I want to create responses with strings variables, for example , html
> start tag, html title, css, js, head1, content, html end tag , etc.
>
> Can I use this callback function instead of
> MHD_create_response_from_buffer?
In principle yo
Hi,
Build issue should be fixed in Git now.
IIRC, our CI (Buildbot) is not (yet) setup to build with clang, but also
it doesn't send out proper notifications on failures in the first place,
so it is right now of limited use.
Help with setting up better CIs would always be welcome, albeit I
perso
On 02/21/2018 12:15 PM, Tim Rühsen wrote:
>> Generally, I would like
>> to end up with a setup where the entire CI configuration is also in a
>> Git repo and can be easily collaboratively improved. So if you have time
>> and energy to make that happen, great ;-)
>
> Gitlab allows exactly that, bu
lways print the first entry of my circle queue. Can I assign the
> next pointer of
> "cls = cq_user_ptr->entries.cqe_next ; "
>
> to re-callback the crc ? it looks this does not work. how can I transfer
> the "next pointer" of my list as the parameter to the nex
These should be fixed (largely warnings about memory leaks in testcases,
one relating to an actual issue with MHD not calling connection
completed handler for upgraded connections).
Happy hacking!
Christian
On 02/27/2018 10:18 AM, Tim Rühsen wrote:
> Hi,
>
> two tests still fail because of memo
Fixed in Git f4154e6b..4507f419. -Christian
On 02/27/2018 10:30 AM, Tim Rühsen wrote:
> Two more usages of strcpy() annoy the clang static analyzer:
>
> $ make clean
>
> $ scan-build-3.9 -v -enable-checker security,nullability --status-bugs
> make -j$(nproc)
>
>
> With Best Regards, Tim
>
>
Merged, but applied small additional correction as I do not want the new
headers to be installed in systems yet (too early).
Happy hacking!
Christian
p.s.: I'm aware of the test_upgrade test failure, it's tricky, so will
take a bit more time to fix properly.
On 02/28/2018 11:55 AM, Tim Rühsen wr
Try casting the 8*1024*1024 to a "size_t" explicitly. I suspect on your
Mac-Machine, you have maybe a 64-bit size_t and then things go very
wrong if you pass a 32-bit argument.
Note that the microhttpd2-API that I've started to hack on is supposed
to categorically eliminate such API-usage bugs, bu
Should be implemented in 785ae52b..5717a9ec, feedback welcome... -Christian
On 03/01/2018 09:21 AM, Tim Rühsen wrote:
> Hi,
>
> could MHD_OPTION_STRICT_FOR_CLIENT be more strict regarding spaces in
> the 'resource' of HTTP requests, please ?
>
> Currently MHD accepts spaces (instead %20 resp. +)
Should be fixed now. Tough one, fortunately unlikely to affect most
people: for some threading models, upgraded connections didn't call the
per-request clean up function, and for all multi-threaded models during
daemon stop, we might call the per-request clean up function for
not-yet-finished conne
On 02/27/2018 10:39 AM, Tim Rühsen wrote:
> $ CC=gcc CFLAGS="-O0 -g -ggdb3 -fno-omit-frame-pointer
> -fsanitize=undefined" ./configure
>
> $ make clean
> $ make check
> $ grep runtime src/*/*.log
>
> src/microhttpd/test_upgrade.log:test_upgrade.c:1075:32: runtime error:
> member access within mis
Might be fixed in f60a569e..a7b25581, please let me know if not (or
rather Evgeny, as he'll know better what to do ;-)).
Happy hacking!
Christian
On 03/04/2018 10:34 AM, Tim Ruehsen wrote:
> Hi,
>
> just saw that the wget2 MinGW build breaks since a while. Could you
> have a look ?
>
> With Be
On 03/04/2018 12:47 PM, Tim Ruehsen wrote:
> Am Sonntag, den 04.03.2018, 11:40 +0100 schrieb Christian Grothoff:
>> Might be fixed in f60a569e..a7b25581, please let me know if not (or
>> rather Evgeny, as he'll know better what to do ;-)).
>
> Thanks, the reporte
Dear Bob,
I've analyzed your code, and the issue is on your end: you simply didn't
set the timeout correctly. When using an external event loop, it is
mandatory that you ask MHD for the timeout using MHD_get_timeout() and
use that with select/poll/epoll. Then, you must call MHD_run() once
wheneve
ched patch? It adds one line to the docs that I'm quite sure
> would have pointed me in the right direction had it been there before.
>
> Thanks!
> Bob
>
> On Sun, Mar 11, 2018 at 1:11 PM, Christian Grothoff
> wrote:
>>
>> Dear Bob,
>>
>> I&#x
2018 at 2:11 PM, silvioprog wrote:
>> Hello dudes.
>>
>> It would be nice to attach this example (or Christian's explanation) in
>> MHD's docs/examples. :-)
>>
>> Thank you!
>>
>> On Sun, Mar 11, 2018 at 2:11 PM, Christian Grothoff
>>
appears that the commit
>
>>> commit 0ebdff94d461abd4328cf45a6281c15139a045eb
>>> Author: Christian Grothoff
>>> Date: Fri Mar 2 21:45:17 2018 +0100
>>>
>>> fix test_upgrade transient failures (#5189)
>
> introduces the change.
>
> Before
Changing 'long long' will break ABI compatibility. So this is not
something you want to do for a mere warning in response to you trying
out compiler flags to try settings nobody has needed for 20+ years.
On 03/24/2018 04:30 AM, silvioprog wrote:
> Christian,
>
> I'm using the following compilers:
On 03/25/2018 04:05 AM, silvioprog wrote:
> Hello.
>
> I'm going to create a new project from scratch that uses MHD as main
> HTTP library, so I'm free to choose a new API. However, I have some
> questions that may help me to choose between microhttpd.h and microhttpd2.h:
>
> * can I use the new
Dear Marek,
Thanks for your report. As for the "test_options" failure, I wonder
what happens on Solaris 10 if you "bind()" a socket to the port 0.
Given the error message, it seems that the semantics are different from
those on other platforms: on GNU/Linux, bind()ing to 0 means "pick a
random fr
On 04/29/2018 03:14 PM, Austin Einter wrote:
> Dear All
> I am very new to libmicrohttpd.
> I am planning to use libmicrohttpd in one of my project.
>
> I have basic two questions
>
> 1) Can I send HTTP responses in an asynch manner.
> Example - Say I get a GET request in my libmicrohttpd server
On 05/17/2018 06:52 AM, Austin Einter wrote:
> Hello
> I am using libmicrohttpd and facing issue with POST processing.
>
> The POST message received contains xml or json data. libmicrohttpd does
> not support xml / json. So I can not use post process or iterate
> callbacks for body data processing
Dear Austin,
Please look at the code samples I pointed you towards. If you have XML
or JSON POST data, you must not use the MHD_PostProcessor API at all.
Happy hacking!
Christian
On 05/18/2018 09:25 AM, Austin Einter wrote:
> Dear All
> I am getting data in access content callback.
> I can do m
Dear Tal,
If you look at daemon.c:580, you can see that so far we only implemented
the CRD_CERTIFICATE type. There is no fundamental reason why PSK could
not be supported, but the respective data structures would need to be
added to 'struct MHD_Daemon' and the case filled in here with the right
c
You're missing "-lmicrohttpd" on the gcc command line.
On 07/19/2018 07:49 PM, Nick Leli wrote:
> # gcc -o microhttp microhttp.c -L/usr/local/lib/* -I/usr/local/include
> /tmp/cc7sUAvI.o: In function `ahc_echo':
signature.asc
Description: OpenPGP digital signature
On 08/23/2018 06:21 PM, Santos Das wrote:
> Hi,
>
> Can anyone please confirm if libmicrohttpd supports the Async handling?
Yes, it supports asynchronous processing.
> Also, any information on the performance of libmicrohttps will be useful.
Let's just say if used properly, it will never be any
On 08/23/2018 08:36 PM, Santos Das wrote:
> Hi,
>
> Thank you for the quick reply. I have one more question, please help in
> clarifying -
>
> Can "libmicrohttpd" run as a part of the application event loop or is it
> *_mandatory _*for the "libmicrohttpd" to have its own event loop?
It can run
On 08/23/2018 09:09 PM, Santos Das wrote:
> Hi,
>
> Thanks a lot. Is there any significant performance impact when it runs
> in this mode ?
Not inherently, but you don't get the thread-pool feature that way (at
least not without quite a bit of work by you!). My real
high-performance setups use t
On 08/24/2018 04:12 PM, Santos Das wrote:
> Hi,
>
> Thanks for the prompt reply. I have few more questions., kindly see if
> you could help.
>
> a. Does this have a transaction scoreboarding capability (e.g., to match
> up asynchronous operations)? The use of the passed argument *cls seems
> to
On 08/24/2018 08:05 PM, Santos Das wrote:
> Thank you once again for the prompt reply.
>
> I have few more questions. Are you aware of any project which has
> integrated libmicrohttpd along with libcurl without losing any
> functionality of MHD ? I really want to run in the single threaded model
>
On 08/29/2018 08:44 AM, Kunal Ekawde wrote:
> 3. Just after #2, when curl_multi_info_read is successful ,
> MHD_queue_response is invoked, but it returns 0 and the easy_handle
> state is 1.
>
> Can we send the response to client only from the MHD callback handler ?
Yes. You must call MHD_resume_c
it now, I wasn't using suspend/resume, but if client
> pipelines the requests, we would have suspended the connection, will it
> be handled ?
> Appreciate you help.
>
> Thanks,
> Kunal
>
> On Wed, Aug 29, 2018 at 12:47 PM Christian Grothoff <mailto:groth...@gn
uest> ?
>
> Is this correct?
>
> thanks, santos
>
> On Mon, Sep 3, 2018 at 12:41 PM Christian Grothoff <mailto:groth...@gnunet.org>> wrote:
>
> HTTP 1.1 processes requests in-order. Clients may send us additional
> requests on the same TCP connecti
Dear Kunal,
Yes, you can do all this, including raw epoll, no threads and storing
connection details in '*cls'. I just don't have an example that does
all this at once ;-)
Happy hacking!
Christian
On 08/27/2018 11:15 AM, Kunal Ekawde wrote:
> Hi,
>
> With ref to:
> https://lists.gnu.org/archi
the same ?
>
> https://github.com/maru/libmicrohttpd-http2
>
> https://lists.gnu.org/archive/html/libmicrohttpd/2016-08/msg00032.html
>
>
> On Fri, Aug 24, 2018 at 11:59 PM Christian Grothoff <mailto:groth...@gnunet.org>> wrote:
>
> On 08/24/2018 08:05 P
Hi Silvio,
I don't like the proposed feature very much, it's something an
application developer can reasonably easily write themselves, it would
introduce a dependency on file system operations to MHD, and it would
include a lot of different possible error types (file not found, access
permissions
On 9/3/18 6:09 PM, Paul Topley wrote:
>
> This all works great, but there is one particular situation im not sure
> how to handle. When there is an unexpected disconnect in the socket
> between client and server, which isnt instigated by either (lets say the
> server crashes, ethernet disconnect
al epoll w/o any MHD threads.
>
> Thanks,
> Kunal
>
> On Wed, Sep 5, 2018 at 9:22 PM Kunal Ekawde <mailto:kunaleka...@gmail.com>> wrote:
>
> Thanks Christian, yes I got it done :)
>
> On Wed, Sep 5, 2018 at 3:05 PM Christian Grothoff
> mailto:gr
On 09/06/2018 08:19 AM, Kunal Ekawde wrote:
>
> Can you please provide some information on 'MHD_USE_TURBO' as I couldn't
> find any info in manual.
From the manual:
@item MHD_USE_TURBO
@cindex performance
Enable optimizations to aggressively improve performance.
Currently, the optimizations thi
Yes. With a few exceptions MHD doesn't really care about which HTTP
method it is an just passes everything to the application.
On 09/12/2018 05:13 AM, Santos Das wrote:
> Can MHD handle the a msg body associated with a delete method? Can it
> pass it to the application when a message body is rece
If you suspend a connection, you are responsible to schedule some job to
resume it, after which MHD's timeout counter will start again (and of
course your response logic could then also just force MHD to close the
connection once MHD asks for response data). MHD timeouts are there to
detect (idle)
Hi!
Good news: You don't need to do anything. MHD will maintain persistent
TCP connections and use TCP's flow control mechanisms automatically.
You can _force_ MHD to not keep connections open by adding "Connection:
Close" to your HTTP response header manually, but by default MHD will do
the righ
On 09/18/2018 12:23 PM, Kunal Ekawde wrote:
> Thanks Christian,
> So as a solution we need to have a timer for such cases and on timer
> expiry , resume the connection post which as data is not available,
> either error respond or close connection.
Yes, basically if you suspend to perform some asy
) if the client sends
additional requests that the server is not yet processing.
> Sorry, lot of questions. But, please see if you could help in this.
>
> On Tue, Sep 18, 2018 at 3:12 PM Christian Grothoff <mailto:groth...@gnunet.org>> wrote:
>
> If you suspend a con
On 09/18/2018 02:22 PM, Kunal Ekawde wrote:
> Thanks for prompt response, few more doubts :)
> 1. Yeah, timers per connection on each request doesn't seems good, need
> to figure that out.
> 2. When you say ' MHD won't use more RAM per connection than allowed by
> MEMORY_LIMIT' , will MHD read from
On 09/18/2018 02:35 PM, Santos Das wrote:
> Thanks Christian.
>
> I have a question on "MHD_OPTION_CONNECTION_MEMORY_LIMIT" . I went
> through the manual. How does this affect the send/recv buffer size per
> client connection. What does it eventually translate to?
It does not directly translate.
On 09/18/2018 02:43 PM, Santos Das wrote:
> Thanks Christian. Looks like you answered this question for Kunal Ekwade
> already. Thank you.
>
> But, still not clear from your reply, is it equal to the receive buffer
> size ?
MHD uses "whatever is left" (minus some reserves depending on what phase
t; But it always fails.
>
> How can I solve this problem?
>
> Thank you
>
> Forrest
>
> ---原始邮件---
>
> *发件人:*
> Christian Grothoff
> *时 间:* 2018/09/18 20:43:58
> *收件人:*
>
> *抄 送:*
> undefined
> *主 题:*
> Re: [libmicrohttpd] Regard
Sorry, but I don't have one. Maybe someone else does...
On 10/09/2018 04:41 AM, silvioprog wrote:
>
> @Christian, just for curiosity, is there any document or example showing
> MHD + WS? I can't provide it since I'm not familiar with WS, but it
> would be nice if someone could provide one for us.
Looks good, pushed as f7ab8b59..9199e5aa (with updates to documentation).
Happy hacking!
Christian
On 10/15/18 9:03 PM, Gauthier Haderer wrote:
> Hi,
>
> I attached a patch which adds a response flag to force version to HTTP
> 1.0 in
> responses but still maintaining connection management.
>
Pushed as suggested in 9199e5aa..41ac9325
On 10/18/2018 04:35 PM, Tim Rühsen wrote:
> Building fails if the parent directory is an automake project dir:
>
> $ ./bootstrap
> libtoolize: putting auxiliary files in '..'.
> libtoolize: copying file '../ltmain.sh'
> libtoolize: put
Hi Tim,
The issue is that in line Makefile.am:10, we have "noinst_" instead of
"lib_" because the code is far from complete and it must not yet be
installed. That causes the dlname='' issue you describe.
The best fix I can propose: I'm adding an option (--enable-experimental)
which disables build
If you do not set a timeout or do something else explicit to close the
connection, MHD will try to keep the connection open. The rest depends
on the HTTP client, which you cannot force to keep the connection open.
On 10/20/2018 08:57 AM, Santos Das wrote:
> Hi,
>
> We are using a HTTP 1.1.
>
>
Dear Daniel,
You didn't mention which thread mode you were using, but manual
inspection suggests your issue should occur in thread-per-connection
modes (only). In that case, I've pushed a (likely) fix in
b55cd46b..47281241 to Git master.
Please test and report back!
Happy hacking!
Christian
O
lean and tested.
>
> Whatever you decide, let me know and I'll change my build scripts :-)
>
> Regards, Tim
>
>
> On 10/18/18 5:34 PM, Christian Grothoff wrote:
>> Hi Tim,
>>
>> The issue is that in line Makefile.am:10, we have "noinst_" instead
Yes.
On 10/26/18 4:23 PM, Erik Smith wrote:
> Is the server guaranteed to be listening after MHD_start_daemon
> returns? I want to be able to be able to implement quick client/server
> unit testing without the need to poll the server to see if it's up.
>
> erik
>
signature.asc
Description: O
ke me to test
> some more fixes.
>
> Kind regards,
> Daniel
>
>
>
>
>
>
> On Sat, 20 Oct 2018 at 11:46, Christian Grothoff <mailto:groth...@gnunet.org>> wrote:
>
> Dear Daniel,
>
> You didn't mention which thread mode
1 - 100 of 800 matches
Mail list logo
