- b -
-
+
- basic_auth_login_file +: lws_http_mount +
- bin : lwsgw_hash_bin diff --git a/doc/html/group__client.html b/doc/html/group__client.html index ef3db81b..cec55385 100644 --- a/doc/html/group__client.html +++ b/doc/html/group__client.html @@ -119,7 +119,7 @@ LWS_VISIBLE LWS_EXTERN void
- Windows (Visual Studio) +
- Windows (MinGW) +
- Linux (x86 and ARM) +
- OSX +
- NetBSD +
- Install CMake 2.8 or greater: http://cmake.org/cmake/resources/software.html (Most Unix distributions comes with a packaged version also) +
- Install OpenSSL. +
- Generate the build files (default is Make files): $ cd /path/to/src$ mkdir build$ cd build$ cmake ..
+
- Finally you can build using the generated Makefile: NOTE: The$ make && sudo make install
build/directory can have any name and be located anywhere on your filesystem, and that the argument..` given to cmake is simply the source directory of libwebsockets containing the CMakeLists.txt project file. All examples in this file assumes you use ".."
+ - Finally you can build using the generated Makefile: +
- Install CMake 2.6 or greater: http://cmake.org/cmake/resources/software.html +
Install OpenSSL binaries. http://www.openssl.org/related/binaries.html
+(NOTE: Preferably in the default location to make it easier for CMake to find them)
+NOTE2: Be sure that OPENSSL_CONF environment variable is defined and points at <OpenSSL install="" location>="">.cfg
+
+- Generate the Visual studio project by opening the Visual Studio cmd prompt: +
- Now you should have a generated Visual Studio Solution in your
<path to src>/builddirectory, which can be used to build.
+ - Some additional deps may be needed
-
+
- iphlpapi.lib +
- psapi.lib +
- userenv.lib +
+ - If you're using libuv, you must make sure to compile libuv with the same multithread-dll / Mtd attributes as libwebsockets itself +
Install MinGW: http://sourceforge.net/projects/mingw/files
+(NOTE: Preferably in the default location C:)
+
+Fix up MinGW headers
+a) Add the following lines to C:.h:
#if(_WIN32_WINNT >= 0x0600)typedef struct pollfd {SOCKET fd;SHORT events;SHORT revents;} WSAPOLLFD, *PWSAPOLLFD, FAR *LPWSAPOLLFD;WINSOCK_API_LINKAGE int WSAAPI WSAPoll(LPWSAPOLLFD fdArray, ULONG fds, INT timeout);#endif // (_WIN32_WINNT >= 0x0600)b) Create C:.h and copy and paste the content from following link into it:
+http://wine-unstable.sourcearchive.com/documentation/1.1.32/mstcpip_8h-source.html
+
+- Install CMake 2.6 or greater: http://cmake.org/cmake/resources/software.html +
Install OpenSSL binaries. http://www.openssl.org/related/binaries.html
+(NOTE: Preferably in the default location to make it easier for CMake to find them)
+NOTE2: Be sure that OPENSSL_CONF environment variable is defined and points at <OpenSSL install="" location>="">.cfg
+
+Generate the build files (default is Make files) using MSYS shell:
$ cd /drive/path/to/src$ mkdir build$ cd build$ cmake -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=C:/MinGW ..(NOTE: The
+build/directory can have any name and be located anywhere on your filesystem, and that the argument..` given to cmake is simply the source directory of libwebsockets containing the CMakeLists.txt project file. All examples in this file assumes you use "..")NOTE2: To generate build files allowing to create libwebsockets binaries with debug information set the CMAKE_BUILD_TYPE flag to DEBUG:
$ cmake -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=C:/MinGW -DCMAKE_BUILD_TYPE=DEBUG ..
+- Finally you can build using the generated Makefile and get the results deployed into your MinGW installation: +
- Generated by
+
+
1.8.12
+ lws_callback_on_writable(context, wsi)for a specificwsi, or
+lws_callback_on_writable_all_protocol(protocol)for all connections using that protocol to get a callback when next writeable.
+lwsl_err(...)
+lwsl_warn(...)
+lwsl_notice(...)
+lwsl_info(...)
+lwsl_debug(...)
+- be sure you set .events to .revents value as well in the synthesized pollfd +
- check the built-in support for the event loop if possible (eg, ./lib/libuv.c) to see how it interfaces to lws +
- use LWS_POLLHUP / LWS_POLLIN / LWS_POLLOUT from libwebsockets.h to avoid losing windows compatibility +
- LWSMPRO_FILE is used for mapping url namespace to a filesystem directory and serve it automatically. +
- LWSMPRO_CGI associates the url namespace with the given CGI executable, which runs when the URL is accessed and the output provided to the client. +
- LWSMPRO_REDIR_HTTP and LWSMPRO_REDIR_HTTPS auto-redirect clients to the given origin URL. +
- LWSMPRO_CALLBACK causes the http connection to attach to the callback associated with the named protocol (which may be a plugin). +
include lws-common.js from your HEAD section
+<script src="/lws-common.js"></script>
+
+dim the page during initialization, in a script section on your page
+lws_gray_out(true,{'zindex':'499'});
+
+in your ws onOpen(), remove the dimming
+lws_gray_out(false);
+
+in your ws onClose(), reapply the dimming
+lws_gray_out(true,{'zindex':'499'});
+
+- Generated by
+
+ 1.8.12
+
- random 20-byte session id managed in a cookie +
- all information related to the session held at the server, nothing managed clientside +
- sqlite3 used at the server to manage active sessions and users +
- defaults to creating anonymous sessions with no user associated +
- admin account (with user-selectable username) is defined in config with a SHA-1 of the password; rest of the accounts are in sqlite3 +
- user account passwords stored as salted SHA-1 with additional confounder only stored in the JSON config, not the database +
- login, logout, register account + email verification built-in with examples +
- in a mount, some file suffixes (ie, .js) can be associated with a protocol for the purposes of rewriting symbolnames. These are read-only copies of logged-in server state. +
- When your page fetches .js or other rewritten files from that mount, "$lwsgs_user" and so on are rewritten on the fly using chunked transfer encoding +
- Eliminates server-side scripting with a few rewritten symbols and javascript on client side +
- 32-bit bitfield for authentication sectoring, mounts can provide a mask on the loggin-in session's associated server-side bitfield that must be set for access. +
- No code (just config) required for, eg, private URL namespace that requires login to access. +
- b0 is set if you are logged in as a user at all. +
- b1 is set if you are logged in with the user configured to be admin +
- b2 is set if the account has been verified (the account configured for admin is always verified) +
- b3 is set if your session just did the forgot password flow successfully +
email-from: The email address automatic emails are sent from
+email-smtp-ip: Normally 127.0.0.1, if you have a suitable server on port 25 on your lan you can use this instead here.
+email-expire: Seconds that links sent in email will work before being deleted
+email-helo: HELO to use when communicating with your SMTP server
+email-contact-person: mentioned in the automatic emails as a human who can answer questions
+email-confirm-url-base: the URL to start links with in the emails, so the recipient can get back to the web server
+- LWS_CALLBACK_HTTP +
- LWS_CALLBACK_HTTP_BODY +
- LWS_CALLBACK_HTTP_BODY_COMPLETION +
- LWS_CALLBACK_HTTP_DROP_PROTOCOL +
- all the strings will be zero-length and .mask zero, there is no usable cookie
-
+
- only .ip and .session are set: the cookie is OK but no user logged in +
- all the strings contain information about the logged-in user +
+ - Generated by
+
+ 1.8.12
+
- Example protocol plugin (displays directory contents): https://github.com/warmcat/libwebsockets/tree/master/plugins/generic-table/protocol_table_dirlisting.c +
- Example HTML: https://github.com/warmcat/libwebsockets/tree/master/plugins/generic-table/assets/index.html +
- lwsgt.js (client-side table rendering / ws link management): https://github.com/warmcat/libwebsockets/tree/master/plugins/generic-table/assets/lwsgt.js +
- In your HEAD section, include lwsgt.js +
- Also in your HEAD section, style the lwsgt CSS, eg +
- In your body section, declare a div with an id (can be whatever you want) +
- Finally in a <script> at the end of your page, instantiate lwsgt and provide a custom callback for clickable links +
- This describes 5 columns +
- Only four columns (not "uri") should be visible +
- "Name" should be presented as a clickable link using "uri" as the destination, when a "uri" field is presented. +
- "Size" field should be presented aligned to the right +
- Generated by
+
+ 1.8.12
+
- '#' may be used to turn the rest of the line into a comment. +
- There's also a single substitution, if a string contains "_lws_ddir_", then that is replaced with the LWS install data directory path, eg, "/usr/share" or whatever was set when LWS was built + installed. That lets you refer to installed paths without having to change the config if your install path was different. +
reject-service-keywordsallows you to return an HTTP error code and message of your choice if a keyword is found in the user agent
+- Vhosts may have the same name and different ports, these will each create a listening socket on the appropriate port. +
- Vhosts may also have the same port and different name: these will be treated as true vhosts on one listening socket and the active vhost decided at SSL negotiation time (via SNI) or if no SSL, then after the Host: header from the client has been parsed. +
- If the three options
host-ssl-cert,host-ssl-caandhost-ssl-keyare given, then the vhost supports SSL.
+ keeplive-timeout(in secs) defaults to 60 for lwsws, it may be set as a vhost option
+interfacelets you specify which network interface to listen on, if not given listens on all
+- "`unix-socket`": "1" causes the unix socket specified in the interface option to be used instead of an INET socket +
- "`sts`": "1" causes lwsws to send a Strict Transport Security header with responses that informs the client he should never accept to connect to this address using http. This is needed to get the A+ security rating from SSL Labs for your server. +
- "`access-log`": "filepath" sets where apache-compatible access logs will be written +
"enable-client-ssl":"1"enables the vhost's client SSL context, you will need this if you plan to create client conections on the vhost that will use SSL. You don't need it if you only want http / ws client connections.
+- "`ciphers`": "<cipher list>" sets the allowed list of ciphers and key exchange protocols for the vhost. The default list is restricted to only those providing PFS (Perfect Forward Secrecy) on the author's Fedora system. +
- "`ecdh-curve`": "<curve name>" The default ecdh curve is "prime256v1", but you can override it here, per-vhost +
- "`noipv6`": "on" Disable ipv6 completely for this vhost +
- "`ipv6only`": "on" Only allow ipv6 on this vhost / "off" only allow ipv4 on this vhost +
- "`ssl-option-set`": "<decimal>" Sets the SSL option flag value for the vhost. It may be used multiple times and OR's the flags together. +
- "`ssl-option-clear'": "<decimal>" Clears the SSL option flag value for the vhost. It may be used multiple times and OR's the flags together. +
- "`headers':: [{ "header1": "h1value", "header2": "h2value" }] +
- file:// serve the uri using the remainder of the url past the mountpoint based on the origin directory. +
- ^http:// or ^https:// these cause any url matching the mountpoint to issue a redirect to the origin url +
- cgi:// this causes any matching url to be given to the named cgi, eg would cause the url /git/myrepo to pass "myrepo" to the cgi /var/www/cgi-bin/cgit and send the results to the client.{"mountpoint": "/git","origin": "cgi:///var/www/cgi-bin/cgit","default": "/"}, {"mountpoint": "/cgit-data","origin": "file:///usr/share/cgit","default": "/"},
+
- lws_vhost_get(wsi) +
- lws_protocol_get(wsi) +
- lws_callback_on_writable_all_protocol_vhost(vhost, protocol) +
- lws_protocol_vh_priv_zalloc(vhost, protocol, size) +
- lws_protocol_vh_priv_get(vhost, protocol) +
- Generated by
+
+ 1.8.12
+
- test apps work on your platform, then either
-
+
- your user code is broken, align it to how the test apps work, or, +
- something from your code is required to show an lws problem, provide a minimal patch on a test app so it can be reproduced +
+ - test apps break on your platform, but work on, eg, x86_64, either
-
+
- toolchain or platform-specific (eg, OS) issue, or +
- lws platform support issue +
+ - test apps break everywhere
-
+
- sounds like lws problem, info to reproduce and / or a patch is appreciated +
+ - Generated by
+
+ 1.8.12
+
- 1 ERR +
- 2 WARN +
- 4 NOTICE +
- 8 INFO +
- 16 DEBUG +
- 32 PARSER +
- 64 HEADER +
- 128 EXTENSION +
- 256 CLIENT +
- 512 LATENCY +
- Tests 2.10 + 2.11: sends multiple pings on one connection. Lws policy is to only allow one active ping in flight on each connection, the rest are dropped. The autobahn test itself admits this is not part of the standard, just someone's random opinion about how they think a ws server should act. So we will fail this by design and it is no problem about RFC6455 compliance. +
- Generated by
+
+ 1.8.12
+
- '+ + data.children[i].text+''+ + makeTree(data.children[i],relPath)+' '; + } + result+='
');
+ }
+ }
+ $('#main-menu').smartmenus();
+}
diff --git a/doc/html/menudata.js b/doc/html/menudata.js
new file mode 100644
index 00000000..6df2f1dd
--- /dev/null
+++ b/doc/html/menudata.js
@@ -0,0 +1,69 @@
+var menudata={children:[
+{text:'Main Page',url:'index.html'},
+{text:'Related Pages',url:'pages.html'},
+{text:'Modules',url:'modules.html'},
+{text:'Data Structures',url:'annotated.html',children:[
+{text:'Data Structures',url:'annotated.html'},
+{text:'Data Structure Index',url:'classes.html'},
+{text:'Class Hierarchy',url:'hierarchy.html'},
+{text:'Data Fields',url:'functions.html',children:[
+{text:'All',url:'functions.html',children:[
+{text:'_',url:'functions.html#index__'},
+{text:'a',url:'functions.html#index_a'},
+{text:'b',url:'functions.html#index_b'},
+{text:'c',url:'functions.html#index_c'},
+{text:'d',url:'functions.html#index_d'},
+{text:'e',url:'functions.html#index_e'},
+{text:'f',url:'functions.html#index_f'},
+{text:'g',url:'functions.html#index_g'},
+{text:'h',url:'functions.html#index_h'},
+{text:'i',url:'functions.html#index_i'},
+{text:'k',url:'functions.html#index_k'},
+{text:'l',url:'functions.html#index_l'},
+{text:'m',url:'functions.html#index_m'},
+{text:'n',url:'functions.html#index_n'},
+{text:'o',url:'functions.html#index_o'},
+{text:'p',url:'functions.html#index_p'},
+{text:'r',url:'functions.html#index_r'},
+{text:'s',url:'functions.html#index_s'},
+{text:'t',url:'functions.html#index_t'},
+{text:'u',url:'functions.html#index_u'},
+{text:'v',url:'functions.html#index_v'},
+{text:'w',url:'functions.html#index_w'}]},
+{text:'Functions',url:'functions_func.html'},
+{text:'Variables',url:'functions_vars.html',children:[
+{text:'_',url:'functions_vars.html#index__'},
+{text:'a',url:'functions_vars.html#index_a'},
+{text:'b',url:'functions_vars.html#index_b'},
+{text:'c',url:'functions_vars.html#index_c'},
+{text:'d',url:'functions_vars.html#index_d'},
+{text:'e',url:'functions_vars.html#index_e'},
+{text:'f',url:'functions_vars.html#index_f'},
+{text:'g',url:'functions_vars.html#index_g'},
+{text:'h',url:'functions_vars.html#index_h'},
+{text:'i',url:'functions_vars.html#index_i'},
+{text:'k',url:'functions_vars.html#index_k'},
+{text:'l',url:'functions_vars.html#index_l'},
+{text:'m',url:'functions_vars.html#index_m'},
+{text:'n',url:'functions_vars.html#index_n'},
+{text:'o',url:'functions_vars.html#index_o'},
+{text:'p',url:'functions_vars.html#index_p'},
+{text:'r',url:'functions_vars.html#index_r'},
+{text:'s',url:'functions_vars.html#index_s'},
+{text:'t',url:'functions_vars.html#index_t'},
+{text:'u',url:'functions_vars.html#index_u'},
+{text:'v',url:'functions_vars.html#index_v'},
+{text:'w',url:'functions_vars.html#index_w'}]}]}]},
+{text:'Files',url:'files.html',children:[
+{text:'File List',url:'files.html'},
+{text:'Globals',url:'globals.html',children:[
+{text:'All',url:'globals.html',children:[
+{text:'e',url:'globals.html#index_e'},
+{text:'l',url:'globals_l.html#index_l'}]},
+{text:'Functions',url:'globals_func.html',children:[
+{text:'l',url:'globals_func.html#index_l'}]},
+{text:'Typedefs',url:'globals_type.html'},
+{text:'Enumerations',url:'globals_enum.html'},
+{text:'Enumerator',url:'globals_eval.html',children:[
+{text:'e',url:'globals_eval.html#index_e'},
+{text:'l',url:'globals_eval.html#index_l'}]}]}]}]}
diff --git a/doc/html/navtreedata.js b/doc/html/navtreedata.js
index 920f46ec..d9efa4a7 100644
--- a/doc/html/navtreedata.js
+++ b/doc/html/navtreedata.js
@@ -136,7 +136,7 @@ var NAVTREEINDEX =
"group__context-and-vhost.html#gga41c2d763f78cc248df3b9f8645dbd2a5a87a824b2e812f4c3e7f2c4a1ea4f8abd",
"group__service.html#ga9b3cc4473fd8848e5bbee7f310712939",
"group__wsstatus.html#gaeca4afc94b1f026034f99cbba37e2f85",
-"structlws__http__mount.html#a6a9b1492a0b9749e39bd19932717a0b7"
+"structlws__http__mount.html#a614364c770b0bd4db464ad65cddab477"
];
var SYNCONMSG = 'click to disable panel synchronisation';
diff --git a/doc/html/navtreeindex0.js b/doc/html/navtreeindex0.js
index ad266faf..53872dbd 100644
--- a/doc/html/navtreeindex0.js
+++ b/doc/html/navtreeindex0.js
@@ -223,12 +223,12 @@ var NAVTREEINDEX0 =
"group__context-and-vhost.html#ga8ee0314028755f1ddfa9428e09b4fddb":[9,4,4],
"group__context-and-vhost.html#ga94e6cc2223c4eec316b13bcebc3628b6":[11,0,0,0,118],
"group__context-and-vhost.html#ga94e6cc2223c4eec316b13bcebc3628b6":[9,4,10],
-"group__context-and-vhost.html#ga98d88c9080fd89c37114363a6474ea73":[11,0,0,0,169],
"group__context-and-vhost.html#ga98d88c9080fd89c37114363a6474ea73":[9,4,13],
+"group__context-and-vhost.html#ga98d88c9080fd89c37114363a6474ea73":[11,0,0,0,169],
"group__context-and-vhost.html#gae2134657cdd2ea7a59e13ad314e4c50d":[11,0,0,0,117],
"group__context-and-vhost.html#gae2134657cdd2ea7a59e13ad314e4c50d":[9,4,9],
-"group__context-and-vhost.html#gaeb12f934bfd178bd2132a9e73fc641da":[9,4,5],
"group__context-and-vhost.html#gaeb12f934bfd178bd2132a9e73fc641da":[11,0,0,0,73],
+"group__context-and-vhost.html#gaeb12f934bfd178bd2132a9e73fc641da":[9,4,5],
"group__context-and-vhost.html#gaf2fff58562caab7510c41eeac85a8648":[11,0,0,0,74],
"group__context-and-vhost.html#gaf2fff58562caab7510c41eeac85a8648":[9,4,6],
"group__context-and-vhost.html#gga41c2d763f78cc248df3b9f8645dbd2a5a1b2f8bde0f62adc7ebe81b2043f34c0c":[11,0,0,0,26,8],
diff --git a/doc/html/navtreeindex1.js b/doc/html/navtreeindex1.js
index 0d647c00..86a63bc4 100644
--- a/doc/html/navtreeindex1.js
+++ b/doc/html/navtreeindex1.js
@@ -198,8 +198,8 @@ var NAVTREEINDEX1 =
"group__misc.html#ga9f37d0e357de2ab4170723fcdb665d21":[9,8,10],
"group__misc.html#gaa194584fff9698f3b280658f770ccd0f":[11,0,0,0,165],
"group__misc.html#gaa194584fff9698f3b280658f770ccd0f":[9,8,11],
-"group__misc.html#gab321ed812f46f6dc7ef9e3ca6f00cf1b":[9,8,9],
"group__misc.html#gab321ed812f46f6dc7ef9e3ca6f00cf1b":[11,0,0,0,141],
+"group__misc.html#gab321ed812f46f6dc7ef9e3ca6f00cf1b":[9,8,9],
"group__misc.html#gac6abfc0b2bd5b2f09281a4432bb2f5f0":[9,8,4],
"group__misc.html#gac6abfc0b2bd5b2f09281a4432bb2f5f0":[11,0,0,0,92],
"group__misc.html#gacae4d7b6a8d22e4c2d82ff8b12c1e234":[9,8,1],
@@ -238,8 +238,8 @@ var NAVTREEINDEX1 =
"group__sending-data.html#gga98b099cf8c1c7e38ad78501f270e193dabb6705e1d1327cdda5025be28f07712e":[9,13,0,3],
"group__sending-data.html#gga98b099cf8c1c7e38ad78501f270e193dabb6705e1d1327cdda5025be28f07712e":[11,0,0,0,35,3],
"group__sending-data.html#gga98b099cf8c1c7e38ad78501f270e193dae7d8a025a65524652fe9e24c2654c935":[11,0,0,0,35,6],
-"group__sending-data.html#gga98b099cf8c1c7e38ad78501f270e193daf6486c0dba50c44198100717721d9ab2":[11,0,0,0,35,1],
"group__sending-data.html#gga98b099cf8c1c7e38ad78501f270e193daf6486c0dba50c44198100717721d9ab2":[9,13,0,1],
+"group__sending-data.html#gga98b099cf8c1c7e38ad78501f270e193daf6486c0dba50c44198100717721d9ab2":[11,0,0,0,35,1],
"group__sending-data.html#gga98b099cf8c1c7e38ad78501f270e193dafe5a38e940ce56708ac814627e9c0917":[9,13,0,4],
"group__sending-data.html#gga98b099cf8c1c7e38ad78501f270e193dafe5a38e940ce56708ac814627e9c0917":[11,0,0,0,35,7],
"group__service.html":[9,0],
@@ -247,7 +247,7 @@ var NAVTREEINDEX1 =
"group__service.html#ga29c246707997ab7a466aa709aecd2d7b":[11,0,0,0,61],
"group__service.html#ga4fd9d714434ca499e2b3f7dbba86f241":[11,0,0,0,137],
"group__service.html#ga4fd9d714434ca499e2b3f7dbba86f241":[9,0,3],
-"group__service.html#ga53e3d0801dfda7960a7249dd559e68a2":[11,0,0,0,60],
"group__service.html#ga53e3d0801dfda7960a7249dd559e68a2":[9,0,0],
+"group__service.html#ga53e3d0801dfda7960a7249dd559e68a2":[11,0,0,0,60],
"group__service.html#ga9b3cc4473fd8848e5bbee7f310712939":[11,0,0,0,140]
};
diff --git a/doc/html/navtreeindex2.js b/doc/html/navtreeindex2.js
index 0f7ee620..26a2915f 100644
--- a/doc/html/navtreeindex2.js
+++ b/doc/html/navtreeindex2.js
@@ -3,8 +3,8 @@ var NAVTREEINDEX2 =
"group__service.html#ga9b3cc4473fd8848e5bbee7f310712939":[9,0,6],
"group__service.html#gad82efa5466d14a9f05aa06416375b28d":[11,0,0,0,138],
"group__service.html#gad82efa5466d14a9f05aa06416375b28d":[9,0,4],
-"group__service.html#gaebf426eda371ba23642fc11d8e0ace6b":[9,0,5],
"group__service.html#gaebf426eda371ba23642fc11d8e0ace6b":[11,0,0,0,139],
+"group__service.html#gaebf426eda371ba23642fc11d8e0ace6b":[9,0,5],
"group__service.html#gaf95bd0c663d6516a0c80047d9b1167a8":[11,0,0,0,136],
"group__service.html#gaf95bd0c663d6516a0c80047d9b1167a8":[9,0,2],
"group__sha.html":[9,11],
@@ -12,13 +12,13 @@ var NAVTREEINDEX2 =
"group__sha.html#ga66316e6a5a0644a09d5a10e919dfdd8d":[11,0,0,0,51],
"group__sha.html#ga7b09ab74646266f0b555103b3bb8dfe5":[11,0,0,0,146],
"group__sha.html#ga7b09ab74646266f0b555103b3bb8dfe5":[9,11,2],
-"group__sha.html#gaf39765e4a3b413efb65e4698b2ec3575":[9,11,1],
"group__sha.html#gaf39765e4a3b413efb65e4698b2ec3575":[11,0,0,0,52],
+"group__sha.html#gaf39765e4a3b413efb65e4698b2ec3575":[9,11,1],
"group__smtp.html":[9,14],
"group__smtp.html#ga116be79bf44f9dc2a97f46e051fe4dc0":[9,14,1],
"group__smtp.html#ga116be79bf44f9dc2a97f46e051fe4dc0":[11,0,0,0,37],
-"group__smtp.html#ga25298a5afc1074e13b2d5711a86432b2":[9,14,3],
"group__smtp.html#ga25298a5afc1074e13b2d5711a86432b2":[11,0,0,0,78],
+"group__smtp.html#ga25298a5afc1074e13b2d5711a86432b2":[9,14,3],
"group__smtp.html#ga5e535e346d92a9daf00be33abf79d4eb":[9,14,2],
"group__smtp.html#ga5e535e346d92a9daf00be33abf79d4eb":[11,0,0,0,77],
"group__smtp.html#ga77fc9b56a1bb39484844981ec375fc29":[11,0,0,0,79],
@@ -27,8 +27,8 @@ var NAVTREEINDEX2 =
"group__smtp.html#gga116be79bf44f9dc2a97f46e051fe4dc0a1dfec948a864205cec875f63cbe0d4ad":[11,0,0,0,37,3],
"group__smtp.html#gga116be79bf44f9dc2a97f46e051fe4dc0a29e5b0ecf75375b5a643faa3d6222b7c":[9,14,1,0],
"group__smtp.html#gga116be79bf44f9dc2a97f46e051fe4dc0a29e5b0ecf75375b5a643faa3d6222b7c":[11,0,0,0,37,0],
-"group__smtp.html#gga116be79bf44f9dc2a97f46e051fe4dc0a2c2ed16ffc572326e3040684084b21d5":[11,0,0,0,37,8],
"group__smtp.html#gga116be79bf44f9dc2a97f46e051fe4dc0a2c2ed16ffc572326e3040684084b21d5":[9,14,1,8],
+"group__smtp.html#gga116be79bf44f9dc2a97f46e051fe4dc0a2c2ed16ffc572326e3040684084b21d5":[11,0,0,0,37,8],
"group__smtp.html#gga116be79bf44f9dc2a97f46e051fe4dc0a38fba41f28d754e38079b31418a86a69":[11,0,0,0,37,7],
"group__smtp.html#gga116be79bf44f9dc2a97f46e051fe4dc0a38fba41f28d754e38079b31418a86a69":[9,14,1,7],
"group__smtp.html#gga116be79bf44f9dc2a97f46e051fe4dc0a85e3c452950c09a79086bff4b9be5c14":[11,0,0,0,37,6],
@@ -42,8 +42,8 @@ var NAVTREEINDEX2 =
"group__smtp.html#gga116be79bf44f9dc2a97f46e051fe4dc0ab89442b7a3ca2b94c3cdcf33756eb933":[9,14,1,1],
"group__smtp.html#gga116be79bf44f9dc2a97f46e051fe4dc0ab89442b7a3ca2b94c3cdcf33756eb933":[11,0,0,0,37,1],
"group__sock-adopt.html":[9,15],
-"group__sock-adopt.html#gab2d045df0f81afe00891aaed312d552b":[9,15,1],
"group__sock-adopt.html#gab2d045df0f81afe00891aaed312d552b":[11,0,0,0,50],
+"group__sock-adopt.html#gab2d045df0f81afe00891aaed312d552b":[9,15,1],
"group__sock-adopt.html#gabe71b7462afb21c767bdc67334f305af":[11,0,0,0,49],
"group__sock-adopt.html#gabe71b7462afb21c767bdc67334f305af":[9,15,0],
"group__timeout.html":[9,3],
@@ -77,8 +77,8 @@ var NAVTREEINDEX2 =
"group__usercb.html":[9,16],
"group__usercb.html#gad4fcb82e68d60ffacca61a3f783a0a2f":[11,0,0,0,8],
"group__usercb.html#gad4fcb82e68d60ffacca61a3f783a0a2f":[9,16,0],
-"group__usercb.html#gad62860e19975ba4c4af401c3cdb6abf7":[11,0,0,0,22],
"group__usercb.html#gad62860e19975ba4c4af401c3cdb6abf7":[9,16,1],
+"group__usercb.html#gad62860e19975ba4c4af401c3cdb6abf7":[11,0,0,0,22],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a026502768778b8d79d62dd0fe4375fc6":[11,0,0,0,22,17],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a026502768778b8d79d62dd0fe4375fc6":[9,16,1,17],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a0418587d5083bb4850faa438648496ba":[11,0,0,0,22,49],
@@ -94,8 +94,8 @@ var NAVTREEINDEX2 =
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a1df60f314710236f9b53efbf468da768":[11,0,0,0,22,33],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a1df60f314710236f9b53efbf468da768":[9,16,1,33],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a23b90b5e5146e760bc3123ae1fd2a6e5":[11,0,0,0,22,40],
-"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a24d39bf1cfc0bad9d92da9ac1717e439":[11,0,0,0,22,0],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a24d39bf1cfc0bad9d92da9ac1717e439":[9,16,1,0],
+"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a24d39bf1cfc0bad9d92da9ac1717e439":[11,0,0,0,22,0],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a2db02fc6e1c17ab62b52109d1aa9d738":[11,0,0,0,22,7],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a2db02fc6e1c17ab62b52109d1aa9d738":[9,16,1,7],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a2fce9a8608220f32abbf1422a5498804":[11,0,0,0,22,14],
@@ -117,21 +117,21 @@ var NAVTREEINDEX2 =
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a7e12418eec9bce85735e6460176ab604":[11,0,0,0,22,3],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a7ec8e2e9557ee02a4fc9f7dec7e2babc":[11,0,0,0,22,11],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a7ec8e2e9557ee02a4fc9f7dec7e2babc":[9,16,1,11],
-"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a838b18d255c1b94a533287ba302a2eba":[9,16,1,5],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a838b18d255c1b94a533287ba302a2eba":[11,0,0,0,22,5],
+"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a838b18d255c1b94a533287ba302a2eba":[9,16,1,5],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a8909732521d379179003d97ab7a05428":[11,0,0,0,22,35],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a8909732521d379179003d97ab7a05428":[9,16,1,35],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a89862929a72bff65257ca1d51a0fce4d":[11,0,0,0,22,52],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a8e8b2e6dbeac76d8d126947d2166a514":[11,0,0,0,22,10],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a8e8b2e6dbeac76d8d126947d2166a514":[9,16,1,10],
-"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a909cc2a7018864b0b71abacc4058fd8f":[11,0,0,0,22,24],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a909cc2a7018864b0b71abacc4058fd8f":[9,16,1,24],
+"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a909cc2a7018864b0b71abacc4058fd8f":[11,0,0,0,22,24],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a982579753e70e59a9ea13ce628ac891a":[11,0,0,0,22,58],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7a982579753e70e59a9ea13ce628ac891a":[9,16,1,41],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aa46f705dcf97502e95627ffde614f98b":[11,0,0,0,22,37],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aa46f705dcf97502e95627ffde614f98b":[9,16,1,37],
-"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aa536e574a642ff3ab9e12bff7ba2c6a2":[9,16,1,2],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aa536e574a642ff3ab9e12bff7ba2c6a2":[11,0,0,0,22,2],
+"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aa536e574a642ff3ab9e12bff7ba2c6a2":[9,16,1,2],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aa5cc921b7697743017a533822a3d556a":[11,0,0,0,22,56],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aa5cc921b7697743017a533822a3d556a":[9,16,1,39],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aa627548e1296e654fcfab463ec3c9587":[11,0,0,0,22,15],
@@ -152,8 +152,8 @@ var NAVTREEINDEX2 =
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ac4c68e00efcf1ff7bda7ada462aff8ae":[11,0,0,0,22,13],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ac4c68e00efcf1ff7bda7ada462aff8ae":[9,16,1,13],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ac8c0ae966ef1877e0020c0077ff2e4a4":[11,0,0,0,22,41],
-"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aca834dc035b7f7486f9ce40fde54fe9e":[9,16,1,30],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aca834dc035b7f7486f9ce40fde54fe9e":[11,0,0,0,22,30],
+"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aca834dc035b7f7486f9ce40fde54fe9e":[9,16,1,30],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7accd8753672d319a30b4b4c2fb775e84d":[11,0,0,0,22,20],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7accd8753672d319a30b4b4c2fb775e84d":[9,16,1,20],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ad5d34583e3556e153eda91620b48cc49":[11,0,0,0,22,27],
@@ -164,16 +164,16 @@ var NAVTREEINDEX2 =
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ad8c6207b0c4e732f3d507f0fb79370e8":[11,0,0,0,22,1],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7adfb41c92e2522712207ef7f2462b5e34":[11,0,0,0,22,31],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7adfb41c92e2522712207ef7f2462b5e34":[9,16,1,31],
-"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ae4986291b7a810fe290851d73bebeb1c":[9,16,1,21],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ae4986291b7a810fe290851d73bebeb1c":[11,0,0,0,22,21],
+"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ae4986291b7a810fe290851d73bebeb1c":[9,16,1,21],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ae5ad65d779b7eab32ab67ceff91a3bac":[11,0,0,0,22,23],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ae5ad65d779b7eab32ab67ceff91a3bac":[9,16,1,23],
-"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ae8d1de0bb56e03aa58cb4d44b18edd2e":[11,0,0,0,22,12],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ae8d1de0bb56e03aa58cb4d44b18edd2e":[9,16,1,12],
-"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ae9734e1d7af2abf291665ce9e4a728d3":[11,0,0,0,22,19],
+"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ae8d1de0bb56e03aa58cb4d44b18edd2e":[11,0,0,0,22,12],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ae9734e1d7af2abf291665ce9e4a728d3":[9,16,1,19],
-"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aeb0cec65ec82a713cd01e9ca9aeeb5e6":[11,0,0,0,22,57],
+"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7ae9734e1d7af2abf291665ce9e4a728d3":[11,0,0,0,22,19],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aeb0cec65ec82a713cd01e9ca9aeeb5e6":[9,16,1,40],
+"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7aeb0cec65ec82a713cd01e9ca9aeeb5e6":[11,0,0,0,22,57],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7af6cf80e57aae8ba0a57a5c456b1fe026":[11,0,0,0,22,55],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7afc4b2f72cc9e424a750b506ce0cc4310":[11,0,0,0,22,51],
"group__usercb.html#ggad62860e19975ba4c4af401c3cdb6abf7afd8fd77a1cc9405fcb4f26915d7f2d01":[11,0,0,0,22,29],
@@ -200,8 +200,8 @@ var NAVTREEINDEX2 =
"group__vhost-mounts.html#gga31eca18e50cb4357480f2fcad36ff437a8894d16316863077dfe530963ca59f67":[11,0,0,0,32,5],
"group__vhost-mounts.html#gga31eca18e50cb4357480f2fcad36ff437a946a88cf9c852eed2c0317f4115d19da":[9,4,0,2,6],
"group__vhost-mounts.html#gga31eca18e50cb4357480f2fcad36ff437a946a88cf9c852eed2c0317f4115d19da":[11,0,0,0,32,6],
-"group__vhost-mounts.html#gga31eca18e50cb4357480f2fcad36ff437aec137a2434851bd856ceebfb697b9970":[11,0,0,0,32,4],
"group__vhost-mounts.html#gga31eca18e50cb4357480f2fcad36ff437aec137a2434851bd856ceebfb697b9970":[9,4,0,2,4],
+"group__vhost-mounts.html#gga31eca18e50cb4357480f2fcad36ff437aec137a2434851bd856ceebfb697b9970":[11,0,0,0,32,4],
"group__vhost-mounts.html#gga31eca18e50cb4357480f2fcad36ff437afbd10eb4777517ed1f6bfdcf3b9ea1d1":[9,4,0,2,1],
"group__vhost-mounts.html#gga31eca18e50cb4357480f2fcad36ff437afbd10eb4777517ed1f6bfdcf3b9ea1d1":[11,0,0,0,32,1],
"group__wsclose.html":[9,17],
@@ -218,25 +218,25 @@ var NAVTREEINDEX2 =
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a3ffa38d5081b85fb739e02a747ccf2c4":[9,17,0,0],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a462c99b05459df700919cfd3f53c8276":[11,0,0,0,25,4],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a462c99b05459df700919cfd3f53c8276":[9,17,0,3],
-"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a4b8a3b7ce6f731e5248e4b0fb64a5044":[9,17,0,5],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a4b8a3b7ce6f731e5248e4b0fb64a5044":[11,0,0,0,25,6],
-"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a68b3d34bebd88547dcfa5cadba0acd6c":[9,17,0,6],
+"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a4b8a3b7ce6f731e5248e4b0fb64a5044":[9,17,0,5],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a68b3d34bebd88547dcfa5cadba0acd6c":[11,0,0,0,25,7],
-"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a7aef2da0062da606eeb35aaca5cf9050":[11,0,0,0,25,8],
+"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a68b3d34bebd88547dcfa5cadba0acd6c":[9,17,0,6],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a7aef2da0062da606eeb35aaca5cf9050":[9,17,0,7],
+"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a7aef2da0062da606eeb35aaca5cf9050":[11,0,0,0,25,8],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a9737a68759e739856b150ff9dfa30218":[11,0,0,0,25,2],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985a9737a68759e739856b150ff9dfa30218":[9,17,0,1],
-"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ac6a161822783ee873be1c66f48d14e0e":[11,0,0,0,25,11],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ac6a161822783ee873be1c66f48d14e0e":[9,17,0,10],
+"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ac6a161822783ee873be1c66f48d14e0e":[11,0,0,0,25,11],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985acc9a317c70363dd88e823e066b2c73b7":[11,0,0,0,25,0],
-"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ad0869604d79e13700ae5d196a431b350":[9,17,0,11],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ad0869604d79e13700ae5d196a431b350":[11,0,0,0,25,12],
-"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ad09e68295eabdddcba4e332fbea70ae5":[11,0,0,0,25,9],
+"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ad0869604d79e13700ae5d196a431b350":[9,17,0,11],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ad09e68295eabdddcba4e332fbea70ae5":[9,17,0,8],
-"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ad2b477a91c8445bf34ecd43977f9b390":[11,0,0,0,25,13],
+"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ad09e68295eabdddcba4e332fbea70ae5":[11,0,0,0,25,9],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ad2b477a91c8445bf34ecd43977f9b390":[9,17,0,12],
-"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985af90cb98d983ad3d4c79df9b6f3d4a4d2":[11,0,0,0,25,5],
+"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985ad2b477a91c8445bf34ecd43977f9b390":[11,0,0,0,25,13],
"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985af90cb98d983ad3d4c79df9b6f3d4a4d2":[9,17,0,4],
+"group__wsclose.html#ggae399c571df32ba532c0ca67da9284985af90cb98d983ad3d4c79df9b6f3d4a4d2":[11,0,0,0,25,5],
"group__wsstatus.html":[9,18],
"group__wsstatus.html#ga08e9ee165fca503fd9427d55cfecac37":[9,18,3],
"group__wsstatus.html#ga08e9ee165fca503fd9427d55cfecac37":[11,0,0,0,115],
@@ -244,8 +244,8 @@ var NAVTREEINDEX2 =
"group__wsstatus.html#ga26a140623d202dd2bf2004deb6994baa":[11,0,0,0,116],
"group__wsstatus.html#ga2bb3655329b4651cd06f79ee3a764421":[9,18,6],
"group__wsstatus.html#ga2bb3655329b4651cd06f79ee3a764421":[11,0,0,0,133],
-"group__wsstatus.html#ga3df5045656dfb6b0e63a38de2dca79d2":[11,0,0,0,100],
"group__wsstatus.html#ga3df5045656dfb6b0e63a38de2dca79d2":[9,18,1],
+"group__wsstatus.html#ga3df5045656dfb6b0e63a38de2dca79d2":[11,0,0,0,100],
"group__wsstatus.html#ga4ad226d5e01024b4046f4a5a37199aa1":[9,18,2],
"group__wsstatus.html#ga4ad226d5e01024b4046f4a5a37199aa1":[11,0,0,0,114],
"group__wsstatus.html#gaccd9c59336efad8af0554f79cc5966fd":[9,18,0],
diff --git a/doc/html/navtreeindex3.js b/doc/html/navtreeindex3.js
index 7b36d3d4..a4dbebd2 100644
--- a/doc/html/navtreeindex3.js
+++ b/doc/html/navtreeindex3.js
@@ -3,8 +3,8 @@ var NAVTREEINDEX3 =
"group__wsstatus.html#gaeca4afc94b1f026034f99cbba37e2f85":[9,18,5],
"group__wsstatus.html#gaeca4afc94b1f026034f99cbba37e2f85":[11,0,0,0,124],
"hierarchy.html":[10,2],
-"index.html":[0],
"index.html":[],
+"index.html":[0],
"libwebsockets_8h.html":[11,0,0,0],
"libwebsockets_8h.html#a0b056fdcf949a838ff82209b4a627dd9":[11,0,0,0,171],
"libwebsockets_8h.html#a17f5fc891b31d2920bd18b0d66d6cb25":[11,0,0,0,176],
@@ -242,12 +242,12 @@ var NAVTREEINDEX3 =
"structlws__gs__event__args.html#a477274f8ca22ba7411b9285b9dc8dd06":[9,10,0,3,1],
"structlws__gs__event__args.html#acd17e4f9f91f7f9a8f0fbf0744a3a463":[9,10,0,3,0],
"structlws__http__mount.html":[9,4,0,1],
-"structlws__http__mount.html#a0109baf93f23c07c824c997c3533ee44":[9,4,0,1,10],
-"structlws__http__mount.html#a05347d92c3d379809564bd4f3eab259b":[9,4,0,1,15],
-"structlws__http__mount.html#a11ea62b952710d59733dbcf9794a5773":[9,4,0,1,9],
-"structlws__http__mount.html#a21d86fd6043ec00e121ababbc29af39a":[9,4,0,1,13],
-"structlws__http__mount.html#a4283e30ea89d27ae7d061ad760d1d146":[9,4,0,1,2],
-"structlws__http__mount.html#a4437423df85ee3dbcae0e15974c89ec7":[9,4,0,1,8],
-"structlws__http__mount.html#a4a7239d6d4c03986e6e1a72abb6c83aa":[9,4,0,1,5],
-"structlws__http__mount.html#a614364c770b0bd4db464ad65cddab477":[9,4,0,1,0]
+"structlws__http__mount.html#a0109baf93f23c07c824c997c3533ee44":[9,4,0,1,11],
+"structlws__http__mount.html#a05347d92c3d379809564bd4f3eab259b":[9,4,0,1,16],
+"structlws__http__mount.html#a11ea62b952710d59733dbcf9794a5773":[9,4,0,1,10],
+"structlws__http__mount.html#a21d86fd6043ec00e121ababbc29af39a":[9,4,0,1,14],
+"structlws__http__mount.html#a2f6c7dbc2d714b7259c67b7744d4ff98":[9,4,0,1,1],
+"structlws__http__mount.html#a4283e30ea89d27ae7d061ad760d1d146":[9,4,0,1,3],
+"structlws__http__mount.html#a4437423df85ee3dbcae0e15974c89ec7":[9,4,0,1,9],
+"structlws__http__mount.html#a4a7239d6d4c03986e6e1a72abb6c83aa":[9,4,0,1,6]
};
diff --git a/doc/html/navtreeindex4.js b/doc/html/navtreeindex4.js
index 69884940..d68ad8dc 100644
--- a/doc/html/navtreeindex4.js
+++ b/doc/html/navtreeindex4.js
@@ -1,13 +1,14 @@
var NAVTREEINDEX4 =
{
-"structlws__http__mount.html#a6a9b1492a0b9749e39bd19932717a0b7":[9,4,0,1,14],
-"structlws__http__mount.html#a8316dd183ffbef50419a5a4968d35d84":[9,4,0,1,3],
-"structlws__http__mount.html#aa2391bfcada0b7a290b3c6651f64586c":[9,4,0,1,11],
-"structlws__http__mount.html#aabec1a326780aafe11b977000983be0c":[9,4,0,1,1],
-"structlws__http__mount.html#ac8489b60b8f969eb19c9abbdeac90743":[9,4,0,1,12],
-"structlws__http__mount.html#ae137203040c6153694bd88a708da5395":[9,4,0,1,4],
-"structlws__http__mount.html#ae7b5c0f4c5408061e6ea3a8d281f45af":[9,4,0,1,6],
-"structlws__http__mount.html#ae90d1efe7178199fad39de2926902ee4":[9,4,0,1,7],
+"structlws__http__mount.html#a614364c770b0bd4db464ad65cddab477":[9,4,0,1,0],
+"structlws__http__mount.html#a6a9b1492a0b9749e39bd19932717a0b7":[9,4,0,1,15],
+"structlws__http__mount.html#a8316dd183ffbef50419a5a4968d35d84":[9,4,0,1,4],
+"structlws__http__mount.html#aa2391bfcada0b7a290b3c6651f64586c":[9,4,0,1,12],
+"structlws__http__mount.html#aabec1a326780aafe11b977000983be0c":[9,4,0,1,2],
+"structlws__http__mount.html#ac8489b60b8f969eb19c9abbdeac90743":[9,4,0,1,13],
+"structlws__http__mount.html#ae137203040c6153694bd88a708da5395":[9,4,0,1,5],
+"structlws__http__mount.html#ae7b5c0f4c5408061e6ea3a8d281f45af":[9,4,0,1,7],
+"structlws__http__mount.html#ae90d1efe7178199fad39de2926902ee4":[9,4,0,1,8],
"structlws__plat__file__ops.html":[9,20,0],
"structlws__plat__file__ops.html#a01f483807a9862736b17ba9ed5110c40":[9,20,0,2],
"structlws__plat__file__ops.html#a034ec96f2fbaf52b4aa3e82d20795f7b":[9,20,0,0],
@@ -51,14 +52,14 @@ var NAVTREEINDEX4 =
"structlws__process__html__state.html#adcafd17704775b4bbeea9561fb340968":[9,6,1,1,0],
"structlws__process__html__state.html#af0732884ef891e24fe5fa237ebaa21a3":[9,6,1,1,4],
"structlws__process__html__state.html#af21119890fdfebe28fb5c4dabfc1bdf5":[9,6,1,1,1],
-"structlws__protocol__vhost__options.html":[9,4,0,0],
"structlws__protocol__vhost__options.html":[9,4,2],
+"structlws__protocol__vhost__options.html":[9,4,0,0],
"structlws__protocol__vhost__options.html#a0640a92513c70ee6b9b295a9ad1658e7":[9,4,0,0,3],
"structlws__protocol__vhost__options.html#a0640a92513c70ee6b9b295a9ad1658e7":[9,4,2,3],
-"structlws__protocol__vhost__options.html#abc714ddb4171756fc8196e9823a1e21c":[9,4,0,0,1],
"structlws__protocol__vhost__options.html#abc714ddb4171756fc8196e9823a1e21c":[9,4,2,1],
-"structlws__protocol__vhost__options.html#acf9db77f8eb64cd4e314be9b43d8a8b9":[9,4,0,0,0],
+"structlws__protocol__vhost__options.html#abc714ddb4171756fc8196e9823a1e21c":[9,4,0,0,1],
"structlws__protocol__vhost__options.html#acf9db77f8eb64cd4e314be9b43d8a8b9":[9,4,2,0],
+"structlws__protocol__vhost__options.html#acf9db77f8eb64cd4e314be9b43d8a8b9":[9,4,0,0,0],
"structlws__protocol__vhost__options.html#afd99fbc90be51ea2465b550c2ec47822":[9,4,2,2],
"structlws__protocol__vhost__options.html#afd99fbc90be51ea2465b550c2ec47822":[9,4,0,0,2],
"structlws__protocols.html":[9,10,1],
@@ -76,12 +77,12 @@ var NAVTREEINDEX4 =
"structlws__session__info.html#afb924864b70f40372920688a5c1c895e":[9,10,0,2,2],
"structlws__token__limits.html":[9,6,4,1],
"structlws__token__limits.html#a6ec712306cbf8585bce7a56758a3ceff":[9,6,4,1,0],
-"structlws__tokens.html":[9,6,4,0],
"structlws__tokens.html":[9,6,6],
+"structlws__tokens.html":[9,6,4,0],
"structlws__tokens.html#a855b7375d1d58516c0ecd4b60e9a7766":[9,6,6,1],
"structlws__tokens.html#a855b7375d1d58516c0ecd4b60e9a7766":[9,6,4,0,1],
-"structlws__tokens.html#a9f3635412bc71a5cb78e9862b55f10cd":[9,6,4,0,0],
"structlws__tokens.html#a9f3635412bc71a5cb78e9862b55f10cd":[9,6,6,0],
+"structlws__tokens.html#a9f3635412bc71a5cb78e9862b55f10cd":[9,6,4,0,0],
"structlwsgw__hash.html":[9,10,0,1],
"structlwsgw__hash.html#a29435f5cf78747d4257695b0f141d164":[9,10,0,1,0],
"structlwsgw__hash__bin.html":[9,10,0,0],
diff --git a/doc/html/structlws__http__mount.html b/doc/html/structlws__http__mount.html
index 75f633ec..fac9467c 100644
--- a/doc/html/structlws__http__mount.html
+++ b/doc/html/structlws__http__mount.html
@@ -81,6 +81,8 @@ Data Fields
#include <lib/libwebsockets.h>
enum lws_client_connect_ssl_connection_flags - flags that may be used with struct lws_client_connect_info ssl_connection member to control if and how SSL checks apply to the client connection being created
-Function Documentation
diff --git a/doc/html/group__form-parsing.html b/doc/html/group__form-parsing.html index 51c0feb8..0b3dfc32 100644 --- a/doc/html/group__form-parsing.html +++ b/doc/html/group__form-parsing.html @@ -156,9 +156,9 @@ Functionsa new file is starting to arrive
client packet payload goes out on wire unmunged only useful for security tests since normal servers cannot decode the content if used
sent the session quit
 |
+
+ libwebsockets
+
+ Lightweight C library for HTML5 websockets
+ |
+
+Introduction to CMake
+CMake is a multi-platform build tool that can generate build files for many different target platforms. See more info at http://www.cmake.org
+CMake also allows/recommends you to do "out of source"-builds, that is, the build files are separated from your sources, so there is no need to create elaborate clean scripts to get a clean source tree, instead you simply remove your build directory.
+Libwebsockets has been tested to build successfully on the following platforms with SSL support (both OpenSSL/wolfSSL):
+-
+
+Building the library and test apps
+The project settings used by CMake to generate the platform specific build files is called CMakeLists.txt. CMake then uses one of its "Generators" to output a Visual Studio project or Make file for instance. To see a list of the available generators for your platform, simply run the "cmake" command.
+Note that by default OpenSSL will be linked, if you don't want SSL support see below on how to toggle compile options.
++Building on Unix:
+-
+
NOTE2: A common option you may want to give is to set the install path, same as –prefix= with autotools. It defaults to /usr/local. You can do this by, eg
NOTE3: On machines that want libraries in lib64, you can also add the following to the cmake line
NOTE4: If you are building against a non-distro OpenSSL (eg, in order to get access to ALPN support only in newer OpenSSL versions) the nice way to express that in one cmake command is eg,
When you run the test apps using non-distro SSL, you have to force them to use your libs, not the distro ones
To get it to build on latest openssl (2016-04-10) it needed this approach
NOTE5: To build with debug info and _DEBUG for lower priority debug messages compiled in, use
NOTE6 To build on Solaris the linker needs to be informed to use lib socket and libnsl, and only builds in 64bit mode.
+-
+
+Quirk of cmake
+When changing cmake options, for some reason the only way to get it to see the changes sometimes is delete the contents of your build directory and do the cmake from scratch.
++Building on Windows (Visual Studio)
+-
+
(NOTE: There is also a cmake-gui available on Windows if you prefer that)
+NOTE2: See this link to find out the version number corresponding to your Visual Studio edition: http://superuser.com/a/194065
+-
+
+Building on Windows (MinGW)
+-
+
+Building on mbed3
+MBED3 is a non-posix embedded OS targeted on Cortex M class chips.
+ +It's quite unlike any other Posixy platform since the OS is linked statically in with lws to form one binary.
+At the minute server-only is supported and due to bugs in mbed3 network support, the port is of alpha quality. However it can serve the test html, favicon.ico and logo png and may be able to make ws connections. The binary for that including the OS, test app, lws and all the assets is only 117KB.
+0) Today mbed3 only properly works on FRDM K64F $35 Freescale Dev Board with 1MB Flash, 256KB SRAM and Ethernet.
+ +1) Get a working mbed3 environment with arm-none-eabi-cs toolchain (available in Fedora, Ubuntu and other distros)
+2) Confirm you can build things using yotta by following the getting started guide here
+https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/
+3)
+git clone https://github.com/warmcat/lws-test-server
+and cd into it
+4) mkdir -p yotta_modules ; cd yotta_modules
+5) git clone https://github.com/warmcat/libwebsockets ; mv libwebsockets websockets ; cd ..
+6) yotta target frdm-k64f-gcc
+7) yotta install
+8) yotta build
++Setting compile options
+To set compile time flags you can either use one of the CMake gui applications or do it via the command line.
++Command line
+To list available options (omit the H if you don't want the help text):
cmake -LH .. +
Then to set an option and build (for example turn off SSL support):
cmake -DLWS_WITH_SSL=0 .. +
or cmake -DLWS_WITH_SSL:BOOL=OFF ..
++Unix GUI
+If you have a curses-enabled build you simply type: (not all packages include this, my debian install does not for example).
ccmake +
+Windows GUI
+On windows CMake comes with a gui application: Start -> Programs -> CMake -> CMake (cmake-gui)
++wolfSSL/CyaSSL replacement for OpenSSL
+wolfSSL/CyaSSL is a lightweight SSL library targeted at embedded systems: https://www.wolfssl.com/wolfSSL/Products-wolfssl.html
+It contains a OpenSSL compatibility layer which makes it possible to pretty much link to it instead of OpenSSL, giving a much smaller footprint.
+NOTE: wolfssl needs to be compiled using the --enable-opensslextra flag for this to work.
+Compiling libwebsockets with wolfSSL
+NOTE: On windows use the .lib file extension for LWS_WOLFSSL_LIBRARIES instead.
+Compiling libwebsockets with CyaSSL
+NOTE: On windows use the .lib file extension for LWS_CYASSL_LIBRARIES instead.
+Building plugins outside of lws itself
+The directory ./plugin-standalone/ shows how easy it is to create plugins outside of lws itself. First build lws itself with -DLWS_WITH_PLUGINS, then use the same flow to build the standalone plugin
if you changed the default plugin directory when you built lws, you must also give the same arguments to cmake here (eg, -DCMAKE_INSTALL_PREFIX:PATH=/usr/something/else... )
Otherwise if you run lwsws or libwebsockets-test-server-v2.0, it will now find the additional plugin "libprotocol_example_standalone.so"
If you have multiple vhosts, you must enable plugins at the vhost additionally, discovered plugins are not enabled automatically for security reasons. You do this using info->pvo or for lwsws, in the JSON config.
++Reproducing HTTP2.0 tests
+You must have built and be running lws against a version of openssl that has ALPN / NPN. Most distros still have older versions. You'll know it's right by seeing
at lws startup.
+For non-SSL HTTP2.0 upgrade
For SSL / ALPN HTTP2.0 upgrade
+Cross compiling
+To enable cross-compiling libwebsockets using CMake you need to create a "Toolchain file" that you supply to CMake when generating your build files. CMake will then use the cross compilers and build paths specified in this file to look for dependencies and such.
+Libwebsockets includes an example toolchain file cross-arm-linux-gnueabihf.cmake you can use as a starting point.
+The commandline to configure for cross with this would look like
The example shows how to build with no external cross lib dependencies, you need to provide the cross libraries otherwise.
+NOTE: start from an EMPTY build directory if you had a non-cross build in there before the settings will be cached and your changes ignored.
+Additional information on cross compilation with CMake: http://www.vtk.org/Wiki/CMake_Cross_Compiling
++Memory efficiency
+Embedded server-only configuration without extensions (ie, no compression on websocket connections), but with full v13 websocket features and http server, built on ARM Cortex-A9:
+Update at 8dac94d (2013-02-18)
This shows the impact of the major configuration with/without options at 13ba5bbc633ea962d46d using Ubuntu ARM on a PandaBoard ES.
+These are accounting for static allocations from the library elf, there are additional dynamic allocations via malloc. These are a bit old now but give the right idea for relative "expense" of features.
+Static allocations, ARM9
+| .text | .rodata | .data | .bss | |
|---|---|---|---|---|
| All (no without) | 35024 | 9940 | 336 | 4104 |
| without client | 25684 | 7144 | 336 | 4104 |
| without client, exts | 21652 | 6288 | 288 | 4104 |
| without client, exts, debug[1] | 19756 | 3768 | 288 | 4104 |
| without server | 30304 | 8160 | 336 | 4104 |
| without server, exts | 25382 | 7204 | 288 | 4104 |
| without server, exts, debug[1] | 23712 | 4256 | 288 | 4104 |
[1] --disable-debug only removes messages below lwsl_notice. Since that is the default logging level the impact is not noticeable, error, warn and notice logs are all still there.
[2] 1024 fd per process is the default limit (set by ulimit) in at least Fedora and Ubuntu. You can make significant savings tailoring this to actual expected peak fds, ie, at a limit of 20, context creation allocation reduces to 4432 + 240 = 4672)
[3] known header content is freed after connection establishment
+-
+
|
+
+ libwebsockets
+
+ Lightweight C library for HTML5 websockets
+ |
+
+Daemonization
+There's a helper api lws_daemonize built by default that does everything you need to daemonize well, including creating a lock file. If you're making what's basically a daemon, just call this early in your init to fork to a headless background process and exit the starting process.
Notice stdout, stderr, stdin are all redirected to /dev/null to enforce your daemon is headless, so you'll need to sort out alternative logging, by, eg, syslog.
++Maximum number of connections
+The maximum number of connections the library can deal with is decided when it starts by querying the OS to find out how many file descriptors it is allowed to open (1024 on Fedora for example). It then allocates arrays that allow up to that many connections, minus whatever other file descriptors are in use by the user code.
+If you want to restrict that allocation, or increase it, you can use ulimit or similar to change the available number of file descriptors, and when restarted libwebsockets will adapt accordingly.
++Libwebsockets is singlethreaded
+Libwebsockets works in a serialized event loop, in a single thread.
+Directly performing websocket actions from other threads is not allowed. Aside from the internal data being inconsistent in forked() processes, the scope of a wsi (struct websocket) can end at any time during service with the socket closing and the wsi freed.
Websocket write activities should only take place in the LWS_CALLBACK_SERVER_WRITEABLE callback as described below.
[This network-programming necessity to link the issue of new data to the peer taking the previous data is not obvious to all users so let's repeat that in other words:
+***ONLY DO LWS_WRITE FROM THE WRITEABLE CALLBACK***
+There is another network-programming truism that surprises some people which is if the sink for the data cannot accept more:
+***YOU MUST PERFORM RX FLOW CONTROL***
+See the mirror protocol implementations for example code.
+Only live connections appear in the user callbacks, so this removes any possibility of trying to used closed and freed wsis.
+If you need to service other socket or file descriptors as well as the websocket ones, you can combine them together with the websocket ones in one poll loop, see "External Polling Loop support" below, and still do it all in one thread / process context.
+If you insist on trying to use it from multiple threads, take special care if you might simultaneously create more than one context from different threads.
+SSL_library_init() is called from the context create api and it also is not reentrant. So at least create the contexts sequentially.
++Only send data when socket writeable
+You should only send data on a websocket connection from the user callback LWS_CALLBACK_SERVER_WRITEABLE (or LWS_CALLBACK_CLIENT_WRITEABLE for clients).
If you want to send something, do not just send it but request a callback when the socket is writeable using
+-
+
Usually you will get called back immediately next time around the service loop, but if your peer is slow or temporarily inactive the callback will be delayed accordingly. Generating what to write and sending it should be done in the ...WRITEABLE callback.
+See the test server code for an example of how to do this.
++Do not rely on only your own WRITEABLE requests appearing
+Libwebsockets may generate additional LWS_CALLBACK_CLIENT_WRITEABLE events if it met network conditions where it had to buffer your send data internally.
So your code for LWS_CALLBACK_CLIENT_WRITEABLE needs to own the decision about what to send, it can't assume that just because the writeable callback came it really is time to send something.
It's quite possible you get an 'extra' writeable callback at any time and just need to return 0 and wait for the expected callback later.
+Closing connections from the user side
+When you want to close a connection, you do it by returning -1 from a callback for that connection.
You can provoke a callback by calling lws_callback_on_writable on the wsi, then notice in the callback you want to close it and just return -1. But usually, the decision to close is made in a callback already and returning -1 is simple.
If the socket knows the connection is dead, because the peer closed or there was an affirmitive network error like a FIN coming, then libwebsockets will take care of closing the connection automatically.
+If you have a silently dead connection, it's possible to enter a state where the send pipe on the connection is choked but no ack will ever come, so the dead connection will never become writeable. To cover that, you can use TCP keepalives (see later in this document) or pings.
++Fragmented messages
+To support fragmented messages you need to check for the final frame of a message with lws_is_final_fragment. This check can be combined with libwebsockets_remaining_packet_payload to gather the whole contents of a message, eg:
The test app libwebsockets-test-fraggle sources also show how to deal with fragmented messages.
++Debug Logging
+Also using lws_set_log_level api you may provide a custom callback to actually emit the log string. By default, this points to an internal emit function that sends to stderr. Setting it to NULL leaves it as it is instead.
A helper function lwsl_emit_syslog() is exported from the library to simplify logging to syslog. You still need to use setlogmask, openlog and closelog in your user code.
The logging apis are made available for user code.
+-
+
The difference between notice and info is that notice will be logged by default whereas info is ignored by default.
+If you are not building with _DEBUG defined, ie, without this
+then log levels below notice do not actually get compiled in.
++External Polling Loop support
+libwebsockets maintains an internal poll() array for all of its sockets, but you can instead integrate the sockets into an external polling array. That's needed if libwebsockets will cooperate with an existing poll array maintained by another server.
Four callbacks LWS_CALLBACK_ADD_POLL_FD, LWS_CALLBACK_DEL_POLL_FD, LWS_CALLBACK_SET_MODE_POLL_FD and LWS_CALLBACK_CLEAR_MODE_POLL_FD appear in the callback for protocol 0 and allow interface code to manage socket descriptors in other poll loops.
You can pass all pollfds that need service to lws_service_fd(), even if the socket or file does not belong to libwebsockets it is safe.
If libwebsocket handled it, it zeros the pollfd revents field before returning. So you can let libwebsockets try and if pollfd->revents is nonzero on return, you know it needs handling by your code.
Also note that when integrating a foreign event loop like libev or libuv where it doesn't natively use poll() semantics, and you must return a fake pollfd reflecting the real event:
+-
+
+Using with in c++ apps
+The library is ready for use by C++ apps. You can get started quickly by copying the test server
+and building it in C++ like this
+INSTALL_DATADIR is only needed because the test server uses it as shipped, if you remove the references to it in your app you don't need to define it on the g++ line either.
+Availability of header information
+HTTP Header information is managed by a pool of "ah" structs. These are a limited resource so there is pressure to free the headers and return the ah to the pool for reuse.
+For that reason header information on HTTP connections that get upgraded to websockets is lost after the ESTABLISHED callback. Anything important that isn't processed by user code before then should be copied out for later.
+For HTTP connections that don't upgrade, header info remains available the whole time.
++TCP Keepalive
+It is possible for a connection which is not being used to send to die silently somewhere between the peer and the side not sending. In this case by default TCP will just not report anything and you will never get any more incoming data or sign the link is dead until you try to send.
+To deal with getting a notification of that situation, you can choose to enable TCP keepalives on all libwebsockets sockets, when you create the context.
+To enable keepalive, set the ka_time member of the context creation parameter struct to a nonzero value (in seconds) at context creation time. You should also fill ka_probes and ka_interval in that case.
+With keepalive enabled, the TCP layer will send control packets that should stimulate a response from the peer without affecting link traffic. If the response is not coming, the socket will announce an error at poll() forcing a close.
Note that BSDs don't support keepalive time / probes / interval per-socket like Linux does. On those systems you can enable keepalive by a nonzero value in ka_time, but the systemwide kernel settings for the time / probes/ interval are used, regardless of what nonzero value is in ka_time.
+Optimizing SSL connections
+There's a member ssl_cipher_list in the lws_context_creation_info struct which allows the user code to restrict the possible cipher selection at context-creation time.
You might want to look into that to stop the ssl peers selecting a cipher which is too computationally expensive. To use it, point it to a string like
`"RC4-MD5:RC4-SHA:AES128-SHA:AES256-SHA:HIGH:!DSS:!aNULL"` +
if left NULL, then the "DEFAULT" set of ciphers are all possible to select.
You can also set it to "ALL" to allow everything (including insecure ciphers).
+Async nature of client connections
+When you call lws_client_connect_info(..) and get a wsi back, it does not mean your connection is active. It just means it started trying to connect.
Your client connection is actually active only when you receive LWS_CALLBACK_CLIENT_ESTABLISHED for it.
There's a 5 second timeout for the connection, and it may give up or die for other reasons, if any of that happens you'll get a LWS_CALLBACK_CLIENT_CONNECTION_ERROR callback on protocol 0 instead for the wsi.
After attempting the connection and getting back a non-NULL wsi you should loop calling lws_service() until one of the above callbacks occurs.
As usual, see test-client.c for example code.
+Notice that the client connection api tries to progress the connection somewhat before returning. That means it's possible to get callbacks like CONNECTION_ERROR on the new connection before your user code had a chance to get the wsi returned to identify it (in fact if the connection did fail early, NULL will be returned instead of the wsi anyway).
+To avoid that problem, you can fill in pwsi in the client connection info struct to point to a struct lws that get filled in early by the client connection api with the related wsi. You can then check for that in the callback to confirm the identity of the failing client connection.
+Lws platform-independent file access apis
+lws now exposes his internal platform file abstraction in a way that can be both used by user code to make it platform-agnostic, and be overridden or subclassed by user code. This allows things like handling the URI "directory +space" as a virtual filesystem that may or may not be backed by a regular filesystem. One example use is serving files from inside large compressed archive storage without having to unpack anything except the file being requested.
+The test server shows how to use it, basically the platform-specific part of lws prepares a file operations structure that lives in the lws context.
+The user code can get a pointer to the file operations struct
+and then can use helpers to also leverage these platform-independent file handling apis
+The user code can also override or subclass the file operations, to either wrap or replace them. An example is shown in test server.
++ECDH Support
+ECDH Certs are now supported. Enable the CMake option
cmake .. -DLWS_SSL_SERVER_WITH_ECDH_CERT=1 +
and the info->options flag
LWS_SERVER_OPTION_SSL_ECDH +
to build in support and select it at runtime.
++SMP / Multithreaded service
+SMP support is integrated into LWS without any internal threading. It's very simple to use, libwebsockets-test-server-pthread shows how to do it, use -j <n> argument there to control the number of service threads up to 32.
+Two new members are added to the info struct
unsigned int count_threads; + unsigned int fd_limit_per_thread; +
leave them at the default 0 to get the normal singlethreaded service loop.
+Set count_threads to n to tell lws you will have n simultaneous service threads operating on the context.
+There is still a single listen socket on one port, no matter how many service threads.
+When a connection is made, it is accepted by the service thread with the least connections active to perform load balancing.
+The user code is responsible for spawning n threads running the service loop associated to a specific tsi (Thread Service Index, 0 .. n - 1). See the libwebsockets-test-server-pthread for how to do.
+If you leave fd_limit_per_thread at 0, then the process limit of fds is shared between the service threads; if you process was allowed 1024 fds overall then each thread is limited to 1024 / n.
+You can set fd_limit_per_thread to a nonzero number to control this manually, eg the overall supported fd limit is less than the process allowance.
+You can control the context basic data allocation for multithreading from Cmake using -DLWS_MAX_SMP=, if not given it's set to 32. The serv_buf allocation for the threads (currently 4096) is made at runtime only for active threads.
+Because lws will limit the requested number of actual threads supported according to LWS_MAX_SMP, there is an api lws_get_count_threads(context) to discover how many threads were actually allowed when the context was created.
+It's required to implement locking in the user code in the same way that libwebsockets-test-server-pthread does it, for the FD locking callbacks.
+There is no knowledge or dependency in lws itself about pthreads. How the locking is implemented is entirely up to the user code.
++Libev / Libuv support
+You can select either or both
-DLWS_WITH_LIBEV=1 + -DLWS_WITH_LIBUV=1 +
at cmake configure-time. The user application may use one of the context init options flags
LWS_SERVER_OPTION_LIBEV + LWS_SERVER_OPTION_LIBUV +
to indicate it will use either of the event libraries.
++Extension option control from user code
+User code may set per-connection extension options now, using a new api lws_set_extension_option().
This should be called from the ESTABLISHED callback like this
If the extension is not active (missing or not negotiated for the connection, or extensions are disabled on the library) the call is just returns -1. Otherwise the connection's extension has its named option changed.
+The extension may decide to alter or disallow the change, in the example above permessage-deflate restricts the size of his rx output buffer also considering the protocol's rx_buf_size member.
++Client connections as HTTP[S] rather than WS[S]
+You may open a generic http client connection using the same struct lws_client_connect_info used to create client ws[s] connections.
+To stay in http[s], set the optional info member "method" to point to the string "GET" instead of the default NULL.
+After the server headers are processed, when payload from the server is available the callback LWS_CALLBACK_RECEIVE_CLIENT_HTTP will be made.
+You can choose whether to process the data immediately, or queue a callback when an outgoing socket is writeable to provide flow control, and process the data in the writable callback.
+Either way you use the api lws_http_client_read() to access the data, eg
Notice that if you will use SSL client connections on a vhost, you must prepare the client SSL context for the vhost after creating the vhost, since this is not normally done if the vhost was set up to listen / serve. Call the api lws_init_vhost_client_ssl() to also allow client SSL on the vhost.
++Using lws vhosts
+If you set LWS_SERVER_OPTION_EXPLICIT_VHOSTS options flag when you create your context, it won't create a default vhost using the info struct members for compatibility. Instead you can call lws_create_vhost() afterwards to attach one or more vhosts manually.
+lws_create_vhost() uses the same info struct as lws_create_context(), it ignores members related to context and uses the ones meaningful for vhost (marked with VH in libwebsockets.h).
+When you attach the vhost, if the vhost's port already has a listen socket then both vhosts share it and use SNI (is SSL in use) or the Host: header from the client to select the right one. Or if no other vhost already listening the a new listen socket is created.
+There are some new members but mainly it's stuff you used to set at context creation time.
++How lws matches hostname or SNI to a vhost
+LWS first strips any trailing :port number.
+Then it tries to find an exact name match for a vhost listening on the correct port, ie, if SNI or the Host: header provided abc.com:1234, it will match on a vhost named abc.com that is listening on port 1234.
+If there is no exact match, lws will consider wildcard matches, for example if cats.abc.com:1234 is provided by the client by SNI or Host: header, it will accept a vhost "abc.com" listening on port 1234. If there was a better, exact, match, it will have been chosen in preference to this.
+Connections with SSL will still have the client go on to check the certificate allows wildcards and error out if not.
++Using lws mounts on a vhost
+The last argument to lws_create_vhost() lets you associate a linked list of lws_http_mount structures with that vhost's URL 'namespace', in a similar way that unix lets you mount filesystems into areas of your / filesystem how you like and deal with the contents transparently.
+The last mount structure should have a NULL mount_next, otherwise it should point to the 'next' mount structure in your list.
+Both the mount structures and the strings must persist until the context is destroyed, since they are not copied but used in place.
+.origin_protocol should be one of
-
+
+Operation of LWSMPRO_CALLBACK mounts
+The feature provided by CALLBACK type mounts is binding a part of the URL namespace to a named protocol callback handler.
+This allows protocol plugins to handle areas of the URL namespace. For example in test-server-v2.0.c, the URL area "/formtest" is associated with the plugin providing "protocol-post-demo" like this
+Client access to /formtest[anything] will be passed to the callback registered with the named protocol, which in this case is provided by a protocol plugin.
+Access by all methods, eg, GET and POST are handled by the callback.
+protocol-post-demo deals with accepting and responding to the html form that is in the test server HTML.
+When a connection accesses a URL related to a CALLBACK type mount, the connection protocol is changed until the next access on the connection to a URL outside the same CALLBACK mount area. User space on the connection is arranged to be the size of the new protocol user space allocation as given in the protocol struct.
+This allocation is only deleted / replaced when the connection accesses a URL region with a different protocol (or the default protocols[0] if no CALLBACK area matches it).
++Dimming webpage when connection lost
+The lws test plugins' html provides useful feedback on the webpage about if it is still connected to the server, by greying out the page if not. You can also add this to your own html easily
+-
+
-
+
|
+
+ libwebsockets
+
+ Lightweight C library for HTML5 websockets
+ |
+
+Enabling lwsgs for build
+Enable at CMake with -DLWS_WITH_GENERIC_SESSIONS=1
+This also needs sqlite3 (libsqlite3-dev or similar package)
++lwsgs Introduction
+The generic-sessions protocol plugin provides cookie-based login authentication for lws web and ws connections.
+The plugin handles everything about generic account registration, email verification, lost password, account deletion, and other generic account management.
+Other code, in another eg, ws protocol handler, only needs very high-level state information from generic-sessions, ie, which user the client is authenticated as. Everything underneath is managed in generic-sessions.
+-
+
+Lwsgs Integration to HTML
+Only three steps are needed to integrate lwsgs in your HTML.
+1) lwsgs HTML UI is bundled with the javascript it uses in lwsgs.js, so import that script file in your head section
2) define an empty div of id "lwsgs" somewhere
+3) Call lwsgs_initial() in your page
+That's it. An example is below
++Lwsgs Overall Flow@
+When the protocol is initialized, it gets per-vhost information from the config, such as where the sqlite3 databases are to be stored. The admin username and sha-1 of the admin password are also taken from here.
+In the mounts using protocol-generic-sessions, a cookie is maintained against any requests; if no cookie was active on the initial request a new session is created with no attached user.
+So there should always be an active session after any transactions with the server.
+In the example html going to the mount /lwsgs loads a login / register page as the default.
+The <form> in the login page contains 'next url' hidden inputs that let the html 'program' where the form handler will go after a successful admin login, a successful user login and a failed login.
+After a successful login, the sqlite record at the server for the current session is updated to have the logged-in username associated with it.
++Lwsgs Configuration
+"auth-mask" defines the authorization sector bits that must be enabled on the session to gain access.
+"auth-mask" 0 is the default.
+-
+
Note that the name of the real application protocol that uses generic-sessions is used, not generic-sessions itself.
+The vhost configures the storage dir, admin credentials and session cookie lifetimes:
+The email- related settings control generation of automatic emails for registration and forgotten password.
+-
+
The real protocol that makes use of generic-sessions must also be listed and any configuration it needs given
+Notice the real application uses his own sqlite db, no details about how generic-sessions works or how it stores data are available to it.
++Lwsgs Password Confounder
+You can also define a per-vhost confounder shown in the example above, used when aggregating the password with the salt when it is hashed. Any attacker will also need to get the confounder along with the database, which you can make harder by making the config dir only eneterable / readable by root.
++Lwsgs Preparing the db directory
+You will have to prepare the db directory so it's suitable for the lwsws user to use, that usually means apache, eg
++Lwsgs Email configuration
+lwsgs will can send emails by talking to an SMTP server on localhost:25. That will usually be sendmail or postfix, you should confirm that works first by itself using the mail application to send on it.
lwsgs has been tested on stock Fedora sendmail and postfix.
++Lwsgs Integration with another protocol
+lwsgs is designed to provide sessions and accounts in a standalone and generic way.
+But it's not useful by itself, there will always be the actual application who wants to make use of generic-sessions features.
+We provide the "messageboard" plugin as an example of how to integrate with your actual application protocol.
+The basic approach is the 'real' protocol handler (usually a plugin itself) subclasses the generic-sessions plugin and calls through to it by default.
+The "real" protocol handler entirely deals with ws-related stuff itself, since generic-sessions does not use ws. But for
+-
+
the "real" protocol handler checks if it recognizes the activity (eg, his own POST form URL) and if not, passes stuff through to the generic-sessions protocol callback to handle it. To simplify matters the real protocol can just pass through any unhandled messages to generic-sessions.
+The "real" protocol can get a pointer to generic-sessions protocol on the same vhost using
+The "real" protocol must also arrange generic-sessions per_session_data in his own per-session allocation. To allow keeping generic-sessions opaque, the real protocol must allocate that space at runtime, using the pss size the generic-sessions protocol struct exposes
+The allocation reserved for generic-sessions is then used as user_space when the real protocol calls through to the generic-sessions callback
+In that way the "real" protocol can subclass generic-sessions functionality.
+To ease management of these secondary allocations, there are callbacks that occur when a wsi binds to a protocol and when the binding is dropped. These should be used to malloc and free and kind of per-connection secondary allocations.
+#section gsapsib Getting session-specific information from another protocol
+At least at the time when someone tries to upgrade an http(s) connection to ws(s) with your real protocol, it is necessary to confirm the cookie the http(s) connection has with generic-sessions and find out his username and other info.
+Generic sessions lets another protocol check it again by calling his callback, and lws itself provides a generic session info struct to pass the related data
+After the call to generic-sessions, the results can be
+-
+
the real protocol can use this to reject attempts to open ws connections from http connections that are not authenticated; afterwards there's no need to check the ws connection auth status again.
+-
+
|
+
+ libwebsockets
+
+ Lightweight C library for HTML5 websockets
+ |
+
+What is generic-table?
+Generic-table is a JSON schema and client-side JS file that makes it easy to display live, table structured HTML over a ws link.
+An example plugin and index.html using it are provided, but lwsgt itself doesn't have its own plugin, it's just a JSON schema and client-side JS that other plugins can use to simplify displaying live, table-based data without having to reinvent the wheel each time.
+The ws protocol sends JSON describing the table, and then JSON updating the table contents when it chooses, the brower table is updated automatically, live.
+
+-
+
+Enabling for build
+Enable the demo plugin at CMake with -DLWS_WITH_PLUGINS=1
++Integrating with your html
+-
+
-
+
You can skip this but the result will be less beautiful until some CSS is provided.
+-
+
lwsgt JS will put its content there.
+-
+
In the callback, you can recover the ws object by window[gt].lwsgt_ws.
+Lwsgt constructor
+To instantiate the ws link and lwsgt instance, your HTML must call a lwsgt constructor for each region on the page managed by lwsgt.
+var myvar = new lwsgt_initial(title, ws_protocol, div_id, click_cb, myvar);
All of the arguments are strings.
+| Parameter | Description |
|---|---|
| title | Title string to go above the table |
| ws_protocol | Protocol name string to use when making ws connection |
| div_id | HTML id of div to fill with content |
| click_cb | Callback function name string to handle clickable links |
| myvar | Name of var used to hold this instantiation globally |
Note "myvar" is needed so it can be passed to the click handling callback.
++Lwsgt click handling function
+When a clickable link produced by lwsgt is clicked, the function named in the click_cb parameter to lwsgt_initial is called.
+That function is expected to take four parameters, eg
+function lwsgt_dir_click(gt, u, col, row)
| Parameter | Description |
|---|---|
| gt | Name of global var holding this lwsgt context (ie, myvar) |
| u | Link "url" string |
| col | Table column number link is from |
| row | Table row number link is from |
+Generic-table JSON
+Column layout
+When the ws connection is established, the protocol should send a JSON message describing the table columns. For example
+-
+
Breadcrumbs
+When a view is hierarchical, it's useful to provide a "path" with links back in the "path", known as "breadcrumbs".
+Elements before the last one should provide a "url" member as well as the displayable name, which is used to create the link destination.
+The last element, being the current displayed page should not have a url member and be displayed without link style.
+Table data
+The actual file data consists of an array of rows, containing the columns mentioned in the original "cols" section.
++Setting up protocol-lws-table-dirlisting
+The example protocol needs two mounts, one to provide the index.html, js and the protocol itself
+The protocol wants a per-mount option (PMO) to tell it the base directory it is serving from, named "dir".
+The other mount is there to simply serve items that get clicked on from the table in a secure way
+This last bit is not related to using lwsgt itself.
+-
+
|
+
+ libwebsockets
+
+ Lightweight C library for HTML5 websockets
+ |
+
+Libwebsockets Web Server
+lwsws is an implementation of a very lightweight, ws-capable generic web server, which uses libwebsockets to implement everything underneath.
+If you are basically implementing a standalone server with lws, you can avoid reinventing the wheel and use a debugged server including lws.
++Build
+Just enable -DLWS_WITH_LWSWS=1 at cmake-time.
+It enables libuv and plugin support automatically.
+NOTICE on Ubuntu, the default libuv package is called "libuv-0.10". This is ancient.
+You should replace this with libuv1 and libuv1-dev before proceeding.
++Lwsws Configuration
+lwsws uses JSON config files, they're pure JSON except:
+-
+
There is a single file intended for global settings
+/etc/lwsws/conf
and a config directory intended to take one file per vhost
+/etc/lwsws/conf.d/warmcat.com
To get started quickly, an example config reproducing the old test server on port 7681, non-SSL is provided. To set it up
+Other Global Options
+-
+
+Lwsws Vhosts
+One server can run many vhosts, where SSL is in use SNI is used to match the connection to a vhost and its vhost-specific SSL keys during SSL negotiation.
+Listing multiple vhosts looks something like this
That sets up three vhosts all called "localhost" on ports 443 and 7681 with SSL, and port 80 without SSL but with a forced redirect to https://localhost
++Lwsws Vhost name and port sharing
+The vhost name field is used to match on incoming SNI or Host: header, so it must always be the host name used to reach the vhost externally.
+-
+
+Lwsws Protocols
+Vhosts by default have available the union of any initial protocols from context creation time, and any protocols exposed by plugins.
+Vhosts can select which plugins they want to offer and give them per-vhost settings using this syntax
The "x":"y" parameters like "status":"ok" are made available to the protocol during its per-vhost LWS_CALLBACK_PROTOCOL_INIT ( is a pointer to a linked list of struct lws_protocol_vhost_options containing the name and value pointers).
+To indicate that a protocol should be used when no Protocol: header is sent by the client, you can use "default": "1"
+Lwsws Other vhost options
+-
+
Each vhost may have its own certs, SNI is used during the initial connection negotiation to figure out which certs to use by the server name it's asking for from the request DNS name.
+-
+
If you need to allow weaker ciphers,you can provide an alternative list here per-vhost.
+-
+
The values are derived from /usr/include/openssl/ssl.h
would equate to
+-
+
allows you to set arbitrary headers on every file served by the vhost
+recommended vhost headers for good client security are
++Lwsws Mounts
+Where mounts are given in the vhost definition, then directory contents may be auto-served if it matches the mountpoint.
+Mount protocols are used to control what kind of translation happens
+-
+
Eg, with this mountpoint
The uri /file.jpg would serve /var/www/mysite.com/file.jpg, since / matched.
+-
+
+Lwsws Other mount options
+1) Some protocols may want "per-mount options" in name:value format. You can provide them using "pmo"
{
+ "mountpoint": "/stuff",
+ "origin": "callback://myprotocol",
+ "pmo": [{
+ "myname": "myvalue"
+ }]
+ }
+2) When using a cgi:// protcol origin at a mountpoint, you may also give cgi environment variables specific to the mountpoint like this
This allows you to customize one cgi depending on the mountpoint (and / or vhost).
+3) It's also possible to set the cgi timeout (in secs) per cgi:// mount, like this
4) callback:// protocol may be used when defining a mount to associate a named protocol callback with the URL namespace area. For example
All handling of client access to /formtest[anything] will be passed to the callback registered to the protocol "protocol-post-demo".
+This is useful for handling POST http body content or general non-cgi http payload generation inside a plugin.
+See the related notes in README.coding.md
+5) Cache policy of the files in the mount can also be set. If no options are given, the content is marked uncacheable.
6) You can also define a list of additional mimetypes per-mount
Normally a file suffix MUST match one of the canned mimetypes or one of the extra mimetypes, or the file is not served. This adds a little bit of security because even if there is a bug somewhere and the mount dirs are circumvented, lws will not serve, eg, /etc/passwd.
+If you provide an extra mimetype entry
"*": "" +
Then any file is served, if the mimetype was not known then it is served without a Content-Type: header.
+7) A mount can be protected by HTTP Basic Auth. This only makes sense when using https, since otherwise the password can be sniffed.
+You can add a basic-auth entry on a mount like this`
Before serving anything, lws will signal to the browser that a username / password combination is required, and it will pop up a dialog. When the user has filled it in, lwsws checks the user:password string against the text file named in the basic-auth entry.
The file should contain user:pass one per line
+The file should be readable by lwsws, and for a little bit of extra security not have a file suffix, so lws would reject to serve it even if it could find it on a mount.
++Lwsws Plugins
+Protcols and extensions may also be provided from "plugins", these are lightweight dynamic libraries. They are scanned for at init time, and any protocols and extensions found are added to the list given at context creation time.
+Protocols receive init (LWS_CALLBACK_PROTOCOL_INIT) and destruction (LWS_CALLBACK_PROTOCOL_DESTROY) callbacks per-vhost, and there are arrangements they can make per-vhost allocations and get hold of the correct pointer from the wsi at the callback.
+This allows a protocol to choose to strictly segregate data on a per-vhost basis, and also allows the plugin to handle its own initialization and context storage.
+To help that happen conveniently, there are some new apis
+-
+
dumb increment, mirror and status protocol plugins are provided as examples.
++Additional plugin search paths
+Packages that have their own lws plugins can install them in their own preferred dir and ask lwsws to scan there by using a config fragment like this, in its own conf.d/ file managed by the other package
+lws-server-status plugin
+One provided protocol can be used to monitor the server status.
+Enable the protocol like this on a vhost's ws-protocols section
"update-ms" is used to control how often updated JSON is sent on a ws link.
+And map the provided HTML into the vhost in the mounts section
You might choose to put it on its own vhost which has "interface": "lo", so it's not externally visible.
++Lwsws Integration with Systemd
+lwsws needs a service file like this as /usr/lib/systemd/system/lwsws.service
You can find this prepared in ./lwsws/usr-lib-systemd-system-lwsws.service
+Lwsws Integration with logrotate
+For correct operation with logrotate, /etc/logrotate.d/lwsws (if that's where we're putting the logs) should contain
You can find this prepared in /lwsws/etc-logrotate.d-lwsws
Prepare the log directory like this
+-
+
|
+
+ libwebsockets
+
+ Lightweight C library for HTML5 websockets
+ |
+
Library is a component
+As a library, lws is always just a component in a bigger application.
+When users have a problem involving lws, what is happening in the bigger application is usually critical to understand what is going on (and where the solution lies).
+Many users are able to share their sources, but others decide not to, for presumed "commercial advantage" or whatever. (In any event, it can be painful looking through large chunks of someone else's sources for problems when that is not the library author's responsibility.)
+This makes answering questions like "what is wrong with my code I am not +going to show you?" or even "what is wrong with my code?" very difficult.
+Even if it's clear there is a problem somewhere, it cannot be understood or reproduced by anyone else if it needs user code that isn't provided.
+The biggest question is, "is this an lws problem actually"?
+Use the test apps as sanity checks
+The test server and client are extremely useful for sanity checks and debugging guidance.
+-
+
-
+
|
+
+ libwebsockets
+
+ Lightweight C library for HTML5 websockets
+ |
+
Are you building a client? You just need to look at the test client 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 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.
+$ cmake .. -DLWS_WITH_PLUGINS=1
+ +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
++Testing server with a browser
+If you run libwebsockets-test-server and point your browser (eg, Chrome) to
http://127.0.0.1:7681 +
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.
+Running test server as a Daemon
+You can use the -D option on the test server to have it fork into the background and return immediately. In this daemonized mode all stderr is disabled and logging goes only to syslog, eg, /var/log/messages or similar.
The server maintains a lockfile at /tmp/.lwsts-lock that contains the pid of the master process, and deletes this file when the master process terminates.
To stop the daemon, do
If it finds a stale lock (the pid mentioned in the file does not exist any more) it will delete the lock and create a new one during startup.
+If the lock is valid, the daemon will exit with a note on stderr that it was already running.
++Using SSL on the server side
+To test it using SSL/WSS, just run the test server with
and use the URL
The connection will be entirely encrypted using some generated certificates that your browser will not accept, since they are not signed by any real Certificate Authority. Just accept the certificates in the browser and the connection will proceed in first https and then websocket wss, acting exactly the same.
+test-server.c is all that is needed to use libwebsockets for serving both the script html over http and websockets.
++Testing websocket client support
+If you run the test server as described above, you can also connect to it using the test client as well as a browser.
+will by default connect to the test server on localhost:7681 and print the dumb increment number from the server at the same time as drawing random circles in the mirror protocol; if you connect to the test server using a browser at the same time you will be able to see the circles being drawn.
+The test client supports SSL too, use
+the -s tells it to accept the default self-signed cert from the server, otherwise it will strictly fail the connection if there is no CA cert to validate the server's certificate.
++Choosing between test server variations
+If you will be doing standalone serving with lws, ideally you should avoid making your own server at all, and use lwsws with your own protocol plugins.
+The second best option is follow test-server-v2.0.c, which uses a mount to autoserve a directory, and lws protocol plugins for ws, without needing any user callback code (other than what's needed in the protocol plugin).
+For those two options libuv is needed to support the protocol plugins, if that's not possible then the other variations with their own protocol code should be considered.
++Testing simple echo
+You can test against echo.websockets.org as a sanity test like this (the client connects to port 80 by default):
This echo test is of limited use though because it doesn't negotiate any protocol. You can run the same test app as a local server, by default on localhost:7681
and do the echo test against the local echo server
If you add the --ssl switch to both the client and server, you can also test with an encrypted link.
+Testing SSL on the client side
+To test SSL/WSS client action, just run the client test with
By default the client test applet is set to accept self-signed certificates used by the test server, this is indicated by the use_ssl var being set to 2. Set it to 1 to reject any server certificate that it doesn't have a trusted CA cert for.
+Using the websocket ping utility
+libwebsockets-test-ping connects as a client to a remote websocket server and pings it like the normal unix ping utility.
By default it sends 64 byte payload packets using the 04 PING packet opcode type. You can change the payload size using the -s= flag, up to a maximum of 125 mandated by the 04 standard.
Using the lws-mirror protocol that is provided by the test server, libwebsockets-test-ping can also use larger payload sizes up to 4096 is BINARY packets; lws-mirror will copy them back to the client and they appear as a PONG. Use the -m flag to select this operation.
The default interval between pings is 1s, you can use the -i= flag to set this, including fractions like -i=0.01 for 10ms interval.
Before you can even use the PING opcode that is part of the standard, you must complete a handshake with a specified protocol. By default lws-mirror-protocol is used which is supported by the test server. But if you are using it on another server, you can specify the protocol to handshake with by --protocol=protocolname
+fraggle Fraggle test app
+By default it runs in server mode
You need to run a second session in client mode, you have to give the -c switch and the server address at least:
The fraggle test sends a random number up to 1024 fragmented websocket frames each of a random size between 1 and 2001 bytes in a single message, then sends a checksum and starts sending a new randomly sized and fragmented message.
+The fraggle test client receives the same message fragments and computes the same checksum using websocket framing to see when the message has ended. It then accepts the server checksum message and compares that to its checksum.
++proxy support
+The http_proxy environment variable is respected by the client connection code for both ws:// and wss://. It doesn't support authentication.
You use it like this
+debug logging
+By default logging of severity "notice", "warn" or "err" is enabled to stderr.
+Again by default other logging is compiled in but disabled from printing.
+By default debug logs below "notice" in severity are not compiled in. To get them included, add this option in CMAKE
+If you want to see more detailed debug logs, you can control a bitfield to select which logs types may print using the lws_set_log_level() api, in the test apps you can use -d <number> to control this. The types of logging available are (OR together the numbers to select multiple)
-
+
+Websocket version supported
+The final IETF standard is supported for both client and server, protocol version 13.
++Latency Tracking
+Since libwebsockets runs using poll() and a single threaded approach, any unexpected latency coming from system calls would be bad news. There's now a latency tracking scheme that can be built in with --with-latency at configure-time, logging the time taken for system calls to complete and if the whole action did complete that time or was deferred.
You can see the detailed data by enabling logging level 512 (eg, -d 519 on the test server to see that and the usual logs), however even without that the "worst" latency is kept and reported to the logs with NOTICE severity when the context is destroyed.
Some care is needed interpreting them, if the action completed the first figure (in us) is the time taken for the whole action, which may have retried through the poll loop many times and will depend on network roundtrip times. High figures here don't indicate a problem. The figure in us reported after "lat" in the logging is the time taken by this particular attempt. High figures here may indicate a problem, or if you system is loaded with another app at that time, such as the browser, it may simply indicate the OS gave preferential treatment to the other app during that call.
++Autobahn Test Suite
+Lws can be tested against the autobahn websocket fuzzer.
+1) pip install autobahntestsuite
+2) wstest -m fuzzingserver
+3) Run tests like this
+libwebsockets-test-echo –client localhost –port 9001 -u "/runCase?case=20&agent=libwebsockets" -v -d 65535 -n 1
+(this runs test 20)
+4) In a browser, go here
+http://localhost:8080/test_browser.html
+fill in "libwebsockets" in "User Agent Identifier" and press "Update Reports (Manual)"
+5) In a browser go to the directory you ran wstest in (eg, /projects/libwebsockets)
+file:///projects/libwebsockets/reports/clients/index.html
+to see the results
++Autobahn Test Notes
+1) Autobahn tests the user code + lws implementation. So to get the same results, you need to follow test-echo.c in terms of user implementation.
+2) Two of the tests make no sense for Libwebsockets to support and we fail them.
+-
+
-
+
- ';
+ for (var i in data.children) {
+ result+='
bits set here must be set for authorized client session
+§ basic_auth_login_file
+ +| const char* lws_http_mount::basic_auth_login_file | +
NULL, or filepath to use to check basic auth logins against
+