Tntnet is a web application server for web applications written in C++.

Hello,

We regularly encounter a problem with unsuccessful Ajax requests in an application using tntnet. For example on our component Login.ecpp. This component does not do any complex actions.

tntnet.worker returns this message to us:

FATAL tntnet.worker - requesttime 600s seconds in thread 139743169820416 exceeded - exit process

tntnet is completely blocked for a while. If we wait, everything works again.

We used the latest tntnet.

How do we debug this problem?

This commit changes the behavior of files in the mbcomponent: If enableCompression is set and client supports compression, mbcomponent is looking for the requested filename with the extension .gz at first, if this file is found, this already compressed file would be sent to the client. if there is no file with the extension .gz than the current file would be compressed on the fly (as it was before) and sent to the client.

Example: client wants favicon.svg, with compression enabled. server looks for favicon.svg.gz ==> if found, server sends this compressed file. (this is the new behavior) if favicon.svg.gz not found, server will compress favicon.svg and send it compressed to the client. (this is the old behavior, now the fallback)

This bit of ECPP

<%application scope="shared">
    GlobalConf a_conf;
</%application>

results is this generated C++

  typedef GlobalConf a_conf_type;
  TNT_APPLICATION_SHARED_VAR(GlobalConf, a_conf, ());   // <%application> GlobalConf a_conf

where the typedef isn't actually used. I suppose it's meant to be used as the first argument for TNT_APPLICATION_SHARED_VAR?

Ok, I've got a (hopefully) dumb question.

I checked the docs, and it says: http://www.tntnet.org/howto/static-howto.html

In tntnet.xml, I put the lines:

<mapping>
  <url>^/(.*)</url>
  <target>[email protected]</target>
  <pathinfo>/var/www/htdocs/$1</pathinfo>
</mapping>

I'm using the basic sample:

int main(int argc, char* argv[])
{
	std::cerr << "Starting up CLabs webserver" << std::endl;
	try
	{
		tnt::Tntnet app;
		app.listen(8000);
		app.mapUrl("^/(.*)", "$1");
		app.mapUrl("^/([^.]+)(\\..+)?", "$1"); 

		app.run();
	}
	catch (const std::exception& e)
	{
		std::cerr << e.what() << std::endl;
	}
	std::cerr << "Shutting down webserver" << std::endl;
}

Yet, I get 404 errors for any of the files I have loaded in /var/www/htdocs/

I've tried slightly different versions of the files to make sure I didn't have a typo or something.

Do we have to do something in the code to enable static files? Do I need a different app.mapURL statement? Does that bypass tntnet.xml? Do you need a statement to read tntnet.xml?

Thank you,

== John ==

The (generated) file config.h currently isn't installed as part of the tntnet library, but is included in several headers: ssl.h, listener.h, pollerimpl.h, and on my fork's v3.0 branch tntconfig.has well (that's how I found out). I would suggest moving it from framework/common to framework/common/tnt.

If you think it shouldn't be installed, IMHO the headers including it shouldn't be installed either, and moved from framework/common/tnt to framework/common (and from _HEADERS to _SOURCES).

I will fix this on my fork and include it in the v3.0 branch. Here is what I use config.h for in tntconfig.h.

By the way, I would be happy discussion this and the other changes on there with you on IRC, or maybe gitter.im? It's pretty similar to IRC (in fact it allows connecting to it via IRC) but has a log / history so users don't have to be online simultaneously or use a bouncer.

Danke für deine Mail. Leider reicht die Info noch nicht um damit zu arbeiten. Soweit wie ich es verstanden habe, habe ich das im Code dokumentiert. Bitte noch mal ansehen und ergänzen. Am besten mit kurzem Beispiel. Danke !

Viele Grüße

Olaf

update

I added the systemd config in my fork.

Greetings

Olaf

libtool is only needed when building libraries and including it (through LT_INIT) adds an additional build dependency as well as resulting in a bigger configure script that checks for things that aren't used.

I'll create a PR for this soon, just don't release tntnet 2.3 yet, please :)

i tried again compilation with your changes. test/tntnet-test fails on arm platform see logs of the fedora build server: https://kojipkgs.fedoraproject.org//work/tasks/9563/10369563/build.log

