diff --git a/CMakeLists.txt b/CMakeLists.txt index 1c5a0bb42..356b4092d 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -401,6 +401,8 @@ SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/bin") SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/lib") SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/lib") +SET(LWS_INSTALL_PATH "${CMAKE_INSTALL_PREFIX}") + # Put absolute path of dynamic libraries into the object code. Some # architectures, notably Mac OS X, need this. SET(CMAKE_INSTALL_NAME_DIR "${CMAKE_INSTALL_PREFIX}/${LWS_INSTALL_LIB_DIR}${LIB_SUFFIX}") diff --git a/README.lwsws.md b/README.lwsws.md index 244aeeac0..a8722b0a2 100644 --- a/README.lwsws.md +++ b/README.lwsws.md @@ -20,6 +20,11 @@ Configuration lwsws uses JSON config files, they're pure JSON but # 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. + There is a single file intended for global settings /etc/lwsws/conf diff --git a/doc/html/md_README.generic-table.html b/doc/html/md_README.generic-table.html deleted file mode 100644 index cae3cbaa6..000000000 --- a/doc/html/md_README.generic-table.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - -libwebsockets: Notes about generic-table - - - - - - - - - - - -
-
- - - - - - - -
-
libwebsockets -
-
Lightweight C library for HTML5 websockets
-
-
- - - -
-
- -
-
-
- -
-
-
-
Notes about generic-table
-
-
-

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.

-

Enabling for build

-

Enable at CMake with -DLWS_WITH_PLUGINS=1

-

Generic-table JSON

-

Column layout

-

When the ws connection is established, the protocol should send a JSON message describing the table columns. For example

-
1 msg = "{\"cols\":["
2  " {\"name\": \"Date\"},"
3  " {\"name\": \"Size\", \"align\": \"right\"},"
4  " {\"name\": \"Icon\"},"
5  " {\"name\": \"Name\", \"href\": \"uri\"},"
6  " {\"name\": \"uri\", \"hide\": \"1\" }"
7  " ]"
8  "}";
    -
  • 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
  • -
-

Table data

-

The

-
-
- - - - diff --git a/doc/html/md_README.lwsws.html b/doc/html/md_README.lwsws.html index 10ea75b69..85f779c1d 100644 --- a/doc/html/md_README.lwsws.html +++ b/doc/html/md_README.lwsws.html @@ -72,6 +72,7 @@ $(document).ready(function(){initNavTree('md_README.lwsws.html','');});

It enables libuv and plugin support automatically.

Configuration

lwsws uses JSON config files, they're pure JSON but # 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.

There is a single file intended for global settings

/etc/lwsws/conf

1 # these are the server global settings
2 # stuff related to vhosts should go in one
3 # file per vhost in ../conf.d/
4 
5 {
6  "global": {
7  "uid": "48", # apache user
8  "gid": "48", # apache user
9  "count-threads": "1",
10  "server-string": "myserver v1", # returned in http headers
11  "init-ssl": "yes"
12  }
13 }

and a config directory intended to take one file per vhost

/etc/lwsws/conf.d/warmcat.com

1 {
2  "vhosts": [{
3  "name": "warmcat.com",
4  "port": "443",
5  "interface": "eth0", # optional
6  "host-ssl-key": "/etc/pki/tls/private/warmcat.com.key", # if given enable ssl
7  "host-ssl-cert": "/etc/pki/tls/certs/warmcat.com.crt",
8  "host-ssl-ca": "/etc/pki/tls/certs/warmcat.com.cer",
9  "mounts": [{ # autoserve
10  "mountpoint": "/",
11  "origin": "file:///var/www/warmcat.com",
12  "default": "index.html"
13  }]
14  }]
15 }

To get started quickly, an example config reproducing the old test server on port 7681, non-SSL is provided. To set it up

1 # mkdir -p /etc/lwsws/conf.d /var/log/lwsws
2 # cp ./lwsws/etc-lwsws-conf-EXAMPLE /etc/lwsws/conf
3 # cp ./lwsws/etc-lwsws-conf.d-localhost-EXAMPLE /etc/lwsws/conf.d/test-server
4 # sudo lwsws

Vhosts

