Lasa Martxel wrote:
Hello,
I have found the following code in daemon.c file, lines 1449 to 1467:
if (0 >= res)
{
if (GNUTLS_E_INTERRUPTED != res)
{
urh->app.celi &= ~MHD_EPOLL_STATE_WRITE_READY;
if (GNUTLS_E_INTERRUPTED != res)
(GNUTLS_E_INTERRUPTED != res) is checked twice.
In the read part (a few lines above), GNUTLS_E_INTERRUPTED != res is checked first and then GNUTLS_E_AGAIN != res. It looks like something similar should be done here, but I’m not sure.
Thanks,
Martxel
Lasa Martxel <mlasa@ikerlan.es> wrote:
I was getting an error when running make check, when building test_upgrade. I have followed the following steps to build the library (tried both on master an v0.9.62, same result):
git clone https://gnunet.org/git/libmicrohttpd.git
cd libmicrohttpd
./bootstrap
./configure --enable-curl
make
make check
The error message I was getting is the following one:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/microhttpd -fvisibility=hidden -pthread -g -O2 -fno-strict-aliasing -MT test_upgrade-test_upgrade.o -MD -MP -MF .deps/test_upgrade-test_upgrade.Tpo -c -o test_upgrade-test_upgrade.o `test -f 'test_upgrade.c' || echo './'`test_upgrade.c
mv -f .deps/test_upgrade-test_upgrade.Tpo .deps/test_upgrade-test_upgrade.Po
/bin/bash ../../libtool --tag=CC --mode=link gcc -fvisibility=hidden -pthread -g -O2 -fno-strict-aliasing -o test_upgrade test_upgrade-test_upgrade.o ../../src/microhttpd/libmicrohttpd.la
libtool: link: gcc -fvisibility=hidden -pthread -g -O2 -fno-strict-aliasing -o .libs/test_upgrade test_upgrade-test_upgrade.o ../../src/microhttpd/.libs/libmicrohttpd.so -pthread
/usr/bin/ld: test_upgrade-test_upgrade.o: undefined reference to symbol 'gnutls_handshake@@GNUTLS_3_4'
//usr/lib/x86_64-linux-gnu/libgnutls.so.30: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:1139: recipe for target 'test_upgrade' failed
I had to add $(MHD_TLS_LIB_LDFLAGS) and $(MHD_TLS_LIBDEPS) to test_upgrade_LDADD and test_upgrade_tls_LDADD to the Makefile.am:
diff --git a/src/microhttpd/Makefile.am b/src/microhttpd/Makefile.am
index 22b6100d..1f4ffca3 100644
--- a/src/microhttpd/Makefile.am
+++ b/src/microhttpd/Makefile.am
@@ -224,6 +224,7 @@ test_upgrade_LDFLAGS = \
$(MHD_TLS_LIB_LDFLAGS)
test_upgrade_LDADD = \
$(top_builddir)/src/microhttpd/libmicrohttpd.la \
+ $(MHD_TLS_LIB_LDFLAGS) $(MHD_TLS_LIBDEPS) \
$(PTHREAD_LIBS)
test_upgrade_tls_SOURCES = \
@@ -236,6 +237,7 @@ test_upgrade_tls_LDFLAGS = \
$(MHD_TLS_LIB_LDFLAGS)
test_upgrade_tls_LDADD = \
$(top_builddir)/src/microhttpd/libmicrohttpd.la \
+ $(MHD_TLS_LIB_LDFLAGS) $(MHD_TLS_LIBDEPS) \
$(PTHREAD_LIBS)
test_postprocessor_SOURCES = \
With that change, I’m able to correctly build, run and pass al the tests.
Regards,
Martxel
-> patched as suggested
The argument of the HTTPS options is now always
extracted from the list of variable arguments.
This removes strange errors like:
MHD HTTPS option 8 passed to MHD but MHD_USE_TLS not set
Invalid option 6313728! (Did you terminate the list with MHD_OPTION_END?)
And allows to activate/deactivate HTTPS fairly by
only setting or not the flag MHD_USE_TLS.
Change-Id: I31acedbdefe9c930e94c7227d240a36d2a9000d5
Signed-off-by: José Bollo <jose.bollo@iot.bzh>
Signed-off-by: Christian Grothoff <christian@grothoff.org>
Date: Thu, 8 Nov 2018 00:15:29 +0100
Subject: [PATCH 1/1] fix tests with curl
Starting with curl 7.62.0 some tests fail. The commit in question is
46e16406 [0] ("url: use the URL API internally as well").
Analyzing the changed behavior reveals that the url given to
curl_easy_setopt() with CURLOPT_URL is no longer encoded. Looking at the
documentation [1] this behavior is correct, the "parameter should be a
char * to a zero terminated string which must be URL-encoded [...]".
So let's just give a valid url...
[0] https://github.com/curl/curl/commit/46e164069d1a5230e4e64cbd2ff46c46cce056bb
[1] https://curl.haxx.se/libcurl/c/CURLOPT_URL.html
Signed-off-by: Christian Hesse <mail@eworm.de>
Signed-off: CG
Date: Mon, 15 Oct 2018 14:11:39 +0200
Subject: [PATCH] Add response flag to force version to 1.0 and maintain
connection management.
The existing MHD_RF_HTTP_VERSION_1_0_ONLY flag already changes MHD's
behavior to apply HTTP 1.0 rules for connection management. When
enabled, MHD sends a response using the same version as used in the
request (is this normal?).
What I want is MHD responding as a HTTP 1.0 server with support for
connection management headers would do. This is what the
MHD_RF_HTTP_VERSION_1_0_RESPONSE response flag is for.
You can even combine it with MHD_RF_HTTP_VERSION_1_0_ONLY to change the
response's HTTP version while maintaining strict compliance with HTTP
1.0 regarding connection management.
This solution is not perfect as this flag is set on the response which
is created after header processing. So MHD will behave as a HTTP 1.1
server until the response is queued. It means that an invalid HTTP 1.1
request will fail even if the response is sent with HTTP 1.0 and the
request would be valid if interpreted with this version. For example,
this request will fail in strict mode:
GET /dummy HTTP/1.1
as the Host header is missing and is mandatory in HTTP 1.1, but it
should succeed when interpreted with HTTP 1.0.
I don't think this is a big issue in practice. Besides, being able to
change the HTTP version on a response basis is really convenient when
using MHD in a test framework where we need to validate a client against
HTTP 1.1 AND HTTP 1.0.
Christian Grothoff
silvioprog
Evgeny Grin (Karlson2k)
José Bollo