Reading through configure.ac, I found several things done in multiple different ways throughout the file:

• Option testing with test "$enable_option" = "yes" and test x$enable_option = xyes (e.g. line 135 and line 149)
• Conditional code paths with AS_IF and the shell's if ... then ... endif (e.g. line 152 and line 196)

Also, the options -Wall and -pedantic are enabled (only) for the IBM C++ compiler. Why?

=autoconf-2.70 is more strict with quoting and thus produces broken configure files without these fixes

Gentoo-bug: https://bugs.gentoo.org/775479 Signed-off-by: Lars Wendler [email protected]

Problem : openssl behaves with default weak protocol(SSL3) and weak cipher(RC4) Solution : add sslProtocols and sslCipherList tag in tntnet.xml to allow user to configuration it.

Problem : some recent browser likes Chrome reports that “Your connection to tntnet server is encrypted with obsolete cryptography.” To avoid this kind of message, it is good to allow openssl using ECDHE cipher suite. Solution : create a temp ECDH keys.

Debian Bullseye 11.3 tntnet 2.2.1-4

Note: this is a completely fresh Debian 11 installation with tntnet, the exact same configuration works fine on Deb 10.

When running command: systemctl status tntnet

I see this warning (hostname is dev0).

● tntnet.service - Tntnet web server Loaded: loaded (/lib/systemd/system/tntnet.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2022-04-10 18:35:37 PDT; 19h ago Process: 2711879 ExecStart=/usr/bin/tntnet (code=exited, status=0/SUCCESS) Main PID: 2711881 (tntnet) Tasks: 9 (limit: 154413) Memory: 1.3M CPU: 211ms CGroup: /system.slice/tntnet.service ├─2711880 /usr/bin/tntnet └─2711881 /usr/bin/tntnet

Apr 10 18:35:37 dev0 systemd[1]: Starting Tntnet web server... Apr 10 18:35:37 dev0 tntnet[2711879]: tntnet 2.2.1 Apr 10 18:35:37 dev0 systemd[1]: tntnet.service: Supervising process 2711881 which is not our child. We'll most likely not notice when it exits.

Something is wrong with the way systemd is being used. I posted another issue about the default startup file /etc/default/tntnet is not being read on startup, the issue with systemd may be a related.

Debian Linux Bullseye 11.3 Tntnet version 2.2.1-4

This is a completely new Debian Bulleye installation with freshly installed tntnet, the same setup works perfectly on Debian Buster (edit correction: my last known working tntnet version was on Debian 9 "Stretch").

I use the default startup file to specify an alternative configuration .xml file, but noticed it behaved as if using the default configs from /etc/tntnet.xml.

Contents of /etc/default/tntnet :

DAEMON_OPTS="--logall -c /usr/local/etc/tntnet.xml"

Nothing seems to be read on startup because there are no errors even when jibberish is typed into the startup config file.

inside makefile of hello the cxxtools lib is not define and so the compilation has an error of link in the history of demo/hello/Makefile.am it seems that it was perhaps correct in the past

I am starting tntnet with a systemd service unit, see attached configuration file: [email protected] I am starting multiple instances, for example systemctl start [email protected] and systemctl start [email protected].

This systemd service sets the user and group to www-data. If user and group are also configured in the configuration file tntnet.xml (<user>www-data</user><group>www-data</group>), tntnet throws an exception: error 1 in function setgroups: Operation not permitted

Maybe tntnet should check user and group before calling the setgroups function?

It would be nice, if tntnet provides a special daemon mode for systemd services. systemd could be used for controlling the tntnet process.

My system is a Debian 9.6 (Stretch) and tntnet is compiled from master branch. The April 2018 version did not show this behavior.

With tntnet version 2.1 from the Debian repositories you can create tnt::QueryParams objects with unnamed parameters. tnt::QueryParams tnt_qp; tnt_qp.add("value");

With the latest version from GitHub this only works with the class cxxtools::QueryParams from the cxxtools library. For now I am using a workaround: cxxtools::QueryParams cxx_qp; cxx_qp.add("value"); tnt_qp.add(cxx_qp)