@@ -123,11 +124,18 @@ $(document).ready(function(){initNavTree('md_README.lwsws.html','');});
  • cgi:// this causes any matching url to be given to the named cgi, eg
    1 {
    2  "mountpoint": "/git",
    3  "origin": "cgi:///var/www/cgi-bin/cgit",
    4  "default": "/"
    5 }, {
    6  "mountpoint": "/cgit-data",
    7  "origin": "file:///usr/share/cgit",
    8  "default": "/"
    9 },
    would cause the url /git/myrepo to pass "myrepo" to the cgi /var/www/cgi-bin/cgit and send the results to the client.
  • Other mount options

    -

    1) When using a cgi:// protcol origin at a mountpoint, you may also give cgi environment variables specific to the mountpoint like this

    1 {
    2  "mountpoint": "/git",
    3  "origin": "cgi:///var/www/cgi-bin/cgit",
    4  "default": "/",
    5  "cgi-env": [{
    6  "CGIT_CONFIG": "/etc/cgitrc/libwebsockets.org"
    7  }]
    8 }

    This allows you to customize one cgi depending on the mountpoint (and / or vhost).

    -

    2) It's also possible to set the cgi timeout (in secs) per cgi:// mount, like this

    1 "cgi-timeout": "30"

    3) callback:// protocol may be used when defining a mount to associate a named protocol callback with the URL namespace area. For example

    1 {
    2  "mountpoint": "/formtest",
    3  "origin": "callback://protocol-post-demo"
    4 }

    All handling of client access to /formtest[anything] will be passed to the callback registered to the protocol "protocol-post-demo".

    +

    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

    1 {
    2  "mountpoint": "/git",
    3  "origin": "cgi:///var/www/cgi-bin/cgit",
    4  "default": "/",
    5  "cgi-env": [{
    6  "CGIT_CONFIG": "/etc/cgitrc/libwebsockets.org"
    7  }]
    8 }

    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

    1 "cgi-timeout": "30"

    4) callback:// protocol may be used when defining a mount to associate a named protocol callback with the URL namespace area. For example

    1 {
    2  "mountpoint": "/formtest",
    3  "origin": "callback://protocol-post-demo"
    4 }

    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

    -

    4) Cache policy of the files in the mount can also be set. If no options are given, the content is marked uncacheable.

    1 {
    2  "mountpoint": "/",
    3  "origin": "file:///var/www/mysite.com",
    4  "cache-max-age": "60", # seconds
    5  "cache-reuse": "1", # allow reuse at client at all
    6  "cache-revalidate": "1", # check it with server each time
    7  "cache-intermediaries": "1" # allow intermediary caches to hold
    8 }

    4) You can also define a list of additional mimetypes per-mount

    1 "extra-mimetypes": {
    2  ".zip": "application/zip",
    3  ".doc": "text/evil"
    4  }

    Plugins

    +

    5) Cache policy of the files in the mount can also be set. If no options are given, the content is marked uncacheable.

    1 {
    2  "mountpoint": "/",
    3  "origin": "file:///var/www/mysite.com",
    4  "cache-max-age": "60", # seconds
    5  "cache-reuse": "1", # allow reuse at client at all
    6  "cache-revalidate": "1", # check it with server each time
    7  "cache-intermediaries": "1" # allow intermediary caches to hold
    8 }

    6) You can also define a list of additional mimetypes per-mount

    1 "extra-mimetypes": {
    2  ".zip": "application/zip",
    3  ".doc": "text/evil"
    4  }

    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.

    diff --git a/doc/latex/md_README.lwsws.tex b/doc/latex/md_README.lwsws.tex index c3992ff4b..afe0aeda3 100644 --- a/doc/latex/md_README.lwsws.tex +++ b/doc/latex/md_README.lwsws.tex @@ -12,6 +12,8 @@ It enables libuv and plugin support automatically. lwsws uses J\+S\+ON config files, they\textquotesingle{}re pure J\+S\+ON but \# may be used to turn the rest of the line into a comment. +There\textquotesingle{}s also a single substitution, if a string contains \char`\"{}\+\_\+lws\+\_\+ddir\+\_\+\char`\"{}, then that is replaced with the L\+WS install data directory path, eg, \char`\"{}/usr/share\char`\"{} or whatever was set when L\+WS was built + installed. That lets you refer to installed paths without having to change the config if your install path was different. + There is a single file intended for global settings /etc/lwsws/conf @@ -240,7 +242,17 @@ Eg, with this mountpoint \subsection*{Other mount options } -1) When using a cgi\+:// protcol origin at a mountpoint, you may also give cgi environment variables specific to the mountpoint like this +1) Some protocols may want \char`\"{}per-\/mount options\char`\"{} in name\+:value format. You can provide them using \char`\"{}pmo\char`\"{} \begin{DoxyVerb} { + "mountpoint": "/stuff", + "origin": "callback://myprotocol", + "pmo": [{ + "myname": "myvalue" + }] + } +\end{DoxyVerb} + + +2) When using a cgi\+:// protcol origin at a mountpoint, you may also give cgi environment variables specific to the mountpoint like this \begin{DoxyCode} 1 \{ 2 "mountpoint": "/git", @@ -253,11 +265,11 @@ Eg, with this mountpoint \end{DoxyCode} This allows you to customize one cgi depending on the mountpoint (and / or vhost). -2) It\textquotesingle{}s also possible to set the cgi timeout (in secs) per cgi\+:// mount, like this +3) It\textquotesingle{}s also possible to set the cgi timeout (in secs) per cgi\+:// mount, like this \begin{DoxyCode} 1 "cgi-timeout": "30" \end{DoxyCode} - 3) {\ttfamily callback\+://} protocol may be used when defining a mount to associate a named protocol callback with the U\+RL namespace area. For example + 4) {\ttfamily callback\+://} protocol may be used when defining a mount to associate a named protocol callback with the U\+RL namespace area. For example \begin{DoxyCode} 1 \{ 2 "mountpoint": "/formtest", @@ -270,7 +282,7 @@ This is useful for handling P\+O\+ST http body content or general non-\/cgi http See the related notes in R\+E\+A\+D\+M\+E.\+coding.\+md -4) Cache policy of the files in the mount can also be set. If no options are given, the content is marked uncacheable. +5) Cache policy of the files in the mount can also be set. If no options are given, the content is marked uncacheable. \begin{DoxyCode} 1 \{ 2 "mountpoint": "/", @@ -283,7 +295,7 @@ See the related notes in R\+E\+A\+D\+M\+E.\+coding.\+md \end{DoxyCode} -4) You can also define a list of additional mimetypes per-\/mount +6) You can also define a list of additional mimetypes per-\/mount \begin{DoxyCode} 1 "extra-mimetypes": \{ 2 ".zip": "application/zip", diff --git a/lib/lejp-conf.c b/lib/lejp-conf.c index 81c85b100..4637aa9d3 100644 --- a/lib/lejp-conf.c +++ b/lib/lejp-conf.c @@ -27,6 +27,8 @@ #include #endif +#define ESC_INSTALL_DATADIR "_lws_ddir_" + static const char * const paths_global[] = { "global.uid", "global.gid", @@ -246,6 +248,7 @@ lejp_vhosts_cb(struct lejp_ctx *ctx, char reason) struct jpargs *a = (struct jpargs *)ctx->user; struct lws_protocol_vhost_options *pvo, *mp_cgienv; struct lws_http_mount *m; + char *p, *p1; int n; #if 0 @@ -309,8 +312,7 @@ lejp_vhosts_cb(struct lejp_ctx *ctx, char reason) a->p += n; a->pvo->value = a->p; a->pvo->options = NULL; - a->p += snprintf(a->p, a->end - a->p, "%s", ctx->buf); - *(a->p)++ = '\0'; + goto dostring; } if (reason == LEJPCB_OBJECT_END && @@ -484,13 +486,10 @@ lejp_vhosts_cb(struct lejp_ctx *ctx, char reason) a->p += n; mp_cgienv->value = a->p; mp_cgienv->options = NULL; - a->p += snprintf(a->p, a->end - a->p, "%s", ctx->buf); - *(a->p)++ = '\0'; - lwsl_notice(" adding pmo / cgi-env '%s' = '%s'\n", mp_cgienv->name, mp_cgienv->value); + goto dostring; - break; case LEJPVP_PROTOCOL_NAME_OPT: /* this catches, eg, * vhosts[].ws-protocols[].xxx-protocol.yyy-option @@ -570,7 +569,20 @@ lejp_vhosts_cb(struct lejp_ctx *ctx, char reason) return 0; } - a->p += snprintf(a->p, a->end - a->p, "%s", ctx->buf); +dostring: + p = ctx->buf; + p1 = strstr(p, ESC_INSTALL_DATADIR); + if (p1) { + n = p1 - p; + if (n > a->end - a->p) + n = a->end - a->p; + strncpy(a->p, p, n); + a->p += n; + a->p += snprintf(a->p, a->end - a->p, "%s", LWS_INSTALL_DATADIR); + p += n + strlen(ESC_INSTALL_DATADIR); + } + + a->p += snprintf(a->p, a->end - a->p, "%s", p); *(a->p)++ = '\0'; return 0; diff --git a/lws_config.h.in b/lws_config.h.in index 0e929b900..42a77c60e 100644 --- a/lws_config.h.in +++ b/lws_config.h.in @@ -6,6 +6,8 @@ #endif #endif +#define LWS_INSTALL_DATADIR "${CMAKE_INSTALL_PREFIX}/share" + /* Define to 1 to use wolfSSL/CyaSSL as a replacement for OpenSSL. * LWS_OPENSSL_SUPPORT needs to be set also for this to work. */ #cmakedefine USE_WOLFSSL diff --git a/lwsws/etc-lwsws-conf.d-localhost-EXAMPLE b/lwsws/etc-lwsws-conf.d-localhost-EXAMPLE index 59bf9aa82..42ac27536 100644 --- a/lwsws/etc-lwsws-conf.d-localhost-EXAMPLE +++ b/lwsws/etc-lwsws-conf.d-localhost-EXAMPLE @@ -10,7 +10,7 @@ # "sts": "on", "mounts": [{ "mountpoint": "/", - "origin": "file:///usr/share/libwebsockets-test-server", + "origin": "file://_lws_ddir_/libwebsockets-test-server", "default": "test.html", "cache-max-age": "60", "cache-reuse": "1", @@ -18,11 +18,11 @@ "cache-intermediaries": "0" }, { "mountpoint": "/server-status", - "origin": "file:///usr/share/libwebsockets-test-server/server-status", + "origin": "file://_lws_ddir_/libwebsockets-test-server/server-status", "default": "server-status.html" }, { "mountpoint": "/testcgi", - "origin": "cgi:///usr/share/libwebsockets-test-server/lws-cgi-test.sh" + "origin": "cgi://_lws_ddir_/libwebsockets-test-server/lws-cgi-test.sh" }, { "mountpoint": "/formtest",