diff --git a/README.test-apps.md b/README.test-apps.md
index 240011b8..1437b31f 100644
--- a/README.test-apps.md
+++ b/README.test-apps.md
@@ -1,3 +1,49 @@
+Overview of lws test apps
+=========================
+
+Are you building a client? You just need to look at the test client
+[libwebsockets-test-client](test-server/test-client.c).
+
+If you are building a standalone server, there are three choices, in order of
+preferability.
+
+1) lwsws + protocol plugins
+
+Lws provides a generic web server app that can be configured with JSON
+config files. https://libwebsockets.org itself uses this method.
+
+With lwsws handling the serving part, you only need to write an lws protocol
+plugin. See [plugin-standalone](plugin-standalone) for an example of how
+to do that outside lws itself, using lws public apis.
+
+ $ cmake .. -DLWS_WITH_LWSWS=1
+
+See [README.lwsws.md](README.lwsws.md) for information on how to configure
+lwsws.
+
+NOTE this method implies libuv is used by lws, to provide crossplatform
+implementations of timers, dynamic lib loading etc for plugins and lwsws.
+
+2) test-server-v2.0.c
+
+This method lets you configure web serving in code, instead of using lwsws.
+
+Plugins are still used, which implies libuv needed.
+
+ $ cmake .. -DLWS_WITH_PLUGINS=1
+
+See [test-server-v2.0.c](test-server/test-server-v2.0.c)
+
+3) protocols in the server app
+
+This is the original way lws implemented servers, plugins and libuv are not
+required, but without plugins separating the protocol code directly, the
+combined code is all squidged together and is much less maintainable.
+
+This method is still supported in lws but all ongoing and future work is
+being done in protocol plugins only.
+
+
Notes about lws test apps
=========================
diff --git a/doc/html/libwebsockets_8h_source.html b/doc/html/libwebsockets_8h_source.html
index 7213fd4e..d96ac8c2 100644
--- a/doc/html/libwebsockets_8h_source.html
+++ b/doc/html/libwebsockets_8h_source.html
@@ -71,7 +71,7 @@ $(document).ready(function(){initNavTree('libwebsockets_8h_source.html','');});
If you are building a standalone server, there are three choices, in order of preferability.
+
1) lwsws + protocol plugins
+
Lws provides a generic web server app that can be configured with JSON config files. https://libwebsockets.org itself uses this method.
+
With lwsws handling the serving part, you only need to write an lws protocol plugin. See [plugin-standalone](plugin-standalone) for an example of how to do that outside lws itself, using lws public apis.
+
$ cmake .. -DLWS_WITH_LWSWS=1
+
See README.lwsws.md for information on how to configure lwsws.
+
NOTE this method implies libuv is used by lws, to provide crossplatform implementations of timers, dynamic lib loading etc for plugins and lwsws.
+
2) test-server-v2.0.c
+
This method lets you configure web serving in code, instead of using lwsws.
+
Plugins are still used, which implies libuv needed.
This is the original way lws implemented servers, plugins and libuv are not required, but without plugins separating the protocol code directly, the combined code is all squidged together and is much less maintainable.
+
This method is still supported in lws but all ongoing and future work is being done in protocol plugins only.
It will fetch a script in the form of test.html, and then run the script in there on the browser to open a websocket connection. Incrementing numbers should appear in the browser display.
By default the test server logs to both stderr and syslog, you can control what is logged using -d <log level>, see later.
diff --git a/doc/html/navtreedata.js b/doc/html/navtreedata.js
index db36b872..66d4e104 100644
--- a/doc/html/navtreedata.js
+++ b/doc/html/navtreedata.js
@@ -6,7 +6,7 @@ var NAVTREE =
[ "Notes about lwsws", "md_README.lwsws.html", null ],
[ "Notes about coding with lws", "md_README.coding.html", null ],
[ "Notes about generic-sessions Plugin", "md_README.generic-sessions.html", null ],
- [ "Notes about lws test apps", "md_README.test-apps.html", null ],
+ [ "Overview of lws test apps", "md_README.test-apps.html", null ],
[ "Deprecated List", "deprecated.html", null ],
[ "Modules", "modules.html", "modules" ],
[ "Data Structures", "annotated.html", [
diff --git a/doc/html/pages.html b/doc/html/pages.html
index a5b8e0f5..880af1c5 100644
--- a/doc/html/pages.html
+++ b/doc/html/pages.html
@@ -71,7 +71,7 @@ $(document).ready(function(){initNavTree('pages.html','');});
diff --git a/doc/latex/md_README.test-apps.tex b/doc/latex/md_README.test-apps.tex
index 50881a38..76c7844f 100644
--- a/doc/latex/md_README.test-apps.tex
+++ b/doc/latex/md_README.test-apps.tex
@@ -1,3 +1,37 @@
+Are you building a client? You just need to look at the test client \href{test-server/test-client.c}{\tt libwebsockets-\/test-\/client}.
+
+If you are building a standalone server, there are three choices, in order of preferability.
+
+1) lwsws + protocol plugins
+
+Lws provides a generic web server app that can be configured with J\+S\+ON config files. \href{https://libwebsockets.org}{\tt https\+://libwebsockets.\+org} itself uses this method.
+
+With lwsws handling the serving part, you only need to write an lws protocol plugin. See \mbox{[}plugin-\/standalone\mbox{]}(plugin-\/standalone) for an example of how to do that outside lws itself, using lws public apis.
+
+\$ cmake .. -\/\+D\+L\+W\+S\+\_\+\+W\+I\+T\+H\+\_\+\+L\+W\+S\+WS=1
+
+See \hyperlink{md_README.lwsws}{R\+E\+A\+D\+ME.lwsws.md} for information on how to configure lwsws.
+
+N\+O\+TE this method implies libuv is used by lws, to provide crossplatform implementations of timers, dynamic lib loading etc for plugins and lwsws.
+
+2) test-\/server-\/v2.\+0.\+c
+
+This method lets you configure web serving in code, instead of using lwsws.
+
+Plugins are still used, which implies libuv needed.
+
+\$ cmake .. -\/\+D\+L\+W\+S\+\_\+\+W\+I\+T\+H\+\_\+\+P\+L\+U\+G\+I\+NS=1
+
+See \href{test-server/test-server-v2.0.c}{\tt test-\/server-\/v2.\+0.\+c}
+
+3) protocols in the server app
+
+This is the original way lws implemented servers, plugins and libuv are not required, but without plugins separating the protocol code directly, the combined code is all squidged together and is much less maintainable.
+
+This method is still supported in lws but all ongoing and future work is being done in protocol plugins only.
+
+\section*{Notes about lws test apps }
+
\subsection*{Testing server with a browser }
If you run \href{test-server/test-server.c}{\tt libwebsockets-\/test-\/server} and point your browser (eg, Chrome) to \begin{DoxyVerb} http://127.0.0.1:7681
diff --git a/doc/latex/refman.tex b/doc/latex/refman.tex
index 9e297790..8a9f9e3f 100644
--- a/doc/latex/refman.tex
+++ b/doc/latex/refman.tex
@@ -155,7 +155,7 @@
\label{md_README.generic-sessions}
\hypertarget{md_README.generic-sessions}{}
\input{md_README.generic-sessions}
-\chapter{Notes about lws test apps}
+\chapter{Overview of lws test apps}
\label{md_README.test-apps}
\hypertarget{md_README.test-apps}{}
\input{md_README.test-apps}
diff --git a/lib/server.c b/lib/server.c
index 4d49f836..5d4b246e 100644
--- a/lib/server.c
+++ b/lib/server.c
@@ -870,7 +870,7 @@ lws_http_action(struct lws *wsi)
} else {
/* deferred cleanup and reset to protocols[0] */
- lwsl_notice("no hit\n");
+ lwsl_info("no hit\n");
if (lws_bind_protocol(wsi, &wsi->vhost->protocols[0]))
return 1;
@@ -1853,7 +1853,7 @@ lws_serve_http_file(struct lws *wsi, const char *file, const char *content_type,
O_RDONLY);
if (wsi->u.http.fd == LWS_INVALID_FILE) {
- lwsl_err("Unable to open '%s'\n", file);
+ lwsl_info("Unable to open '%s'\n", file);
lws_return_http_status(wsi, HTTP_STATUS_NOT_FOUND, NULL);
return -1;
diff --git a/test-server/test-server-http.c b/test-server/test-server-http.c
index 875a0a87..cdd136df 100644
--- a/test-server/test-server-http.c
+++ b/test-server/test-server-http.c
@@ -209,7 +209,7 @@ int callback_http(struct lws *wsi, enum lws_callback_reasons reason, void *user,
switch (reason) {
case LWS_CALLBACK_HTTP:
- lwsl_notice("lws_http_serve: %s\n",in);
+ lwsl_info("lws_http_serve: %s\n",in);
if (debug_level & LLL_INFO) {
dump_handshake_info(wsi);
@@ -223,11 +223,8 @@ int callback_http(struct lws *wsi, enum lws_callback_reasons reason, void *user,
}
{
- char name[100], rip[50];
- lws_get_peer_addresses(wsi, lws_get_socket_fd(wsi), name,
- sizeof(name), rip, sizeof(rip));
- sprintf(buf, "%s (%s)", name, rip);
- lwsl_notice("HTTP connect from %s\n", buf);
+ lws_get_peer_simple(wsi, buf, sizeof(buf));
+ lwsl_info("HTTP connect from %s\n", buf);
}
if (len < 1) {
@@ -497,7 +494,7 @@ int callback_http(struct lws *wsi, enum lws_callback_reasons reason, void *user,
return 1;
goto try_to_reuse;
case LWS_CALLBACK_HTTP_DROP_PROTOCOL:
- lwsl_notice("LWS_CALLBACK_HTTP_DROP_PROTOCOL\n");
+ lwsl_debug("LWS_CALLBACK_HTTP_DROP_PROTOCOL\n");
/* called when our wsi user_space is going to be destroyed */
if (pss->spa) {
diff --git a/test-server/test-server.c b/test-server/test-server.c
index 505df01a..85b9c1bb 100644
--- a/test-server/test-server.c
+++ b/test-server/test-server.c
@@ -135,7 +135,7 @@ test_server_fops_open(struct lws *wsi, const char *filename,
/* call through to original platform implementation */
n = fops_plat.open(wsi, filename, filelen, flags);
- lwsl_notice("%s: opening %s, ret %ld, len %lu\n", __func__, filename,
+ lwsl_info("%s: opening %s, ret %ld, len %lu\n", __func__, filename,
(long)n, *filelen);
return n;