{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"", "gen_ut":1752643541, "reponame":"libwebsockets", "desc":"libwebsockets lightweight C networking library", "owner": { "name": "Andy Green", "email": "andy@warmcat.com", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" },"url":"https://libwebsockets.org/repo/libwebsockets", "f":3, "items": [ {"schema":"libjg2-1", "cid":"3dee6ec94dedd0f5797f5f37648ff761", "commit": {"type":"commit", "time": 1751702063, "time_ofs": 60, "oid_tree": { "oid": "8023528dca85bb087f536c552e3b83a4205698d1", "alias": []}, "oid":{ "oid": "10a159b9c8215b95922b88c69a1e4cc68a5b425b", "alias": []}, "msg": "lwsws: update README", "sig_commit": { "git_time": { "time": 1751702063, "offset": 60 }, "name": "Andy Green", "email": "andy@warmcat.com", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" }, "sig_author": { "git_time": { "time": 1751610382, "offset": 60 }, "name": "Andy Green", "email": "andy@warmcat.com", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" }}, "body": "lwsws: update README\n" , "diff": "diff --git a/READMEs/README.lwsws.md b/READMEs/README.lwsws.md\nindex d2006b3..434266c 100644\n--- a/READMEs/README.lwsws.md\n+++ b/READMEs/README.lwsws.md\n@@ -1,26 +1,24 @@\n Notes about lwsws\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n \n-@section lwsws Libwebsockets Web Server\n+## Libwebsockets Web Server\n \n lwsws is an implementation of a very lightweight, ws-capable generic web\n server, which uses libwebsockets to implement everything underneath.\n \n If you are basically implementing a standalone server with lws, you can avoid\n-reinventing the wheel and use a debugged server including lws.\n+reinventing the wheel and use a debugged server including lws, managed\n+mainly by JSON. You can offer most things using the mounts in JSON, but for\n+custom services like ws protocols, you do this in code and then tell lwsws\n+to offer the protocol on the vhost(s) desired. \n \n-\n-@section lwswsb Build\n+## Build\n \n Just enable -DLWS_WITH_LWSWS\u003d1 at cmake-time.\n \n It enables libuv and plugin support automatically.\n \n-NOTICE on Ubuntu, the default libuv package is called \u0022libuv-0.10\u0022. This is ancient.\n-\n-You should replace this with libuv1 and libuv1-dev before proceeding.\n-\n-@section lwswsc Lwsws Configuration\n+## Lwsws Configuration\n \n lwsws uses JSON config files, they're pure JSON except:\n \n@@ -79,13 +77,13 @@ on port 7681, non-SSL is provided. To set it up\n \t# sudo lwsws\n ```\n \n-@section lwswsacme Using Letsencrypt or other ACME providers\n+## Using Letsencrypt or other ACME providers\n \n Lws supports automatic provisioning and renewal of TLS certificates.\n \n See ./READMEs/README.plugin-acme.md for examples of how to set it up on an lwsws vhost.\n \n-@section lwsogo Other Global Options\n+## Other Global Options\n \n - `reject-service-keywords` allows you to return an HTTP error code and message of your choice\n if a keyword is found in the user agent\n@@ -99,7 +97,7 @@ if a keyword is found in the user agent\n - `timeout-secs` lets you set the global timeout for various network-related\n operations in lws, in seconds. It defaults to 5.\n \n-@section lwswsv Lwsws Vhosts\n+## Lwsws Vhosts\n \n One server can run many vhosts, where SSL is in use SNI is used to match\n the connection to a vhost and its vhost-specific SSL keys during SSL\n@@ -159,7 +157,7 @@ Listing multiple vhosts looks something like this\n That sets up three vhosts all called \u0022localhost\u0022 on ports 443 and 7681 with SSL, and port 80 without SSL but with a forced redirect to https://localhost\n \n \n-@section lwswsvn Lwsws Vhost name and port sharing\n+## Vhost name and port sharing\n \n The vhost name field is used to match on incoming SNI or Host: header, so it\n must always be the host name used to reach the vhost externally.\n@@ -173,7 +171,7 @@ negotiation time (via SNI) or if no SSL, then after the Host: header from\n the client has been parsed.\n \n \n-@section lwswspr Lwsws Protocols\n+## Lwsws Protocols\n \n Vhosts by default have available the union of any initial protocols from context creation time, and\n any protocols exposed by plugins.\n@@ -215,7 +213,7 @@ to be selected using \u0022raw\u0022: \u00221\u0022\n \n See also \u0022apply-listen-accept\u0022 below.\n \n-@section lwswsovo Lwsws Other vhost options\n+## Lwsws Other vhost options\n \n - If the three options `host-ssl-cert`, `host-ssl-ca` and `host-ssl-key` are given, then the vhost supports SSL.\n \n@@ -287,7 +285,7 @@ recommended vhost headers for good client security are\n \n - \u0022`apply-listen-accept`\u0022: \u0022on\u0022 This vhost only serves a non-http protocol, specified in \u0022listen-accept-role\u0022 and \u0022listen-accept-protocol\u0022\n \n-@section lwswsm Lwsws Mounts\n+# Lwsws Mounts\n \n Where mounts are given in the vhost definition, then directory contents may\n be auto-served if it matches the mountpoint.\n@@ -338,7 +336,7 @@ This will cause your local url `/proxytest` to serve content fetched from libweb\n In addition link and src urls in the document are rewritten so / or the origin url part are rewritten to the mountpoint part.\n \n \n-@section lwswsomo Lwsws Other mount options\n+## Lwsws Other mount options\n \n 1) Some protocols may want \u0022per-mount options\u0022 in name:value format. You can\n provide them using \u0022pmo\u0022\n@@ -455,7 +453,7 @@ Auth before the ws upgrade, this is also possible. In this case, the\n \u0022basic-auth\u0022: and filepath to the credentials file is passed as a pvo in the\n \u0022ws-protocols\u0022 section of the vhost definition.\n \n-@section lwswscc Requiring a Client Cert on a vhost\n+## Requiring a Client Cert on a vhost\n \n You can make a vhost insist to get a client certificate from the peer before\n allowing the connection with\n@@ -467,7 +465,7 @@ allowing the connection with\n the connection will only proceed if the client certificate was signed by the\n same CA as the server has been told to trust.\n \n-@section rawconf Configuring Fallback and Raw vhosts\n+## Configuring Fallback and Raw vhosts\n \n Lws supports some unusual modes for vhost listen sockets, which may be\n configured entirely using the JSON per-vhost config language in the related\n@@ -518,7 +516,7 @@ protocol \u0022myprotocol\u0022.\n \t\u0022allow-http-on-https\u0022:\t\t\u00221\u0022,\n ```\n \n-@section lwswspl Lwsws Plugins\n+## Lwsws Plugins\n \n Protcols and extensions may also be provided from \u0022plugins\u0022, these are\n lightweight dynamic libraries. They are scanned for at init time, and\n@@ -545,7 +543,7 @@ To help that happen conveniently, there are some new apis\n dumb increment, mirror and status protocol plugins are provided as examples.\n \n \n-@section lwswsplaplp Additional plugin search paths\n+## Additional plugin search paths\n \n Packages that have their own lws plugins can install them in their own\n preferred dir and ask lwsws to scan there by using a config fragment\n@@ -558,7 +556,7 @@ like this, in its own conf.d/ file managed by the other package\n \t}\n ```\n \n-@section lwswsssp lws-server-status plugin\n+## lws-server-status plugin\n \n One provided protocol can be used to monitor the server status.\n \n@@ -594,7 +592,7 @@ Linux systems by giving an appropriate path down /sys.\n This may be given multiple times.\n \n \n-@section lwswsreload Lwsws Configuration Reload\n+## Lwsws Configuration Reload\n \n You may send lwsws a `HUP` signal, by, eg\n \n@@ -637,7 +635,7 @@ etc, and lwsws or lws may also have been updated arbitrarily.\n respond to SIGHUP or SIGTERM. Actual serving and network listening etc happens\n in child processes which use the privileges set in the lwsws config files.\n \n-@section lwswssysd Lwsws Integration with Systemd\n+## Lwsws Integration with Systemd\n \n lwsws needs a service file like this as `/usr/lib/systemd/system/lwsws.service`\n ```\n@@ -657,7 +655,7 @@ WantedBy\u003dmulti-user.target\n You can find this prepared in `./lwsws/usr-lib-systemd-system-lwsws.service`\n \n \n-@section lwswslr Lwsws Integration with logrotate\n+## Lwsws Integration with logrotate\n \n For correct operation with logrotate, `/etc/logrotate.d/lwsws` (if that's\n where we're putting the logs) should contain\n@@ -678,7 +676,7 @@ Prepare the log directory like this\n \tsudo chmod 700 /var/log/lwsws\n ```\n \n-@section lwswsgdb Debugging lwsws with gdb\n+## Debugging lwsws with gdb\n \n Hopefully you won't need to debug lwsws itself, but you may want to debug your plugins. start lwsws like this to have everything running under gdb\n \n@@ -689,7 +687,7 @@ sudo gdb -ex \u0022set follow-fork-mode child\u0022 -ex \u0022run\u0022 --args /usr/local/bin/lwsws\n \n this will give nice backtraces in lwsws itself and in plugins, if they were built with symbols.\n \n-@section lwswsvgd Running lwsws under valgrind\n+## Running lwsws under valgrind\n \n You can just run lwsws under valgrind as usual and get valid results. However the results / analysis part of valgrind runs\n after the plugins have removed themselves, this means valgrind backtraces into plugin code is opaque, without\n","s":{"c":1752643541,"u": 3068}} ],"g": 4511,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 0, "si": 0, "db":0, "di":0, "sat":0, "lfc": "0000"}