From e3f6ed2d6547bf910fe5e6a21ea660ea83b0e7b7 Mon Sep 17 00:00:00 2001 From: Christos Trochalakis Date: Thu, 27 Dec 2018 14:44:09 +0200 Subject: [PATCH 01/55] Add missing changelog entries Those were forgotten during the upload, but let's add them for completeness. Gbp-Dch: Ignore --- debian/changelog | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/changelog b/debian/changelog index be5df648..93a36f21 100644 --- a/debian/changelog +++ b/debian/changelog @@ -7,6 +7,8 @@ nginx (1.14.2-2) unstable; urgency=medium [ Christos Trochalakis ] * http-dav-ext: Upgrade to 3.0.0 (Closes: #851651) + * Use a minimal export of the upstream signing key + * Bump Standards-Version, no changes needed -- Christos Trochalakis Thu, 27 Dec 2018 12:49:34 +0200 From ccedd1185b2471d7b50d5617b5383fb021001888 Mon Sep 17 00:00:00 2001 From: Christos Trochalakis Date: Tue, 13 Aug 2019 21:04:39 +0300 Subject: [PATCH 02/55] gbp: setup for buster Gbp-Dch: Ignore --- debian/gbp.conf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/gbp.conf b/debian/gbp.conf index a14a6992..b5fb2c91 100644 --- a/debian/gbp.conf +++ b/debian/gbp.conf @@ -2,3 +2,5 @@ pristine-tar = True upstream-branch = upstream upstream-tag = upstream/%(version)s +dist=buster +debian-branch=buster From fce697b5bc7fca3b89cfc8ebd941f8dfc5b13388 Mon Sep 17 00:00:00 2001 From: Christos Trochalakis Date: Mon, 19 Aug 2019 11:33:14 +0300 Subject: [PATCH 03/55] Handle CVE-2019-9511 CVE-2019-9513 CVE-2019-9516 Several security issues were identified in nginx HTTP/2 implementation, which might cause excessive memory consumption and CPU usage (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516). The issues affect nginx compiled with the ngx_http_v2_module (not compiled by default) if the "http2" option of the "listen" directive is used in a configuration file. The issues affect nginx 1.9.5 - 1.17.2. The issues are fixed in nginx 1.17.3, 1.16.1. Thanks to Jonathan Looney from Netflix for discovering these issues. --- debian/patches/CVE-2019-9511.patch | 87 ++++++++++++++++++++++++++++++ debian/patches/CVE-2019-9513.patch | 62 +++++++++++++++++++++ debian/patches/CVE-2019-9516.patch | 45 ++++++++++++++++ debian/patches/series | 3 ++ 4 files changed, 197 insertions(+) create mode 100644 debian/patches/CVE-2019-9511.patch create mode 100644 debian/patches/CVE-2019-9513.patch create mode 100644 debian/patches/CVE-2019-9516.patch diff --git a/debian/patches/CVE-2019-9511.patch b/debian/patches/CVE-2019-9511.patch new file mode 100644 index 00000000..3b48e0cd --- /dev/null +++ b/debian/patches/CVE-2019-9511.patch @@ -0,0 +1,87 @@ +From 3f64486e0c15414dc6368139453dcaca338ddf3e Mon Sep 17 00:00:00 2001 +From: Ruslan Ermilov +Date: Tue, 13 Aug 2019 15:43:36 +0300 +Subject: [PATCH 2/3] HTTP/2: limited number of DATA frames. + +Fixed excessive memory growth and CPU usage if stream windows are +manipulated in a way that results in generating many small DATA frames. +Fix is to limit the number of simultaneously allocated DATA frames. +--- + src/http/v2/ngx_http_v2.c | 2 ++ + src/http/v2/ngx_http_v2.h | 2 ++ + src/http/v2/ngx_http_v2_filter_module.c | 22 +++++++++++++++++----- + 3 files changed, 21 insertions(+), 5 deletions(-) + +diff --git a/src/http/v2/ngx_http_v2.c b/src/http/v2/ngx_http_v2.c +index be2ef82b..1b01f271 100644 +--- a/src/http/v2/ngx_http_v2.c ++++ b/src/http/v2/ngx_http_v2.c +@@ -4339,6 +4339,8 @@ ngx_http_v2_close_stream(ngx_http_v2_stream_t *stream, ngx_int_t rc) + */ + pool = stream->pool; + ++ h2c->frames -= stream->frames; ++ + ngx_http_free_request(stream->request, rc); + + if (pool != h2c->state.pool) { +diff --git a/src/http/v2/ngx_http_v2.h b/src/http/v2/ngx_http_v2.h +index bec22160..715b7d30 100644 +--- a/src/http/v2/ngx_http_v2.h ++++ b/src/http/v2/ngx_http_v2.h +@@ -192,6 +192,8 @@ struct ngx_http_v2_stream_s { + + ngx_buf_t *preread; + ++ ngx_uint_t frames; ++ + ngx_http_v2_out_frame_t *free_frames; + ngx_chain_t *free_frame_headers; + ngx_chain_t *free_bufs; +diff --git a/src/http/v2/ngx_http_v2_filter_module.c b/src/http/v2/ngx_http_v2_filter_module.c +index 029e8ece..c7ee5536 100644 +--- a/src/http/v2/ngx_http_v2_filter_module.c ++++ b/src/http/v2/ngx_http_v2_filter_module.c +@@ -1661,22 +1661,34 @@ static ngx_http_v2_out_frame_t * + ngx_http_v2_filter_get_data_frame(ngx_http_v2_stream_t *stream, + size_t len, ngx_chain_t *first, ngx_chain_t *last) + { +- u_char flags; +- ngx_buf_t *buf; +- ngx_chain_t *cl; +- ngx_http_v2_out_frame_t *frame; ++ u_char flags; ++ ngx_buf_t *buf; ++ ngx_chain_t *cl; ++ ngx_http_v2_out_frame_t *frame; ++ ngx_http_v2_connection_t *h2c; + + frame = stream->free_frames; ++ h2c = stream->connection; + + if (frame) { + stream->free_frames = frame->next; + +- } else { ++ } else if (h2c->frames < 10000) { + frame = ngx_palloc(stream->request->pool, + sizeof(ngx_http_v2_out_frame_t)); + if (frame == NULL) { + return NULL; + } ++ ++ stream->frames++; ++ h2c->frames++; ++ ++ } else { ++ ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0, ++ "http2 flood detected"); ++ ++ h2c->connection->error = 1; ++ return NULL; + } + + flags = last->buf->last_buf ? NGX_HTTP_V2_END_STREAM_FLAG : 0; +-- +2.20.1 + diff --git a/debian/patches/CVE-2019-9513.patch b/debian/patches/CVE-2019-9513.patch new file mode 100644 index 00000000..edc1c2b8 --- /dev/null +++ b/debian/patches/CVE-2019-9513.patch @@ -0,0 +1,62 @@ +From bbdc81631b6d322785d8e92788fd400e25a931e6 Mon Sep 17 00:00:00 2001 +From: Ruslan Ermilov +Date: Tue, 13 Aug 2019 15:43:40 +0300 +Subject: [PATCH 3/3] HTTP/2: limited number of PRIORITY frames. + +Fixed excessive CPU usage caused by a peer that continuously shuffles +priority of streams. Fix is to limit the number of PRIORITY frames. +--- + src/http/v2/ngx_http_v2.c | 10 ++++++++++ + src/http/v2/ngx_http_v2.h | 1 + + 2 files changed, 11 insertions(+) + +diff --git a/src/http/v2/ngx_http_v2.c b/src/http/v2/ngx_http_v2.c +index 1b01f271..fd6ecb05 100644 +--- a/src/http/v2/ngx_http_v2.c ++++ b/src/http/v2/ngx_http_v2.c +@@ -275,6 +275,7 @@ ngx_http_v2_init(ngx_event_t *rev) + h2scf = ngx_http_get_module_srv_conf(hc->conf_ctx, ngx_http_v2_module); + + h2c->concurrent_pushes = h2scf->concurrent_pushes; ++ h2c->priority_limit = h2scf->concurrent_streams; + + h2c->pool = ngx_create_pool(h2scf->pool_size, h2c->connection->log); + if (h2c->pool == NULL) { +@@ -1806,6 +1807,13 @@ ngx_http_v2_state_priority(ngx_http_v2_connection_t *h2c, u_char *pos, + return ngx_http_v2_connection_error(h2c, NGX_HTTP_V2_SIZE_ERROR); + } + ++ if (--h2c->priority_limit == 0) { ++ ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0, ++ "client sent too many PRIORITY frames"); ++ ++ return ngx_http_v2_connection_error(h2c, NGX_HTTP_V2_ENHANCE_YOUR_CALM); ++ } ++ + if (end - pos < NGX_HTTP_V2_PRIORITY_SIZE) { + return ngx_http_v2_state_save(h2c, pos, end, + ngx_http_v2_state_priority); +@@ -3120,6 +3128,8 @@ ngx_http_v2_create_stream(ngx_http_v2_connection_t *h2c, ngx_uint_t push) + h2c->processing++; + } + ++ h2c->priority_limit += h2scf->concurrent_streams; ++ + return stream; + } + +diff --git a/src/http/v2/ngx_http_v2.h b/src/http/v2/ngx_http_v2.h +index 715b7d30..69d55d1c 100644 +--- a/src/http/v2/ngx_http_v2.h ++++ b/src/http/v2/ngx_http_v2.h +@@ -122,6 +122,7 @@ struct ngx_http_v2_connection_s { + ngx_uint_t processing; + ngx_uint_t frames; + ngx_uint_t idle; ++ ngx_uint_t priority_limit; + + ngx_uint_t pushing; + ngx_uint_t concurrent_pushes; +-- +2.20.1 + diff --git a/debian/patches/CVE-2019-9516.patch b/debian/patches/CVE-2019-9516.patch new file mode 100644 index 00000000..0d5ec774 --- /dev/null +++ b/debian/patches/CVE-2019-9516.patch @@ -0,0 +1,45 @@ +From 840d8a3e2f126384eb4ee3e5dd7ffe875a5634c5 Mon Sep 17 00:00:00 2001 +From: Sergey Kandaurov +Date: Tue, 13 Aug 2019 15:43:32 +0300 +Subject: [PATCH 1/3] HTTP/2: reject zero length headers with PROTOCOL_ERROR. + +Fixed uncontrolled memory growth if peer sends a stream of +headers with a 0-length header name and 0-length header value. +Fix is to reject headers with zero name length. +--- + src/http/v2/ngx_http_v2.c | 12 ++++++++---- + 1 file changed, 8 insertions(+), 4 deletions(-) + +diff --git a/src/http/v2/ngx_http_v2.c b/src/http/v2/ngx_http_v2.c +index 12214e15..be2ef82b 100644 +--- a/src/http/v2/ngx_http_v2.c ++++ b/src/http/v2/ngx_http_v2.c +@@ -1548,6 +1548,14 @@ ngx_http_v2_state_process_header(ngx_http_v2_connection_t *h2c, u_char *pos, + header->name.len = h2c->state.field_end - h2c->state.field_start; + header->name.data = h2c->state.field_start; + ++ if (header->name.len == 0) { ++ ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0, ++ "client sent zero header name length"); ++ ++ return ngx_http_v2_connection_error(h2c, ++ NGX_HTTP_V2_PROTOCOL_ERROR); ++ } ++ + return ngx_http_v2_state_field_len(h2c, pos, end); + } + +@@ -3249,10 +3257,6 @@ ngx_http_v2_validate_header(ngx_http_request_t *r, ngx_http_v2_header_t *header) + ngx_uint_t i; + ngx_http_core_srv_conf_t *cscf; + +- if (header->name.len == 0) { +- return NGX_ERROR; +- } +- + r->invalid_header = 0; + + cscf = ngx_http_get_module_srv_conf(r, ngx_http_core_module); +-- +2.20.1 + diff --git a/debian/patches/series b/debian/patches/series index 5b6b799f..dfc20c17 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,2 +1,5 @@ 0002-Make-sure-signature-stays-the-same-in-all-nginx-buil.patch 0003-define_gnu_source-on-other-glibc-based-platforms.patch +CVE-2019-9516.patch +CVE-2019-9511.patch +CVE-2019-9513.patch From 117fc2156ffdf628d28bb469b920f7d4cbf19d2c Mon Sep 17 00:00:00 2001 From: Christos Trochalakis Date: Mon, 19 Aug 2019 13:03:31 +0300 Subject: [PATCH 04/55] Release 1.14.2-2+deb10u1 --- debian/changelog | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/debian/changelog b/debian/changelog index 93a36f21..b2c8dc3d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +nginx (1.14.2-2+deb10u1) buster-security; urgency=high + + * Backport upstream fixes for 3 CVEs (Closes: #935037) + Those fixes affect Nginx HTTP/2 implementation, which might cause + excessive memory consumption and CPU usage. + (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516). + + -- Christos Trochalakis Tue, 13 Aug 2019 21:10:28 +0300 + nginx (1.14.2-2) unstable; urgency=medium [ Kartik Mistry ] From 06b6f5670e9ca2b6d71f05b6b531ac661b10c4b6 Mon Sep 17 00:00:00 2001 From: Christos Trochalakis Date: Sat, 11 Jan 2020 09:21:48 +0200 Subject: [PATCH 05/55] Handle CVE-2019-20372, error page request smuggling Nginx before 1.17.7, with certain error_page configurations, allows HTTP request smuggling, as demonstrated by the ability of an attacker to read unauthorized web pages in environments where NGINX is being fronted by a load balancer. --- debian/patches/CVE-2019-20372.patch | 31 +++++++++++++++++++++++++++++ debian/patches/series | 1 + 2 files changed, 32 insertions(+) create mode 100644 debian/patches/CVE-2019-20372.patch diff --git a/debian/patches/CVE-2019-20372.patch b/debian/patches/CVE-2019-20372.patch new file mode 100644 index 00000000..7793fa49 --- /dev/null +++ b/debian/patches/CVE-2019-20372.patch @@ -0,0 +1,31 @@ +From 8bffc01d084b4881e3eed2052c115b8f04268cb9 Mon Sep 17 00:00:00 2001 +From: Ruslan Ermilov +Date: Mon, 23 Dec 2019 15:45:46 +0300 +Subject: [PATCH] Discard request body when redirecting to a URL via + error_page. + +Reported by Bert JW Regeer and Francisco Oca Gonzalez. +--- + src/http/ngx_http_special_response.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/src/http/ngx_http_special_response.c b/src/http/ngx_http_special_response.c +index 2c1ff174..e2a5e9dc 100644 +--- a/src/http/ngx_http_special_response.c ++++ b/src/http/ngx_http_special_response.c +@@ -623,6 +623,12 @@ ngx_http_send_error_page(ngx_http_request_t *r, ngx_http_err_page_t *err_page) + return ngx_http_named_location(r, &uri); + } + ++ r->expect_tested = 1; ++ ++ if (ngx_http_discard_request_body(r) != NGX_OK) { ++ r->keepalive = 0; ++ } ++ + location = ngx_list_push(&r->headers_out.headers); + + if (location == NULL) { +-- +2.23.0 + diff --git a/debian/patches/series b/debian/patches/series index 5b6b799f..b221db70 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,2 +1,3 @@ 0002-Make-sure-signature-stays-the-same-in-all-nginx-buil.patch 0003-define_gnu_source-on-other-glibc-based-platforms.patch +CVE-2019-20372.patch From f6841c97e24e562a828e90ab7f00598c2fd987f0 Mon Sep 17 00:00:00 2001 From: Christos Trochalakis Date: Sat, 11 Jan 2020 09:37:17 +0200 Subject: [PATCH 06/55] Release 1.16.1-3 --- debian/changelog | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/debian/changelog b/debian/changelog index a692f860..4f124226 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +nginx (1.16.1-3) unstable; urgency=high + + * Handle CVE-2019-20372, error page request smuggling + (Closes: #948579) + + -- Christos Trochalakis Sat, 11 Jan 2020 09:36:00 +0200 + nginx (1.16.1-2) unstable; urgency=medium * http-lua: Downgrade to 0.10.13 (Closes: #941917) From 55ef39e8e194200d8c2da5da12c96594971b41bb Mon Sep 17 00:00:00 2001 From: Mohamed Akram Date: Mon, 11 May 2020 22:44:59 +0400 Subject: [PATCH 07/55] Enable --with-compat configure option Closes: #897926 --- debian/rules | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/rules b/debian/rules index 981a57e3..4f28b78f 100755 --- a/debian/rules +++ b/debian/rules @@ -60,6 +60,7 @@ common_configure_flags := \ --http-proxy-temp-path=/var/lib/nginx/proxy \ --http-scgi-temp-path=/var/lib/nginx/scgi \ --http-uwsgi-temp-path=/var/lib/nginx/uwsgi \ + --with-compat \ --with-debug \ --with-pcre-jit \ --with-http_ssl_module \ From e5f8119f92409de49e5ab9dfd8f0eba44b61fa5c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Nov=C3=BD?= Date: Thu, 28 May 2020 19:56:08 +0200 Subject: [PATCH 08/55] Add REMOTE_USER fastcgi param --- debian/conf/fastcgi.conf | 1 + debian/conf/fastcgi_params | 1 + 2 files changed, 2 insertions(+) diff --git a/debian/conf/fastcgi.conf b/debian/conf/fastcgi.conf index 091738c6..d53a628d 100644 --- a/debian/conf/fastcgi.conf +++ b/debian/conf/fastcgi.conf @@ -18,6 +18,7 @@ fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; +fastcgi_param REMOTE_USER $remote_user; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_NAME $server_name; diff --git a/debian/conf/fastcgi_params b/debian/conf/fastcgi_params index 28decb95..69c43877 100644 --- a/debian/conf/fastcgi_params +++ b/debian/conf/fastcgi_params @@ -17,6 +17,7 @@ fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; +fastcgi_param REMOTE_USER $remote_user; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_NAME $server_name; From 3ef09c0f692984ea8b3ea2f40f0fa15e8502433e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Nov=C3=BD?= Date: Thu, 28 May 2020 20:30:37 +0200 Subject: [PATCH 09/55] Use debhelper-compat instead of debian/compat --- debian/compat | 1 - debian/control | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) delete mode 100644 debian/compat diff --git a/debian/compat b/debian/compat deleted file mode 100644 index f599e28b..00000000 --- a/debian/compat +++ /dev/null @@ -1 +0,0 @@ -10 diff --git a/debian/control b/debian/control index 409dc22b..68608007 100644 --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Section: httpd Priority: optional Maintainer: Debian Nginx Maintainers Uploaders: Christos Trochalakis -Build-Depends: debhelper (>= 10), +Build-Depends: debhelper-compat (= 10), dpkg-dev (>= 1.15.5), libexpat-dev, libgd-dev, From 2b4e972bd350a3431f4313d154c4cc2854ee6024 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Nov=C3=BD?= Date: Thu, 28 May 2020 20:36:23 +0200 Subject: [PATCH 10/55] Replace dh_systemd_enable with dh_installsystemd --- debian/rules | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/rules b/debian/rules index 4f28b78f..8b3f962e 100755 --- a/debian/rules +++ b/debian/rules @@ -154,8 +154,8 @@ override_dh_install: override_dh_installinit: dh_installinit --no-restart-on-upgrade --no-start --name=nginx -override_dh_systemd_enable: - dh_systemd_enable --name=nginx +override_dh_installsystemd: + dh_installsystemd --name=nginx override_dh_installlogrotate: dh_installlogrotate --package nginx-common --name=nginx From 12e9c91f45b611aeb9c66e3f7ea531b637e9ba6e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Nov=C3=BD?= Date: Thu, 28 May 2020 20:41:04 +0200 Subject: [PATCH 11/55] Set Rules-Requires-Root: no --- debian/control | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/control b/debian/control index 68608007..34b14d72 100644 --- a/debian/control +++ b/debian/control @@ -24,6 +24,7 @@ Standards-Version: 4.3.0 Homepage: https://nginx.net Vcs-Git: https://salsa.debian.org/nginx-team/nginx.git Vcs-Browser: https://salsa.debian.org/nginx-team/nginx +Rules-Requires-Root: no Package: nginx Architecture: all From 7f0bb450a9742c809e22e8b31f32d359945ab1d8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Nov=C3=BD?= Date: Thu, 28 May 2020 20:49:21 +0200 Subject: [PATCH 12/55] d/rules/dh_installinit: Replace --no-restart-on-upgrade with --no-stop-on-upgrade --- debian/rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index 8b3f962e..bf4b9f32 100755 --- a/debian/rules +++ b/debian/rules @@ -152,7 +152,7 @@ override_dh_install: DH_AUTOSCRIPTDIR=$(CURDIR)/debian/autoscripts debian/dh_nginx override_dh_installinit: - dh_installinit --no-restart-on-upgrade --no-start --name=nginx + dh_installinit --no-stop-on-upgrade --no-start --name=nginx override_dh_installsystemd: dh_installsystemd --name=nginx From 52a04bd90d7a5098654e8eceb286adca5b4b6e30 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Nov=C3=BD?= Date: Thu, 28 May 2020 20:54:39 +0200 Subject: [PATCH 13/55] Bump debhelper compat level to 13 --- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 34b14d72..e2f39900 100644 --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Section: httpd Priority: optional Maintainer: Debian Nginx Maintainers Uploaders: Christos Trochalakis -Build-Depends: debhelper-compat (= 10), +Build-Depends: debhelper-compat (= 13), dpkg-dev (>= 1.15.5), libexpat-dev, libgd-dev, From d089e100447b31ef880030665879ce26b832af3e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Nov=C3=BD?= Date: Thu, 28 May 2020 21:04:44 +0200 Subject: [PATCH 14/55] Use package.maintscript instead of dpkg-maintscript-helper --- debian/nginx-common.maintscript | 8 ++++++++ debian/nginx-common.postinst | 14 -------------- debian/nginx-common.postrm | 14 -------------- debian/nginx-common.preinst | 14 -------------- 4 files changed, 8 insertions(+), 42 deletions(-) create mode 100644 debian/nginx-common.maintscript diff --git a/debian/nginx-common.maintscript b/debian/nginx-common.maintscript new file mode 100644 index 00000000..e1e7f535 --- /dev/null +++ b/debian/nginx-common.maintscript @@ -0,0 +1,8 @@ +# Handle naxsi removal +rm_conffile /etc/nginx/naxsi.rules 1.6.2-2~ +rm_conffile /etc/nginx/naxsi_core.rules 1.6.2-2~ +rm_conffile /etc/nginx/naxsi-ui.conf.1.4.1 1.6.2-2~ +rm_conffile /etc/nginx/naxsi-ui.conf 1.6.2-2~ + +# Handle upstart removal +rm_conffile /etc/init/nginx.conf 1.13.5-1~ diff --git a/debian/nginx-common.postinst b/debian/nginx-common.postinst index f83032db..9e0610ec 100644 --- a/debian/nginx-common.postinst +++ b/debian/nginx-common.postinst @@ -3,20 +3,6 @@ set -e . /usr/share/debconf/confmodule -# Handle naxsi removal -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi.rules 1.6.2-2~ -- "$@" -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi_core.rules 1.6.2-2~ -- "$@" -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi-ui.conf.1.4.1 1.6.2-2~ -- "$@" -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi-ui.conf 1.6.2-2~ -- "$@" - -# Handle upstart removal -dpkg-maintscript-helper rm_conffile \ - /etc/init/nginx.conf 1.13.5-1~ -- "$@" - case "$1" in configure) logdir="/var/log/nginx" diff --git a/debian/nginx-common.postrm b/debian/nginx-common.postrm index d6f313ad..f5124c80 100644 --- a/debian/nginx-common.postrm +++ b/debian/nginx-common.postrm @@ -1,20 +1,6 @@ #!/bin/sh set -e -# Handle naxsi removal -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi.rules 1.6.2-2~ -- "$@" -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi_core.rules 1.6.2-2~ -- "$@" -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi-ui.conf.1.4.1 1.6.2-2~ -- "$@" -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi-ui.conf 1.6.2-2~ -- "$@" - -# Handle upstart removal -dpkg-maintscript-helper rm_conffile \ - /etc/init/nginx.conf 1.13.5-1~ -- "$@" - case "$1" in purge) rm -rf /var/lib/nginx /var/log/nginx /etc/nginx diff --git a/debian/nginx-common.preinst b/debian/nginx-common.preinst index 27f21da6..ead53f77 100644 --- a/debian/nginx-common.preinst +++ b/debian/nginx-common.preinst @@ -1,20 +1,6 @@ #!/bin/sh set -e -# Handle naxsi removal -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi.rules 1.6.2-2~ -- "$@" -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi_core.rules 1.6.2-2~ -- "$@" -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi-ui.conf.1.4.1 1.6.2-2~ -- "$@" -dpkg-maintscript-helper rm_conffile \ - /etc/nginx/naxsi-ui.conf 1.6.2-2~ -- "$@" - -# Handle upstart removal -dpkg-maintscript-helper rm_conffile \ - /etc/init/nginx.conf 1.13.5-1~ -- "$@" - case "$1" in install) # If we are doing a fresh install, then these files are no longer needed. From 403f780a4693f70066f9659cae8fc0e6adea161c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Nov=C3=BD?= Date: Thu, 28 May 2020 21:15:12 +0200 Subject: [PATCH 15/55] Bump standards version to 4.5.0 --- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index e2f39900..835af431 100644 --- a/debian/control +++ b/debian/control @@ -20,7 +20,7 @@ Build-Depends: debhelper-compat (= 13), po-debconf, quilt, zlib1g-dev -Standards-Version: 4.3.0 +Standards-Version: 4.5.0 Homepage: https://nginx.net Vcs-Git: https://salsa.debian.org/nginx-team/nginx.git Vcs-Browser: https://salsa.debian.org/nginx-team/nginx From b575cfe355931e42fb61febe58d06076a8b10725 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Nov=C3=BD?= Date: Thu, 28 May 2020 21:22:34 +0200 Subject: [PATCH 16/55] nchan: Upgrade to 1.2.7 --- debian/modules/nchan/README.md | 1031 +++++++- debian/modules/nchan/changelog.txt | 205 ++ debian/modules/nchan/cloc-exclude.txt | 21 +- debian/modules/nchan/config | 87 +- debian/modules/nchan/src/nchan_commands.rb | 383 ++- .../modules/nchan/src/nchan_config_commands.c | 284 ++- debian/modules/nchan/src/nchan_defs.c | 9 +- debian/modules/nchan/src/nchan_defs.h | 11 +- debian/modules/nchan/src/nchan_module.c | 420 ++-- debian/modules/nchan/src/nchan_module.h | 34 +- debian/modules/nchan/src/nchan_setup.c | 705 +++++- debian/modules/nchan/src/nchan_types.h | 197 +- debian/modules/nchan/src/nchan_variables.c | 6 + debian/modules/nchan/src/nchan_version.h | 1 + .../modules/nchan/src/store/memory/groups.c | 570 +++++ .../modules/nchan/src/store/memory/groups.h | 55 + .../nchan/src/store/memory/ipc-handlers.c | 697 ++++-- .../nchan/src/store/memory/ipc-handlers.h | 16 +- debian/modules/nchan/src/store/memory/ipc.c | 30 +- debian/modules/nchan/src/store/memory/ipc.h | 11 +- .../modules/nchan/src/store/memory/memstore.c | 1473 +++++++---- .../nchan/src/store/memory/store-private.h | 41 +- debian/modules/nchan/src/store/memory/store.h | 6 +- .../modules/nchan/src/store/redis/cluster.c | 1257 ---------- .../modules/nchan/src/store/redis/cluster.h | 30 - debian/modules/nchan/src/store/redis/cmp.c | 1337 ++++++---- debian/modules/nchan/src/store/redis/cmp.h | 66 +- .../nchan/src/store/redis/hiredis/.gitignore | 7 + .../nchan/src/store/redis/hiredis/.travis.yml | 24 + .../src/store/redis/hiredis/CHANGELOG.md | 110 + .../nchan/src/store/redis/hiredis/COPYING | 29 + .../nchan/src/store/redis/hiredis/Makefile | 217 ++ .../nchan/src/store/redis/hiredis/README.md | 392 +++ .../src/store/redis/hiredis/adapters/ae.h | 127 + .../src/store/redis/hiredis/adapters/libev.h | 147 ++ .../store/redis/hiredis/adapters/libevent.h | 108 + .../src/store/redis/hiredis/adapters/libuv.h | 121 + .../nchan/src/store/redis/hiredis/async.c | 687 ++++++ .../nchan/src/store/redis/hiredis/async.h | 129 + .../nchan/src/store/redis/hiredis/dict.c | 338 +++ .../nchan/src/store/redis/hiredis/dict.h | 126 + .../store/redis/hiredis/examples/example-ae.c | 62 + .../redis/hiredis/examples/example-libev.c | 52 + .../redis/hiredis/examples/example-libevent.c | 53 + .../redis/hiredis/examples/example-libuv.c | 53 + .../store/redis/hiredis/examples/example.c | 78 + .../nchan/src/store/redis/hiredis/fmacros.h | 21 + .../nchan/src/store/redis/hiredis/hiredis.c | 1021 ++++++++ .../nchan/src/store/redis/hiredis/hiredis.h | 226 ++ .../nchan/src/store/redis/hiredis/net.c | 461 ++++ .../nchan/src/store/redis/hiredis/net.h | 53 + .../nchan/src/store/redis/hiredis/read.c | 525 ++++ .../nchan/src/store/redis/hiredis/read.h | 116 + .../nchan/src/store/redis/hiredis/sds.c | 1095 +++++++++ .../nchan/src/store/redis/hiredis/sds.h | 105 + .../nchan/src/store/redis/hiredis/test.c | 807 ++++++ .../nchan/src/store/redis/hiredis/win32.h | 42 + .../modules/nchan/src/store/redis/rdsstore.c | 2131 +++++++--------- .../{scripts => redis-lua-scripts}/.gitignore | 0 .../{scripts => redis-lua-scripts}/Gemfile | 0 .../add_fakesub.lua | 13 +- .../channel_keepalive.lua | 9 +- .../{scripts => redis-lua-scripts}/delete.lua | 56 +- .../redis/redis-lua-scripts/find_channel.lua | 70 + .../get_message.lua | 33 +- .../get_message_from_key.lua | 8 + .../publish.lua | 119 +- .../publish_status.lua | 8 +- .../{scripts => redis-lua-scripts}/rsck.lua | 37 +- .../subscriber_register.lua | 24 +- .../subscriber_unregister.lua | 6 +- .../testscripts.rb | 7 +- .../src/store/redis/redis_lua_commands.c | 1036 ++++++++ .../src/store/redis/redis_lua_commands.h | 1001 +------- .../src/store/redis/redis_nginx_adapter.c | 64 +- .../src/store/redis/redis_nginx_adapter.h | 7 +- .../nchan/src/store/redis/redis_nodeset.c | 2179 +++++++++++++++++ .../nchan/src/store/redis/redis_nodeset.h | 276 +++ .../src/store/redis/redis_nodeset_parser.c | 241 ++ .../src/store/redis/redis_nodeset_parser.h | 40 + .../src/store/redis/scripts/find_channel.lua | 56 - .../redis/scripts/get_message_from_key.lua | 9 - .../nchan/src/store/redis/store-private.h | 192 +- debian/modules/nchan/src/store/redis/store.h | 11 +- debian/modules/nchan/src/store/spool.c | 290 ++- debian/modules/nchan/src/store/spool.h | 14 +- .../modules/nchan/src/subscribers/benchmark.c | 72 + .../modules/nchan/src/subscribers/benchmark.h | 3 + debian/modules/nchan/src/subscribers/common.c | 573 ++--- debian/modules/nchan/src/subscribers/common.h | 17 +- .../nchan/src/subscribers/eventsource.c | 94 +- .../nchan/src/subscribers/getmsg_proxy.c | 106 + .../nchan/src/subscribers/getmsg_proxy.h | 1 + .../nchan/src/subscribers/http-chunked.c | 10 +- .../src/subscribers/http-multipart-mixed.c | 27 +- .../nchan/src/subscribers/http-raw-stream.c | 16 +- .../modules/nchan/src/subscribers/internal.c | 19 +- .../nchan/src/subscribers/longpoll-private.h | 4 +- .../modules/nchan/src/subscribers/longpoll.c | 240 +- .../nchan/src/subscribers/memstore_ipc.c | 63 +- .../nchan/src/subscribers/memstore_ipc.h | 3 + .../nchan/src/subscribers/memstore_multi.c | 53 +- .../nchan/src/subscribers/memstore_redis.c | 130 +- .../nchan/src/subscribers/memstore_redis.h | 1 - .../modules/nchan/src/subscribers/websocket.c | 1398 +++++++---- .../modules/nchan/src/subscribers/websocket.h | 3 +- debian/modules/nchan/src/uthash.h | 1236 ++++++---- debian/modules/nchan/src/util/hdr_histogram.c | 1015 ++++++++ debian/modules/nchan/src/util/hdr_histogram.h | 427 ++++ .../modules/nchan/src/util/nchan_benchmark.c | 804 ++++++ .../modules/nchan/src/util/nchan_benchmark.h | 91 + .../nchan/src/util/nchan_bufchainpool.c | 96 + .../nchan/src/util/nchan_bufchainpool.h | 17 + .../modules/nchan/src/util/nchan_channel_id.c | 82 +- .../modules/nchan/src/util/nchan_channel_id.h | 5 +- .../nchan/src/util/nchan_channel_info.c | 128 - .../nchan/src/util/nchan_channel_info.h | 7 - debian/modules/nchan/src/util/nchan_debug.c | 81 + debian/modules/nchan/src/util/nchan_debug.h | 13 + .../nchan/src/util/nchan_fake_request.c | 291 ++- .../nchan/src/util/nchan_fake_request.h | 58 +- debian/modules/nchan/src/util/nchan_list.c | 26 + debian/modules/nchan/src/util/nchan_list.h | 5 + .../src/util/{nchan_msgid.c => nchan_msg.c} | 324 ++- .../src/util/{nchan_msgid.h => nchan_msg.h} | 19 + debian/modules/nchan/src/util/nchan_output.c | 95 +- debian/modules/nchan/src/util/nchan_output.h | 6 +- .../nchan/src/util/nchan_output_info.c | 271 ++ .../nchan/src/util/nchan_output_info.h | 6 + debian/modules/nchan/src/util/nchan_rbtree.h | 6 +- debian/modules/nchan/src/util/nchan_slist.c | 164 ++ debian/modules/nchan/src/util/nchan_slist.h | 41 + .../modules/nchan/src/util/nchan_subrequest.c | 75 +- .../modules/nchan/src/util/nchan_subrequest.h | 5 +- debian/modules/nchan/src/util/nchan_util.c | 913 ++++++- debian/modules/nchan/src/util/nchan_util.h | 50 +- .../nchan/src/util/ngx_nchan_hacked_slab.c | 4 + debian/modules/nchan/src/util/shmem.c | 49 +- debian/modules/nchan/src/util/shmem.h | 5 + 139 files changed, 26022 insertions(+), 7478 deletions(-) mode change 100755 => 100644 debian/modules/nchan/src/nchan_module.c create mode 100644 debian/modules/nchan/src/nchan_version.h create mode 100644 debian/modules/nchan/src/store/memory/groups.c create mode 100644 debian/modules/nchan/src/store/memory/groups.h delete mode 100644 debian/modules/nchan/src/store/redis/cluster.c delete mode 100644 debian/modules/nchan/src/store/redis/cluster.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/.gitignore create mode 100644 debian/modules/nchan/src/store/redis/hiredis/.travis.yml create mode 100644 debian/modules/nchan/src/store/redis/hiredis/CHANGELOG.md create mode 100644 debian/modules/nchan/src/store/redis/hiredis/COPYING create mode 100644 debian/modules/nchan/src/store/redis/hiredis/Makefile create mode 100644 debian/modules/nchan/src/store/redis/hiredis/README.md create mode 100644 debian/modules/nchan/src/store/redis/hiredis/adapters/ae.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/adapters/libev.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/adapters/libevent.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/adapters/libuv.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/async.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/async.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/dict.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/dict.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/examples/example-ae.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/examples/example-libev.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/examples/example-libevent.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/examples/example-libuv.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/examples/example.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/fmacros.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/hiredis.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/hiredis.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/net.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/net.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/read.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/read.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/sds.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/sds.h create mode 100644 debian/modules/nchan/src/store/redis/hiredis/test.c create mode 100644 debian/modules/nchan/src/store/redis/hiredis/win32.h rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/.gitignore (100%) rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/Gemfile (100%) rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/add_fakesub.lua (65%) rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/channel_keepalive.lua (85%) rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/delete.lua (54%) create mode 100644 debian/modules/nchan/src/store/redis/redis-lua-scripts/find_channel.lua rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/get_message.lua (80%) create mode 100644 debian/modules/nchan/src/store/redis/redis-lua-scripts/get_message_from_key.lua rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/publish.lua (71%) rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/publish_status.lua (81%) rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/rsck.lua (86%) rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/subscriber_register.lua (62%) rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/subscriber_unregister.lua (85%) rename debian/modules/nchan/src/store/redis/{scripts => redis-lua-scripts}/testscripts.rb (94%) create mode 100644 debian/modules/nchan/src/store/redis/redis_lua_commands.c create mode 100644 debian/modules/nchan/src/store/redis/redis_nodeset.c create mode 100644 debian/modules/nchan/src/store/redis/redis_nodeset.h create mode 100644 debian/modules/nchan/src/store/redis/redis_nodeset_parser.c create mode 100644 debian/modules/nchan/src/store/redis/redis_nodeset_parser.h delete mode 100644 debian/modules/nchan/src/store/redis/scripts/find_channel.lua delete mode 100644 debian/modules/nchan/src/store/redis/scripts/get_message_from_key.lua create mode 100644 debian/modules/nchan/src/subscribers/benchmark.c create mode 100644 debian/modules/nchan/src/subscribers/benchmark.h create mode 100644 debian/modules/nchan/src/subscribers/getmsg_proxy.c create mode 100644 debian/modules/nchan/src/subscribers/getmsg_proxy.h create mode 100644 debian/modules/nchan/src/util/hdr_histogram.c create mode 100644 debian/modules/nchan/src/util/hdr_histogram.h create mode 100644 debian/modules/nchan/src/util/nchan_benchmark.c create mode 100644 debian/modules/nchan/src/util/nchan_benchmark.h delete mode 100644 debian/modules/nchan/src/util/nchan_channel_info.c delete mode 100644 debian/modules/nchan/src/util/nchan_channel_info.h create mode 100644 debian/modules/nchan/src/util/nchan_debug.c create mode 100644 debian/modules/nchan/src/util/nchan_debug.h rename debian/modules/nchan/src/util/{nchan_msgid.c => nchan_msg.c} (65%) rename debian/modules/nchan/src/util/{nchan_msgid.h => nchan_msg.h} (63%) create mode 100644 debian/modules/nchan/src/util/nchan_output_info.c create mode 100644 debian/modules/nchan/src/util/nchan_output_info.h create mode 100644 debian/modules/nchan/src/util/nchan_slist.c create mode 100644 debian/modules/nchan/src/util/nchan_slist.h diff --git a/debian/modules/nchan/README.md b/debian/modules/nchan/README.md index ee43ac9c..152396d0 100644 --- a/debian/modules/nchan/README.md +++ b/debian/modules/nchan/README.md @@ -1,57 +1,56 @@ - + -https://nchan.slact.net +https://nchan.io Nchan is a scalable, flexible pub/sub server for the modern web, built as a module for the [Nginx](http://nginx.org) web server. It can be configured as a standalone server, or as a shim between your application and hundreds, thousands, or millions of live subscribers. It can buffer messages in memory, on-disk, or via [Redis](http://redis.io). All connections are handled asynchronously and distributed among any number of worker processes. It can also scale to many Nginx servers with [Redis](http://redis.io). Messages are [published](#publisher-endpoints) to channels with HTTP `POST` requests or Websocket, and [subscribed](#subscriber-endpoint) also through [Websocket](#websocket), [long-polling](#long-polling), [EventSource](#eventsource) (SSE), old-fashioned [interval polling](#interval-polling), [and](#http-chunked-transfer) [more](#http-multipart-mixed). -In a web browser, you can use Websocket or EventSource directly, or the [NchanSubscriber.js](https://github.com/slact/nchan/blob/master/NchanSubscriber.js) wrapper library. It supports Long-Polling, EventSource, and resumable Websockets, and has a few other added convenience options. +In a web browser, you can use Websocket or EventSource natively, or the [NchanSubscriber.js](https://github.com/slact/nchan.js) wrapper library. It supports Long-Polling, EventSource, and resumable Websockets, and has a few other added convenience options. It's also available on [NPM](https://www.npmjs.com/package/nchan). ## Features - - RESTful, HTTP-native API. - - Supports [Websocket](https://nchan.slact.net/#websocket), [EventSource (Server-Sent Events)](https://nchan.slact.net/#eventsource), [Long-Polling](https://nchan.slact.net/#long-polling) and other HTTP-based subscribers. - - No-repeat, no-loss message delivery guarantees with per-channel configurable message buffers. + - RESTful, HTTP-native [API](#publishing-messages). + - Supports [Websocket](#websocket), [EventSource (Server-Sent Events)](#eventsource), [Long-Polling](#long-polling) and other HTTP-based subscribers. + - Per-channel configurable message buffers with no-repeat, no-loss message delivery guarantees. - Subscribe to [hundreds of channels](#channel-multiplexing) over a single subscriber connection. - - HTTP request [callbacks and hooks](https://nchan.slact.net/details#application-callbacks) for easy integration. - - Introspection with [channel events](https://nchan.slact.net/details#channel-events) and [url for monitoring performance statistics](https://nchan.slact.net/details#nchan_stub_status). - - Fast ephemeral local message storage and optional, slower, persistent storage with [Redis](https://nchan.slact.net/details#connecting-to-a-redis-server). - - Horizontally scalable (using [Redis](https://nchan.slact.net/details#connecting-to-a-redis-server)). - - Highly Available with no single point of failure (using [Redis Cluster](https://nchan.slact.net/details#redis-cluster)). - - + - HTTP request [callbacks and hooks](#hooks-and-callbacks) for easy integration. + - Introspection with [channel events](#channel-events) and [url for monitoring performance statistics](#nchan_stub_status-stats). + - Channel [group](#channel-groups) usage [accounting and limits](#limits-and-accounting). + - Fast, nonblocking [shared-memory local message storage](#memory-storage) and optional, slower, persistent storage with [Redis](#redis). + - Horizontally scalable (using [Redis](#redis)). + - Auto-failover and [high availability](#high-availability) with no single point of failure using [Redis Cluster](#redis-cluster). ## Status and History -The latest Nchan release is v1.0.8 (November 28, 2016) ([changelog](https://nchan.slact.net/changelog)). +The latest Nchan release is 1.2.7 (March 17, 2020) ([changelog](https://nchan.io/changelog)). -The first iteration of Nchan was written in 2009-2010 as the [Nginx HTTP Push Module](https://pushmodule.slact.net), and was vastly refactored into its present state in 2014-2016. The present release is in the **testing** phase. The core features and old functionality are thoroughly tested and stable. Some of the new functionality, especially Redis Cluster may be a bit buggy. +The first iteration of Nchan was written in 2009-2010 as the [Nginx HTTP Push Module](https://pushmodule.slact.net), and was vastly refactored into its present state in 2014-2016. #### Upgrade from Nginx HTTP Push Module -Although Nchan is backwards-compatible with all Push Module configuration directives, some of the more unusual and rarely used settings have been disabled and will be ignored (with a warning). See the [upgrade page](https://nchan.slact.net/upgrade) for a detailed list of changes and improvements, as well as a full list of incompatibilities. +Although Nchan is backwards-compatible with all Push Module configuration directives, some of the more unusual and rarely used settings have been disabled and will be ignored (with a warning). See the [upgrade page](https://nchan.io/upgrade) for a detailed list of changes and improvements, as well as a full list of incompatibilities. ## Does it scale? -benchmarking internal subscriber response times +benchmarking internal subscriber response times Yes it does. Like Nginx, Nchan can easily handle as much traffic as you can throw at it. I've tried to benchmark it, but my benchmarking tools are much slower than Nchan. The data I've gathered is on how long Nchan itself takes to respond to every subscriber after publishing a message -- this excludes TCP handshake times and internal HTTP request parsing. Basically, it measures how Nchan scales assuming all other components are already tuned for scalability. The graphed data are averages of 5 runs with 50-byte messages. -With a well-tuned OS and network stack on commodity server hardware, expect to handle upwards of 300K concurrent subscribers per second at minimal CPU load. Nchan can also be scaled out to multiple Nginx instances using the [Redis storage engine](#nchan_use_redis), and that too can be scaled up beyond a single-point-of-failure by using [Redis Cluster](https://nchan.slact.net/details#using-redis). +With a well-tuned OS and network stack on commodity server hardware, expect to handle upwards of 300K concurrent subscribers per second at minimal CPU load. Nchan can also be scaled out to multiple Nginx instances using the [Redis storage engine](#nchan_use_redis), and that too can be scaled up beyond a single-point-of-failure by using [Redis Cluster](#redis-cluster). -Currently, Nchan's main bottleneck is not CPU load but memory bandwidth. This can be improved significantly in future versions with fewer allocations and better use of contiguous memory pools. Please consider supporting Nchan to speed up the work of memory cache optimization. ## Install #### Download Packages - - [Arch Linux](https://archlinux.org): [nginx-nchan](https://aur.archlinux.org/packages/nginx-nchan/) and [nginx-nchan-git](https://aur.archlinux.org/packages/nginx-nchan-git/) are available in the Arch User Repository. - - Mac OS X: a [homebrew](http://brew.sh) package is available. `brew tap homebrew/nginx; brew install nginx-full --with-nchan-module` - - [Debian](https://www.debian.org/): A dynamic module build for is available in the Debian package repository: [libnginx-mod-nchan](https://packages.debian.org/sid/libnginx-mod-nchan). - Additionally, you can use the pre-built static module packages [nginx-common.deb](https://nchan.slact.net/download/nginx-common.deb) and [nginx-extras.deb](https://nchan.slact.net/download/nginx-extras.deb). Download both and install them with `dpkg -i`, followed by `sudo apt-get -f install`. - - [Ubuntu](http://www.ubuntu.com/): [nginx-common.ubuntu.deb](https://nchan.slact.net/download/nginx-common.ubuntu.deb) and [nginx-extras.ubuntu.deb](https://nchan.slact.net/download/nginx-extras.ubuntu.deb). Download both and install them with `dpkg -i`, followed by `sudo apt-get -f install`. Who knows when Ubuntu will add them to their repository?... - - [Fedora](https://fedoraproject.org): Dynamic module builds for Nginx > 1.10.0 are available: [nginx-mod-nchan.x86_64.rpm](https://nchan.slact.net/download/nginx-mod-nchan.x86-64.rpm), [nginx-mod-nchan.src.rpm](https://nchan.slact.net/download/nginx-mod-nchan.src.rpm). - - A statically compiled binary and associated linux nginx installation files are also [available as a tarball](https://nchan.slact.net/download/nginx-nchan-latest.tar.gz). + - [Arch Linux](https://archlinux.org): [nginx-mod-nchan](https://aur.archlinux.org/packages/nginx-mod-nchan/) and [nginx-mainline-mod-nchan](https://aur.archlinux.org/packages/nginx-mainline-mod-nchan/) are available in the Arch User Repository. + - Mac OS X: a [homebrew](http://brew.sh) package is available. `brew tap denji/nginx; brew install nginx-full --with-nchan-module` + - [Debian](https://www.debian.org/): A dynamic module build is available in the Debian package repository: [libnginx-mod-nchan](https://packages.debian.org/sid/libnginx-mod-nchan). + Additionally, you can use the pre-built static module packages [nginx-common.deb](https://nchan.io/download/nginx-common.deb) and [nginx-extras.deb](https://nchan.io/download/nginx-extras.deb). Download both and install them with `dpkg -i`, followed by `sudo apt-get -f install`. + - [Ubuntu](http://www.ubuntu.com/): [nginx-common.ubuntu.deb](https://nchan.io/download/nginx-common.ubuntu.deb) and [nginx-extras.ubuntu.deb](https://nchan.io/download/nginx-extras.ubuntu.deb). Download both and install them with `dpkg -i`, followed by `sudo apt-get -f install`. Who knows when Ubuntu will add Nchan to their repository?... + - [Fedora](https://fedoraproject.org): Dynamic module builds for Nginx > 1.10.0 are available: [nginx-mod-nchan.x86_64.rpm](https://nchan.io/download/nginx-mod-nchan.x86-64.rpm), [nginx-mod-nchan.src.rpm](https://nchan.io/download/nginx-mod-nchan.src.rpm). + - [Heroku](https://heroku.com): A buildpack for compiling Nchan into Nginx is available: [nchan-buildpack](https://github.com/andjosh/nchan-buildpack). A one-click, readily-deployable app is also available: [nchan-heroku](https://github.com/andjosh/nchan-heroku). + - A statically compiled binary and associated linux nginx installation files are also [available as a tarball](https://nchan.io/download/nginx-nchan-latest.tar.gz). #### Build From Source @@ -62,7 +61,7 @@ Grab the latest copy of Nginx from [nginx.org](http://nginx.org). Grab the lates If you're using Nginx > 1.9.11, you can build Nchan as a [dynamic module](https://www.nginx.com/blog/dynamic-modules-nginx-1-9-11/) with `--add-dynamic-module=path/to/nchan` -Run `make`, `make install`, and enjoy. (Caution, contents may be hot.) +Run `make`, then `make install`. ## Getting Started @@ -87,11 +86,11 @@ http { } ``` -You can now publish messages to channels by `POST`ing data to `/sub?id=channel_id` , and subscribe by pointing Websocket, EventSource, or [NchanSubscriber.js](https://github.com/slact/nchan/blob/master/NchanSubscriber.js) to `sub/?id=channel_id`. It's that simple. +You can now publish messages to channels by `POST`ing data to `/pub?id=channel_id` , and subscribe by pointing Websocket, EventSource, or [NchanSubscriber.js](https://github.com/slact/nchan.js) to `sub/?id=channel_id`. It's that simple. But Nchan is very flexible and highly configurable. So, of course, it can get a lot more complicated... -## Conceptual Overview +### Conceptual Overview The basic unit of most pub/sub solutions is the messaging *channel*. Nchan is no different. Publishers send messages to channels with a certain *channel id*, and subscribers subscribed to those channels receive them. Some number of messages may be buffered for a time in a channel's message buffer before they are deleted. Pretty simple, right? @@ -121,15 +120,26 @@ http { The above maps requests to the URI `/sub` onto the channel `foobar`'s *subscriber endpoint* , and similarly `/pub` onto channel `foobar`'s *publisher endpoint*. -#### Publisher Endpoints +## Publisher Endpoints Publisher endpoints are Nginx config *locations* with the [*`nchan_publisher`*](#nchan_publisher) directive. Messages can be published to a channel by sending HTTP **POST** requests with the message contents to the *publisher endpoint* locations. You can also publish messages through a **Websocket** connection to the same location. +```nginx + location /pub { + #example publisher location + nchan_publisher; + nchan_channel_id foo; + nchan_channel_group test; + nchan_message_buffer_length 50; + nchan_message_timeout 5m; + } +``` + -##### Publishing Messages +### Publishing Messages Requests and websocket messages are responded to with information about the channel at time of message publication. Here's an example from publishing with `curl`: @@ -147,7 +157,7 @@ The response can be in plaintext (as above), JSON, or XML, based on the request' ```console > curl --request POST --data "test message" -H "Accept: text/json" http://127.0.0.2:80/pub - {"messages": 6, "requested": 55, "subscribers": 0, "last_message_id": "1450755317:0" } + {"messages": 5, "requested": 18, "subscribers": 0, "last_message_id": "1450755280:0" } ``` Websocket publishers also receive the same responses when publishing, with the encoding determined by the *`Accept`* header present during the handshake. @@ -156,7 +166,7 @@ The response code for an HTTP request is *`202` Accepted* if no subscribers are Metadata can be added to a message when using an HTTP POST request for publishing. A `Content-Type` header will be associated as the message's content type (and output to Long-Poll, Interval-Poll, and multipart/mixed subscribers). A `X-EventSource-Event` header can also be used to associate an EventSource `event:` line value with a message. -##### Other Publisher Endpoint Actions +### Other Publisher Endpoint Actions **HTTP `GET`** requests return channel information without publishing a message. The response code is `200` if the channel exists, and `404` otherwise: ```console @@ -171,15 +181,32 @@ Metadata can be added to a message when using an HTTP POST request for publishin **HTTP `DELETE`** requests delete a channel and end all subscriber connections. Like the `GET` requests, this returns a `200` status response with channel info if the channel existed, and a `404` otherwise. -For an in-depth explanation of how settings are applied to channels from publisher locations, see the [details page](https://nchan.slact.net/details#publisher-endpoint-configs). +### How Channel Settings Work + +*A channel's configuration is set to the that of its last-used publishing location.* +So, if you want a channel to behave consistently, and want to publish to it from multiple locations, *make sure those locations have the same configuration*. -#### Subscriber Endpoints +You can also can use differently-configured publisher locations to dynamically update a channel's message buffer settings. This can be used to erase messages or to scale an existing channel's message buffer as desired. + +## Subscriber Endpoints Subscriber endpoints are Nginx config *locations* with the [*`nchan_subscriber`*](#nchan_subscriber) directive. Nchan supports several different kinds of subscribers for receiving messages: [*Websocket*](#websocket), [*EventSource*](#eventsource) (Server Sent Events), [*Long-Poll*](#long-polling), [*Interval-Poll*](#interval-polling). [*HTTP chunked transfer*](#http-chunked-transfer), and [*HTTP multipart/mixed*](#http-multipart-mixed). -- ##### Long-Polling +```nginx + location /sub { + #example subscriber location + nchan_subscriber; + nchan_channel_id foo; + nchan_channel_group test; + nchan_subscriber_first_message oldest; + } +``` + + + +- ### Long-Polling The tried-and-true server-push method supported by every browser out there. Initiated by sending an HTTP `GET` request to a channel subscriber endpoint. The long-polling subscriber walks through a channel's message queue via the built-in cache mechanism of HTTP clients, namely with the "`Last-Modified`" and "`Etag`" headers. Explicitly, to receive the next message for given a long-poll subscriber response, send a request with the "`If-Modified-Since`" header set to the previous response's "`Last-Modified`" header, and "`If-None-Match`" likewise set to the previous response's "`Etag`" header. @@ -187,15 +214,16 @@ Nchan supports several different kinds of subscribers for receiving messages: [* A message's associated content type, if present, will be sent to this subscriber with the `Content-Type` header. -- ##### Interval-Polling +- ### Interval-Polling Works just like long-polling, except if the requested message is not yet available, immediately responds with a `304 Not Modified`. - There is no way to differentiate between long-poll and interval-poll subscriber requests, so long-polling must be disabled for a subscriber location if you wish to use interval-polling. + Nchan cannot automatically distinguish between long-poll and interval-poll subscriber requests, so long-polling must be disabled for a subscriber location if you wish to use interval-polling. -- ##### Websocket +- ### Websocket Bidirectional communication for web browsers. Part of the [HTML5 spec](http://www.w3.org/TR/2014/REC-html5-20141028/single-page.html). Nchan supports the latest protocol version 13 ([RFC 6455](https://tools.ietf.org/html/rfc6455)). Initiated by sending a websocket handshake to the desired subscriber endpoint location. - If the websocket connection is closed by the server, the `close` frame will contain the HTTP response code and status line describing the reason for closing the connection. Server-initiated keep-alive pings can be configured with the [`nchan_websocket_ping_interval`](#nchan_websocket_ping_interval) config directive. Websocket extensions are not yet supported. - Messages published through a websocket connection can be forwarded to an upstream application with the [`nchan_publisher_upstream_request`](#nchan_publisher_upstream_request) config directive. + If the websocket connection is closed by the server, the `close` frame will contain the HTTP response code and status line describing the reason for closing the connection. Server-initiated keep-alive pings can be configured with the [`nchan_websocket_ping_interval`](#nchan_websocket_ping_interval) config directive. + Messages are delivered to subscribers in `text` websocket frames, except if a message's `content-type` is "`application/octet-stream`" -- then it is delivered in a `binary` frame. +
Websocket subscribers can use the custom `ws+meta.nchan` subprotocol to receive message metadata with messages, making websocket connections resumable. Messages received with this subprotocol are of the form 
   id: message_id
@@ -204,9 +232,24 @@ Nchan supports several different kinds of subscribers for receiving messages: [*
   message_data
The `content-type:` line may be omitted. +
+ #### Websocket Publisher + Messages published through a websocket connection can be forwarded to an upstream application with the [`nchan_publisher_upstream_request`](#nchan_publisher_upstream_request) config directive. + Messages published in a binary frame are automatically given the `content-type` "`application/octet-stream`". + #### Permessage-deflate + Nchan version 1.1.8 and above supports the [permessage-deflate protocol extension](https://tools.ietf.org/html/rfc7692). Messages are deflated once when they are published, and then can be broadcast to any number of compatible websocket subscribers. Message deflation is enabled by setting the [`nchan_deflate_message_for_websocket on;`](#nchan_deflate_message_for_websocket) directive in a publisher location. +
+ The deflated data is stored alongside the original message in memory, or, if large enough, on disk. This means more [shared memory](#nchan_shared_memory_size) is necessary when using `nchan_deflate_message_for_websocket`. +
+ Deflation parameters (speed, memory use, strategy, etc.), can be tweaked using the [`nchan_permessage_deflate_compression_window`](#nchan_permessage_deflate_compression_window), [`nchan_permessage_deflate_compression_level`](#nchan_permessage_deflate_compression_level), + [`nchan_permessage_deflate_compression_strategy`](#nchan_permessage_deflate_compression_strategy), and + [`nchan_permessage_deflate_compression_window`](#nchan_permessage_deflate_compression_window) settings. +
+ Nchan also supports the (deprecated) [perframe-deflate extension](https://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-06) still in use by Safari as `x-webkit-perframe-deflate`. +
-- ##### EventSource +- ### EventSource Also known as [Server-Sent Events](https://en.wikipedia.org/wiki/Server-sent_events) or SSE, it predates Websockets in the [HTML5 spec](http://www.w3.org/TR/2014/REC-html5-20141028/single-page.html), and is a [very simple protocol](http://www.w3.org/TR/eventsource/#event-stream-interpretation). Initiated by sending an HTTP `GET` request to a channel subscriber endpoint with the "`Accept: text/event-stream`" header. Each message `data: ` segment will be prefaced by the message `id: `. @@ -217,7 +260,7 @@ Nchan supports several different kinds of subscribers for receiving messages: [* A message's associated `event` type, if present, will be sent to this subscriber with the `event:` line. -- ##### HTTP [multipart/mixed](http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html#z0) +- ### HTTP [multipart/mixed](http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html#z0) The `multipart/mixed` MIMEtype was conceived for emails, but hey, why not use it for HTTP? It's easy to parse and includes metadata with each message. Initiated by including an `Accept: multipart/mixed` header. The response headers and the unused "preamble" portion of the response body are sent right away, with the boundary string generated randomly for each subscriber. Each subsequent message will be sent as one part of the multipart message, and will include the message time and tag (`Last-Modified` and `Etag`) as well as the optional `Content-Type` headers. @@ -225,11 +268,11 @@ Nchan supports several different kinds of subscribers for receiving messages: [* A message's associated content type, if present, will be sent to this subscriber with the `Content-Type` header. -- ##### HTTP Raw Stream +- ### HTTP Raw Stream A simple subscription method similar to the [streaming subscriber](https://github.com/wandenberg/nginx-push-stream-module/blob/master/docs/directives/subscribers.textile#push_stream_subscriber) of the [Nginx HTTP Push Stream Module](https://github.com/wandenberg/nginx-push-stream-module). Messages are appended to the response body, separated by a newline or configurable by `nchan_subscriber_http_raw_stream_separator`. -- ##### HTTP [Chunked Transfer](http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1) +- ### HTTP [Chunked Transfer](http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1) This subscription method uses the `chunked` `Transfer-Encoding` to receive messages. Initiated by explicitly including `chunked` in the [`TE` header](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.39): `TE: chunked` (or `TE: chunked;q=??` where the qval > 0) @@ -237,9 +280,7 @@ Nchan supports several different kinds of subscribers for receiving messages: [* Unlike the other subscriber types, the `chunked` subscriber cannot be used with http/2 because it dissallows chunked encoding. - - -#### PubSub Endpoint +## PubSub Endpoint PubSub endpoints are Nginx config *locations* with the [*`nchan_pubsub`*](#nchan_pubsub) directive. @@ -249,17 +290,19 @@ requests as subscribers, and all HTTP `POST` as publishers. One simple use case ```nginx location = /pubsub { nchan_pubsub; - nchan_channel_id foobar; + nchan_channel_id foo; + nchan_channel_group test; } ``` -A more applicable setup may set different publisher and subscriber channel ids: +A more interesting setup may set different publisher and subscriber channel ids: ```nginx location = /pubsub { nchan_pubsub; nchan_publisher_channel_id foo; nchan_subscriber_channel_id bar; + nchan_channel_group test; } ``` @@ -267,9 +310,9 @@ Here, subscribers will listen for messages on channel `foo`, and publishers will -### The Channel ID +## The Channel ID -So far the examples have used static channel ids, which is not very useful in practice. It can be set to any nginx *variable*, such as a querystring argument, a header value, or a part of the location url: +So far the examples have used static channel ids, which is not very useful. In practice, the channel id can be set to any nginx *variable*, such as a querystring argument, a header value, or a part of the location url: ```nginx location = /sub_by_ip { @@ -294,9 +337,11 @@ So far the examples have used static channel ids, which is not very useful in pr } ``` +I recommend using the last option, a channel id derived from the request URL via a regular expression. It makes things nice and RESTful. + -#### Channel Multiplexing +### Channel Multiplexing With channel multiplexing, subscribers can subscribe to up to 255 channels per connection. Messages published to all the specified channels will be delivered in-order to the subscriber. There are two ways to enable multiplexing: @@ -325,68 +370,626 @@ For more than 7 channels, `nchan_channel_id_split_delimiter` can be used to spli } ``` -Publishing to multiple channels with a single request is also possible, with similar configuration: +It is also possible to publish to multiple channels with a single request as well as delete multiple channels with a single request, with similar configuration: ```nginx location ~ /multipub/(\w+)/(\w+)$ { nchan_publisher; nchan_channel_id "$1" "$2" "another_channel"; + #POST /multipub/foo/bar will publish to: + # channels 'foo', 'bar', 'another_channel' + #DELETE /multipub/foo/bar will delete: + # channels 'foo', 'bar', 'another_channel' } ``` -`DELETE` requests to a multiplexed channel broadcast the deletion to each of the channels it multiplexes, deletes all their messages and kicks out all clients subscribed to any of the channel ids. +When a channel is deleted, all of its messages are deleted, and all of its subscribers' connection are closed -- including ones subscribing through a multiplexed location. For example, suppose a subscriber is subscribed to channels "foo" and "bar" via a single multiplexed connection. If "foo" is deleted, the connection is closed, and the subscriber therefore loses the "bar" subscription as well. -See the [details page](https://nchan.slact.net/details#securing-channels) for more information about using good IDs and keeping channels secure. +See the [Channel Security](#securing-channels) section about using good IDs and keeping private channels secure. +### Channel Groups + +Channels can be associated with groups to avoid channel ID conflicts: + +```nginx + location /test_pubsub { + nchan_pubsub; + nchan_channel_group "test"; + nchan_channel_id "foo"; + } + + location /pubsub { + nchan_pubsub; + nchan_channel_group "production"; + nchan_channel_id "foo"; + #same channel id, different channel group. Thus, different channel. + } + + location /flexgroup_pubsub { + nchan_pubsub; + nchan_channel_group $arg_group; + nchan_channel_id "foo"; + #group can be set with request variables too + } +``` + +#### Limits and Accounting + +Groups can be used to track aggregate channel usage, as well as set limits on the number of channels, subscribers, stored messages, memory use, etc: + +```nginx + #enable group accounting + nchan_channel_group_accounting on; + + location ~ /pubsub/(\w+)$ { + nchan_pubsub; + nchan_channel_group "limited"; + nchan_channel_id $1; + } + + location ~ /prelimited_pubsub/(\w+)$ { + nchan_pubsub; + nchan_channel_group "limited"; + nchan_channel_id $1; + nchan_group_max_subscribers 100; + nchan_group_max_messages_memory 50M; + } + + location /group { + nchan_channel_group limited; + nchan_group_location; + nchan_group_max_channels $arg_max_channels; + nchan_group_max_messages $arg_max_messages; + nchan_group_max_messages_memory $arg_max_messages_mem; + nchan_group_max_messages_disk $arg_max_messages_disk; + nchan_group_max_subscribers $arg_max_subs; + } +``` + +Here, `/group` is an `nchan_group_location`, which is used for accessing and modifying group data. To get group data, send a `GET` request to a `nchan_group_location`: + +```sh +> curl http://localhost/group + +channels: 10 +subscribers: 0 +messages: 219 +shared memory used by messages: 42362 bytes +disk space used by messages: 0 bytes +limits: + max channels: 0 + max subscribers: 0 + max messages: 0 + max messages shared memory: 0 + max messages disk space: 0 +``` + +By default, the data is returned in human-readable plaintext, but can also be formatted as JSON, XML, or YAML: + +```sh +> curl -H "Accept: text/json" http://localhost/group + +{ + "channels": 21, + "subscribers": 40, + "messages": 53, + "messages_memory": 19941, + "messages_disk": 0, + "limits": { + "channels": 0, + "subscribers": 0, + "messages": 0, + "messages_memory": 0, + "messages_disk": 0 + } +} +``` + +The data in the response are for the single Nchan instance only, regardless of whether Redis is used. A limit of 0 means 'unlimited'. + +Limits can be set per-location, as with the above `/prelimited_pubsub/...` location, or with a POST request to the `nchan_group_location`: +```sh +> curl -X POST "http://localhost/group?max_channels=15&max_subs=1000&max_messages_disk=0.5G" + +channels: 0 +subscribers: 0 +messages: 0 +shared memory used by messages: 0 bytes +disk space used by messages: 0 bytes +limits: + max channels: 15 + max subscribers: 1000 + max messages: 0 + max messages shared memory: 0 + max messages disk space: 536870912 + +``` + +Limits are only applied locally, regardless of whether Redis is enabled. +If a publisher or subscriber request exceeds a group limit, Nchan will respond to it with a `403 Forbidden` response. + + + +## Hooks and Callbacks + + + +### Request Authorization + +This feature, configured with [`nchan_authorize_request`](#nchan_authorize_request), behaves just like the Nginx [http_auth_request module](http://nginx.org/en/docs/http/ngx_http_auth_request_module.html#auth_request_set). + +Consider the configuration: +```nginx + upstream my_app { + server 127.0.0.1:8080; + } + location = /auth { + proxy_pass http://my_app/pubsub_authorize; + proxy_pass_request_body off; + proxy_set_header Content-Length ""; + proxy_set_header X-Subscriber-Type $nchan_subscriber_type; + proxy_set_header X-Publisher-Type $nchan_publisher_type; + proxy_set_header X-Prev-Message-Id $nchan_prev_message_id; + proxy_set_header X-Channel-Id $nchan_channel_id; + proxy_set_header X-Original-URI $request_uri; + proxy_set_header X-Forwarded-For $remote_addr; + } + + location ~ /pubsub/auth/(\w+)$ { + nchan_channel_id $1; + nchan_authorize_request /auth; + nchan_pubsub; + nchan_channel_group test; + } +``` + +Here, any request to the location `/pubsub/auth/<...>` will need to be authorized by your application (`my_app`). Nginx will generate a `GET /pubsub_authorize` request to the application, with additional headers set by the `proxy_set_header` directives. Note that Nchan-specific variables are available for this authorization request. Once your application receives this request, it should decide whether or not to authorize the subscriber. This can be done based on a forwarded session cookie, IP address, or any set of parameters of your choosing. If authorized, it should respond with an empty `200 OK` response. +All non-`2xx` response codes (such as `403 Forbidden`) are intepreted as authorization failures. In this case, the failing response is proxied to the client. + +Note that Websocket and EventSource clients will only try to authorize during the initial handshake request, whereas Long-Poll and Interval-Poll subscribers will need to be authorized each time they request the next message, which may flood your application with too many authorization requests. + + + +### Subscriber Presence + +Subscribers can notify an application when they have subscribed and unsubscribed to a channel using the [`nchan_subscribe_request`](#nchan_subscribe_request) +and [`nchan_unsubscribe_request`](#nchan_unsubscribe_request) settings. +These should point to Nginx locations configured to forward requests to an upstream proxy (your application): + +```nginx + location ~ /sub/(\w+)$ { + nchan_channel_id $1; + nchan_subscribe_request /upstream/sub; + nchan_unsubscribe_request /upstream/unsub; + nchan_subscriber; + nchan_channel_group test; + } + + location = /upstream/unsub { + proxy_pass http://127.0.0.1:9292/unsub; + proxy_ignore_client_abort on; #!!!important!!!! + proxy_set_header X-Subscriber-Type $nchan_subscriber_type; + proxy_set_header X-Channel-Id $nchan_channel_id; + proxy_set_header X-Original-URI $request_uri; + } + location = /upstream/sub { + proxy_pass http://127.0.0.1:9292/sub; + proxy_set_header X-Subscriber-Type $nchan_subscriber_type; + proxy_set_header X-Message-Id $nchan_message_id; + proxy_set_header X-Channel-Id $nchan_channel_id; + proxy_set_header X-Original-URI $request_uri; + } +``` + +In order for `nchan_unsubscribe_request` to work correctly, the location it points to must have `proxy_ignore_client_abort on;`. Otherwise, suddenly aborted subscribers may not trigger an unsubscribe request. + +Note that the subscribe/unsubscribe hooks are **disabled for long-poll and interval-poll clients**, because they would trigger these hooks each time they receive a message. + + + +### Message Forwarding + +Messages can be forwarded to an upstream application before being published using the `nchan_publisher_upstream_request` setting: + +```nginx + location ~ /pub/(\w+)$ { + #publisher endpoint + nchan_channel_id $1; + nchan_pubsub; + nchan_publisher_upstream_request /upstream_pub; + } + + location = /upstream_pub { + proxy_pass http://127.0.0.1:9292/pub; + proxy_set_header X-Publisher-Type $nchan_publisher_type; + proxy_set_header X-Prev-Message-Id $nchan_prev_message_id; + proxy_set_header X-Channel-Id $nchan_channel_id; + proxy_set_header X-Original-URI $request_uri; + } +``` +With this configuration, incoming messages are first `POST`ed to `http://127.0.0.1:9292/pub`. +The upstream response code determines how publishing will proceed: + - `304 Not Modified` publishes the message as received, without modifification. + - `204 No Content` discards the message + - `200 OK` is used for modifying the message. Instead of the original incoming message, the message contained in this HTTP response is published. + +There are two main use cases for `nchan_publisher_upstream_request`: forwarding incoming data from Websocket publishers to an application, and mutating incoming messages. + + + ## Storage Nchan can stores messages in memory, on disk, or via Redis. Memory storage is much faster, whereas Redis has additional overhead as is considerably slower for publishing messages, but offers near unlimited scalability for broadcast use cases with far more subscribers than publishers. - - ### Memory Storage -This storage method uses a segment of shared memory to store messages and channel data. Large messages as determined by Nginx's caching layer are stored on-disk. The size of the memory segment is configured with `nchan_max_reserved_memory`. Data stored here is not persistent, and is lost if Nginx is restarted or reloaded. +This default storage method uses a segment of shared memory to store messages and channel data. Large messages as determined by Nginx's caching layer are stored on-disk. The size of the memory segment is configured with `nchan_shared_memory_size`. Data stored here is not persistent, and is lost if Nginx is restarted or reloaded. ### Redis -Nchan can also store messages and channels on a Redis server, or in a Redis cluster. To use a Redis server, set `nchan_use_redis on;` and set the server url with `nchan_redis_url`. These two settings are inheritable by nested locations, so it is enough to set them within an `http { }` block to enable Redis for all Nchan locations in that block. Different locations can also use different Redis servers. +[Redis](http://redis.io) can be used to add **data persistence** and **horizontal scalability**, **failover** and **high availability** to your Nchan setup. + + -To use a Redis Cluster, the Redis servers acting as cluster nodes need to be configured in an `upstream { }` block: +#### Connecting to a Redis Server +To connect to a single Redis master server, use an `upstream` with `nchan_redis_server` and `nchan_redis_pass` settings: ```nginx +http { + upstream my_redis_server { + nchan_redis_server 127.0.0.1; + } + server { + listen 80; + + location ~ /redis_sub/(\w+)$ { + nchan_subscriber; + nchan_channel_id $1; + nchan_redis_pass my_redis_server; + } + location ~ /redis_pub/(\w+)$ { + nchan_redis_pass my_redis_server; + nchan_publisher; + nchan_channel_id $1; + } + } +} +``` + +All servers with the above configuration connecting to the same redis server share channel and message data. + +Channels that don't use Redis can be configured side-by-side with Redis-backed channels, provided the endpoints never overlap. (This can be ensured, as above, by setting separate `nchan_channel_group`s.). Different locations can also connect to different Redis servers. + +Nchan can work with a single Redis master. It can also auto-discover and use Redis slaves to balance PUBSUB traffic. + + + +#### Redis Cluster +Nchan also supports using Redis Cluster, which adds scalability via sharding channels among cluster nodes. Redis cluster also provides **automatic failover**, **high availability**, and eliminates the single point of failure of one shared Redis server. It is configred and used like so: + +```nginx +http { upstream redis_cluster { nchan_redis_server redis://127.0.0.1:7000; nchan_redis_server redis://127.0.0.1:7001; nchan_redis_server redis://127.0.0.1:7002; + # you don't need to specify all the nodes, they will be autodiscovered + # however, it's recommended that you do specify at least a few master nodes. } + server { + listen 80; + + location ~ /sub/(\w+)$ { + nchan_subscriber; + nchan_channel_id $1; + nchan_redis_pass redis_cluster; + } + location ~ /pub/(\w+)$ { + nchan_publisher; + nchan_channel_id $1; + nchan_redis_pass redis_cluster; + } + } +} ``` -It is best to specify all master cluster nodes, but this is not required -- as long as Nchan can connect to at least 1 node, it will discover and connect to the whole cluster. + + +##### High Availability +Redis Cluster connections are designed to be resilient and try to recover from errors. Interrupted connections will have their commands queued until reconnection, and Nchan will publish any messages it successfully received while disconnected. Nchan is also adaptive to cluster modifications. It will add new nodes and remove them as needed. + +All Nchan servers sharing a Redis server or cluster should have their times synchronized (via ntpd or your favorite ntp daemon). Failure to do so may result in missed or duplicate messages. + +#### Tweaks and Optimizations + +As of version 1.2.0, Nchan uses Redis slaves to load-balance PUBSUB traffic. By default, there is an equal chance that a channel's PUBSUB subscription will go to any master or slave. The [`nchan_redis_subscribe_weights`](#nchan_redis_subscribe_weights) setting is available to fine-tune this load-balancing. + +Also from 1.2.0 onward, [`nchan_redis_optimize_target`](#nchan_redis_optimize_target) can be used to prefer optimizing Redis slaves for CPU or bandwidth. For heavy publishing loads, the tradeoff is very roughly 35% replication bandwidth per slave to 30% CPU load on slaves. + +## Introspection + +There are several ways to see what's happening inside Nchan. These are useful for debugging application integration and for measuring performance. -To use Redis Cluster in an Nchan location, use the `nchan_redis_pass` setting: +### Channel Events + +Channel events are messages automatically published by Nchan when certain events occur in a channel. These are very useful for debugging the use of channels. However, they carry a significant performance overhead and should be used during development, and not in production. + +Channel events are published to special 'meta' channels associated with normal channels. Here's how to configure them: ```nginx - location ~ /pubsub/(\w+)$ { +location ~ /pubsub/(.+)$ { + nchan_pubsub; + nchan_channel_id $1; + nchan_channel_events_channel_id $1; #enables channel events for this location +} + +location ~ /channel_events/(.+) { + #channel events subscriber location + nchan_subscriber; + nchan_channel_group meta; #"meta" is a SPECIAL channel group + nchan_channel_id $1; +} +``` + +Note the `/channel_events/...` location has a *special* `nchan_channel_group`, `meta`. This group is reserved for accessing "channel events channels", or"metachannels". + +Now, say I subscribe to `/channel_events/foo` I will refer to this as the channel events subscriber. + +Let's see what this channel events subscriber receives when I publish messages to + +Subscribing to `/pubsub/foo` produces the channel event +``` +subscriber_enqueue foo +``` + +Publishing a message to `/pubsub/foo`: +``` +channel_publish foo +``` + +Unsubscribing from `/pubsub/foo`: +``` +subscriber_dequeue foo +``` + +Deleting `/pubsub/foo` (with HTTP `DELETE /pubsub/foo`): +``` +channel_delete foo +``` + +The event string itself is configirable with [nchan_channel_event_string](#nchan_channel_event_string). By default, it is set to `$nchan_channel_event $nchan_channel_id`. +This string can use any Nginx and [Nchan variables](/#variables). + + +### nchan_stub_status Stats + +Like Nginx's [stub_status](https://nginx.org/en/docs/http/ngx_http_stub_status_module.html), +`nchan_stub_status` is used to get performance metrics. + +```nginx + location /nchan_stub_status { + nchan_stub_status; + } +``` + +Sending a GET request to this location produces the response: + +```text +total published messages: 1906 +stored messages: 1249 +shared memory used: 1824K +channels: 80 +subscribers: 90 +redis pending commands: 0 +redis connected servers: 0 +total interprocess alerts received: 1059634 +interprocess alerts in transit: 0 +interprocess queued alerts: 0 +total interprocess send delay: 0 +total interprocess receive delay: 0 +nchan version: 1.1.5 +``` + +Here's what each line means, and how to interpret it: + - `total published messages`: Number of messages published to all channels through this Nchan server. + - `stored messages`: Number of messages currently buffered in memory + - `shared memory used`: Total shared memory used for buffering messages, storing channel information, and other purposes. This value should be comfortably below `nchan_shared_memory_size`. + - `channels`: Number of channels present on this Nchan server. + - `subscribers`: Number of subscribers to all channels on this Nchan server. + - `redis pending commands`: Number of commands sent to Redis that are awaiting a reply. May spike during high load, especially if the Redis server is overloaded. Should tend towards 0. + - `redis connected servers`: Number of redis servers to which Nchan is currently connected. + - `total interprocess alerts received`: Number of interprocess communication packets transmitted between Nginx workers processes for Nchan. Can grow at 100-10000 per second at high load. + - `interprocess alerts in transit`: Number of interprocess communication packets in transit between Nginx workers. May be nonzero during high load, but should always tend toward 0 over time. + - `interprocess queued alerts`: Number of interprocess communication packets waiting to be sent. May be nonzero during high load, but should always tend toward 0 over time. + - `total interprocess send delay`: Total amount of time interprocess communication packets spend being queued if delayed. May increase during high load. + - `total interprocess receive delay`: Total amount of time interprocess communication packets spend in transit if delayed. May increase during high load. + - `nchan_version`: current version of Nchan. Available for version 1.1.5 and above. + +Additionally, when there is at least one `nchan_stub_status` location, the following Nginx variables are available: + - `$nchan_stub_status_total_published_messages` + - `$nchan_stub_status_stored_messages` + - `$nchan_stub_status_shared_memory_used` + - `$nchan_stub_status_channels` + - `$nchan_stub_status_subscribers` + - `$nchan_stub_status_redis_pending_commands` + - `$nchan_stub_status_redis_connected_servers` + - `$nchan_stub_status_total_ipc_alerts_received` + - `$nchan_stub_status_ipc_queued_alerts` + - `$nchan_stub_status_total_ipc_send_delay` + - `$nchan_stub_status_total_ipc_receive_delay` + + +## Securing Channels + +### Securing Publisher Endpoints +Consider the use case of an application where authenticated users each use a private, dedicated channel for live updates. The configuration might look like this: + +```nginx +http { + server { + #available only on localhost + listen 127.0.0.1:8080; + location ~ /pub/(\w+)$ { + nchan_publisher; + nchan_channel_group my_app_group; + nchan_channel_id $1; + } + } + + server { + #available to the world + listen 80; + + location ~ /sub/(\w+)$ { + nchan_subscriber; + nchan_channel_group my_app_group; + nchan_channel_id $1; + } + } +} + +``` + +Here, the subscriber endpoint is available on a public-facing port 80, and the publisher endpoint is only available on localhost, so can be accessed only by applications residing on that machine. Another way to limit access to the publisher endpoint is by using the allow/deny settings: + +```nginx + + server { + #available to the world + listen 80; + location ~ /pub/(\w+)$ { + allow 127.0.0.1; + deny all; + nchan_publisher; + nchan_channel_group my_app_group; + nchan_channel_id $1; + } +``` + +Here, only the local IP 127.0.0.1 is allowed to use the publisher location, even though it is defined in a non-localhost server block. + +### Keeping a Channel Private + +A Channel ID that is meant to be private should be treated with the same care as a session ID token. Considering the above use case of one-channel-per-user, how can we ensure that only the authenticated user, and no one else, is able to access his channel? + +First, if you intend on securing the channel contents, you must use TLS/SSL: + +```nginx +http { + server { + #available only on localhost + listen 127.0.0.1:8080; + #...publisher endpoint config + } + server { + #available to the world + listen 443 ssl; + #SSL config goes here + location ~ /sub/(\w+)$ { + nchan_subscriber; + nchan_channel_group my_app_group; + nchan_channel_id $1; + } + } +} +``` + +Now that you have a secure connection between the subscriber client and the server, you don't need to worry about the channel ID or messages being passively intercepted. This is a minimum requirement for secure message delivery, but it is not sufficient. + +You must also take care to do at least one of the following: + - [Generate good, high-entropy Channel IDs](#good-ids). + - [Authorize all subscribers with the `nchan_authorize_request` config directive](#request-authorization). + - [Authorize subscribers and hide channel IDs with the "`X-Accel-Redirect`" mechanism](#x-accel-redirect). + +#### Good IDs + +An ID that can be guessed is an ID that can be hijacked. If you are not authenticating subscribers (as described below), a channel ID should be impossible to guess. Use at least 128 bits of entropy to generate a random token, associate it with the authenticated user, and share it only with the user's client. Do not reuse tokens, just as you would not reuse session IDs. + +#### X-Accel-Redirect + +This feature uses the [X-Accel feature](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel) of Nginx upstream proxies to perform an internal request to a subscriber endpoint. +It allows a subscriber client to be authenticated by your application, and then redirected by nginx internally to a location chosen by your appplication (such as a publisher or subscriber endpoint). This makes it possible to have securely authenticated clients that are unaware of the channel id they are subscribed to. + +Consider the following configuration: +```nginx +upstream upstream_app { + server 127.0.0.1:8080; +} + +server { + listen 80; + + location = /sub_upstream { + proxy_pass http://upstream_app/subscriber_x_accel_redirect; + proxy_set_header X-Forwarded-For $remote_addr; + } + + location ~ /sub/internal/(\w+)$ { + internal; #this location only accessible for internal nginx redirects + nchan_subscriber; nchan_channel_id $1; - nchan_pubsub; - nchan_redis_pass redis_cluster; + nchan_channel_group test; } +} +``` +As commented, `/sub/internal/` is inaccessible from the outside: +```console +> curl -v http://127.0.0.1/sub/internal/foo + + < HTTP/1.1 404 Not Found + < Server: nginx/1.9.5 + < + + 404 Not Found + +

404 Not Found

+
nginx/1.9.5
+ + ``` -Note that `nchan_redis_pass` implies `nchan_use_redis on;`, and that this setting is *not* inherited by nested locations. +But if a request is made to `/sub_upstream`, it gets forwarded to your application (`my_app`) on port 8080 with the url `/subscriber_x_accel_redirect`. +Note that you can set any forwarded headers here like any [`proxy_pass`](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass) Nginx location, +but unlike the case with `nchan_authorize_request`, Nchan-specific variables are not available. -When connecting several Nchan servers to the same Redis server (or cluster), the servers **must have their times synced up**. Failure to do so may result in missing and duplicated messages. +Now, your application must be set up to handle the request to `/subscriber_x_accel_redirect`. You should make sure the client is properly authenticated (maybe using a session cookie), and generate an associated channel id. If authentication fails, respond with a normal `403 Forbidden` response. You can also pass extra information about the failure in the response body and headers. -See the [details page](https://nchan.slact.net/details#using-redis) for more information on using Redis. +If your application successfully authenticates the subscriber request, you now need to instruct Nginx to issue an internal redirect to `/sub/internal/my_channel_id`. +This is accomplished by responding with an empty `200 OK` response that includes two headers: +- `X-Accel-Redirect: /sub/internal/my_channel_id` +- `X-Accel-Buffering: no` - +In the presence of these headers, Nginx will not forward your app's response to the client, and instead will *internally* redirect to `/sub/internal/my_channel_id`. +This will behave as if the client had requested the subscriber endpoint location directly. + +Thus using X-Accel-Redirect it is possible to both authenticate all subscribers *and* keep channel IDs completely hidden from subscribers. + +This method is especially useful for EventSource and Websocket subscribers. Long-Polling subscribers will need to be re-authenticated for every new message, which may flood your application with too many authentication requests. + +### Revoking Channel Authorization + +In some cases, you may want to revoke a particular subscriber's authorization for a given channel (e.g., if the user's permissions are changed). If the channel is unique to the subscriber, this is simply accomplished by deleting the channel. The same can be achieved for shared channels by subscribing each subscriber to both the shared channel and a subscriber-specific channel via a multiplexed connection. Deleting the subscriber-specific channel will terminate the subscriber''s connection, thereby also terminating their subscription to the shared channel. Consider the following configuration: + +```nginx +location ~ /sub/(\w+) { + nchan_subscriber; + nchan_channel_id shared_$1 user_$arg_userid; + nchan_authorize_request /authorize; +} +location /pub/user { + nchan_publisher; + nchan_channel_id user_$arg_userid; +} +``` + +A request to `/sub/foo?userid=1234` will subscribe to channels "shared_foo" and "user_1234" via a multiplexed connection. If you later send a `DELETE` request to `/pub/user?userid=1234`, this subscriber will be disconnected and therefore unsubscribed from both "user_1234" and "shared_foo". + ## Variables Nchan makes several variables usabled in the config file: @@ -401,13 +1004,16 @@ Nchan makes several variables usabled in the config file: For subscriber locations, this variable is set to the subscriber type (websocket, longpoll, etc.). - `$nchan_publisher_type` - For subscriber locations, this variable is set to the subscriber type (http or websocket). + For publisher locations, this variable is set to the subscriber type (http or websocket). - `$nchan_prev_message_id`, `$nchan_message_id` The current and previous (if applicable) message id for publisher request or subscriber response. - `$nchan_channel_event` For channel events, this is the event name. Useful when configuring `nchan_channel_event_string`. + +- `$nchan_version` + Current Nchan version. Available since 1.1.5. Additionally, `nchan_stub_status` data is also exposed as variables. These are available only when `nchan_stub_status` is enabled on at least one location: @@ -440,18 +1046,72 @@ Additionally, `nchan_stub_status` data is also exposed as variables. These are a > Split the channel id into several ids for multiplexing using the delimiter string provided. [more details](#channel-multiplexing) +- **nchan_deflate_message_for_websocket** `[ on | off ]` + arguments: 1 + default: `off` + context: server, location + > Store a compressed (deflated) copy of the message along with the original to be sent to websocket clients supporting the permessage-deflate protocol extension + - **nchan_eventsource_event** arguments: 1 default: `(none)` context: server, location, if > Set the EventSource `event:` line to this value. When used in a publisher location, overrides the published message's `X-EventSource-Event` header and associates the message with the given value. When used in a subscriber location, overrides all messages' associated `event:` string with the given value. +- **nchan_eventsource_ping_comment** + arguments: 1 + default: `(empty)` + context: server, location, if + > Set the EventSource comment `: ...` line for periodic pings from server to client. Newlines are not allowed. If empty, no comment is sent with the ping. + +- **nchan_eventsource_ping_data** + arguments: 1 + default: `(empty)` + context: server, location, if + > Set the EventSource `data:` line for periodic pings from server to client. Newlines are not allowed. If empty, no data is sent with the ping. + +- **nchan_eventsource_ping_event** + arguments: 1 + default: `ping` + context: server, location, if + > Set the EventSource `event:` line for periodic pings from server to client. Newlines are not allowed. If empty, no event type is sent with the ping. + +- **nchan_eventsource_ping_interval** ` (seconds)` + arguments: 1 + default: `0 (none)` + context: server, location, if + > Interval for sending ping messages to EventSource subscribers. Disabled by default. + - **nchan_longpoll_multipart_response** `[ off | on | raw ]` arguments: 1 default: `off` context: server, location, if > when set to 'on', enable sending multiple messages in a single longpoll response, separated using the multipart/mixed content-type scheme. If there is only one available message in response to a long-poll request, it is sent unmodified. This is useful for high-latency long-polling connections as a way to minimize round-trips to the server. When set to 'raw', sends multiple messages using the http-raw-stream message separator. +- **nchan_permessage_deflate_compression_level** `[ 0-9 ]` + arguments: 1 + default: `6` + context: http + > Compression level for the `deflate` algorithm used in websocket's permessage-deflate extension. 0: no compression, 1: fastest, worst, 9: slowest, best + +- **nchan_permessage_deflate_compression_memlevel** `[ 1-9 ]` + arguments: 1 + default: `8` + context: http + > Memory level for the `deflate` algorithm used in websocket's permessage-deflate extension. How much memory should be allocated for the internal compression state. 1 - minimum memory, slow and reduces compression ratio; 9 - maximum memory for optimal speed + +- **nchan_permessage_deflate_compression_strategy** `[ default | filtered | huffman-only | rle | fixed ]` + arguments: 1 + default: `default` + context: http + > Compression strategy for the `deflate` algorithm used in websocket's permessage-deflate extension. Use 'default' for normal data, For details see [zlib's section on copression strategies](http://zlib.net/manual.html#Advanced) + +- **nchan_permessage_deflate_compression_window** `[ 9-15 ]` + arguments: 1 + default: `10` + context: http + > Compression window for the `deflate` algorithm used in websocket's permessage-deflate extension. The base two logarithm of the window size (the size of the history buffer). The bigger the window, the better the compression, but the more memory used by the compressor. + - **nchan_publisher** `[ http | websocket ]` arguments: 0 - 2 default: `http websocket` @@ -471,7 +1131,7 @@ Additionally, `nchan_stub_status` data is also exposed as variables. These are a context: server, location, if > Send POST request to internal location (which may proxy to an upstream server) with published message in the request body. Useful for bridging websocket publishers with HTTP applications, or for transforming message via upstream application before publishing to a channel. > The upstream response code determines how publishing will proceed. A `200 OK` will publish the message from the upstream response's body. A `304 Not Modified` will publish the message as it was received from the publisher. A `204 No Content` will result in the message not being published. - [more details](https://nchan.slact.net/details#message-publishing-callbacks) + [more details](#message-forwarding) - **nchan_pubsub** `[ http | websocket | eventsource | longpoll | intervalpoll | chunked | multipart-mixed | http-raw-stream ]` arguments: 0 - 6 @@ -480,6 +1140,12 @@ Additionally, `nchan_stub_status` data is also exposed as variables. These are a > Defines a server or location as a pubsub endpoint. For long-polling, GETs subscribe. and POSTs publish. For Websockets, publishing data on a connection does not yield a channel metadata response. Without additional configuration, this turns a location into an echo server. [more details](#pubsub-endpoint) +- **nchan_subscribe_request** `` + arguments: 1 + context: server, location, if + > Send GET request to internal location (which may proxy to an upstream server) after subscribing. Disabled for longpoll and interval-polling subscribers. + [more details](#subscriber-presence) + - **nchan_subscriber** `[ websocket | eventsource | longpoll | intervalpoll | chunked | multipart-mixed | http-raw-stream ]` arguments: 0 - 5 default: `websocket eventsource longpoll chunked multipart-mixed` @@ -535,37 +1201,111 @@ Additionally, `nchan_stub_status` data is also exposed as variables. These are a legacy name: push_subscriber_timeout > Maximum time a subscriber may wait for a message before being disconnected. If you don't want a subscriber's connection to timeout, set this to 0. When possible, the subscriber will get a response with a `408 Request Timeout` status; otherwise the subscriber will simply be disconnected. +- **nchan_unsubscribe_request** `` + arguments: 1 + context: server, location, if + > Send GET request to internal location (which may proxy to an upstream server) after unsubscribing. Disabled for longpoll and interval-polling subscribers. + [more details](#subscriber-presence) + +- **nchan_websocket_client_heartbeat** ` ` + arguments: 2 + default: `none (disabled)` + context: server, location, if + > Most browser Websocket clients do not allow manually sending PINGs to the server. To overcome this limitation, this setting can be used to set up a PING/PONG message/response connection heartbeat. When the client sends the server message *heartbeat_in* (PING), the server automatically responds with *heartbeat_out* (PONG). + - **nchan_websocket_ping_interval** ` (seconds)` arguments: 1 default: `0 (none)` context: server, location, if > Interval for sending websocket ping frames. Disabled by default. +- **nchan_access_control_allow_credentials** + arguments: 1 + default: `on` + context: http, server, location, if + > When enabled, sets the [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS) `Access-Control-Allow-Credentials` header to `true`. + +- **nchan_access_control_allow_origin** `` + arguments: 1 + default: `$http_origin` + context: http, server, location, if + > Set the [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS) `Access-Control-Allow-Origin` header to this value. If the incoming request's `Origin` header does not match this value, respond with a `403 Forbidden`. Multiple origins can be provided in a single argument separated with a space. + - **nchan_authorize_request** `` arguments: 1 context: server, location, if > Send GET request to internal location (which may proxy to an upstream server) for authorization of a publisher or subscriber request. A 200 response authorizes the request, a 403 response forbids it. - [more details](https://nchan.slact.net/details#request-authorization) + [more details](#request-authorization) -- **nchan_subscribe_request** `` +- **nchan_channel_group** `` arguments: 1 + default: `(none)` context: server, location, if - > Send GET request to internal location (which may proxy to an upstream server) after subscribing. Disabled for longpoll and interval-polling subscribers. - [more details](https://nchan.slact.net/details#subsribe-and-unsubscribe-callbacks) + legacy name: push_channel_group + > The accounting and security group a channel belongs to. Works like a prefix string to the channel id. Can be set with nginx variables. -- **nchan_unsubscribe_request** `` +- **nchan_channel_group_accounting** arguments: 1 - context: server, location, if - > Send GET request to internal location (which may proxy to an upstream server) after unsubscribing. Disabled for longpoll and interval-polling subscribers. - [more details](https://nchan.slact.net/details#subsribe-and-unsubscribe-callbacks) + default: `off` + context: server, location + > Enable tracking channel, subscriber, and message information on a per-channel-group basis. Can be used to place upper limits on channel groups. + +- **nchan_group_location** `[ get | set | delete | off ]` + arguments: 0 - 3 + default: `get set delete` + context: location + > Group information and configuration location. GET request for group info, POST to set limits, DELETE to delete all channels in group. -- **nchan_max_reserved_memory** `` +- **nchan_group_max_channels** `` arguments: 1 - default: `32M` - context: http - legacy name: push_max_reserved_memory - > The size of the shared memory chunk this module will use for message queuing and buffering. - [more details](#memory-storage) + default: `0 (unlimited)` + context: location + > Maximum number of channels allowed in the group. + +- **nchan_group_max_messages** `` + arguments: 1 + default: `0 (unlimited)` + context: location + > Maximum number of messages allowed for all the channels in the group. + +- **nchan_group_max_messages_disk** `` + arguments: 1 + default: `0 (unlimited)` + context: location + > Maximum amount of disk space allowed for the messages of all the channels in the group. + +- **nchan_group_max_messages_memory** `` + arguments: 1 + default: `0 (unlimited)` + context: location + > Maximum amount of shared memory allowed for the messages of all the channels in the group. + +- **nchan_group_max_subscribers** `` + arguments: 1 + default: `0 (unlimited)` + context: location + > Maximum number of subscribers allowed for the messages of all the channels in the group. + +- **nchan_max_channel_id_length** `` + arguments: 1 + default: `1024` + context: http, server, location + legacy name: push_max_channel_id_length + > Maximum permissible channel id length (number of characters). This settings applies to ids before they may be split by the `nchan_channel_id_split_delimiter` Requests with a channel id that is too long will receive a `403 Forbidden` response. + +- **nchan_max_channel_subscribers** `` + arguments: 1 + default: `0 (unlimited)` + context: http, server, location + legacy name: push_max_channel_subscribers + > Maximum concurrent subscribers to the channel on this Nchan server. Does not include subscribers on other Nchan instances when using a shared Redis server. + +- **nchan_subscribe_existing_channels_only** `[ on | off ]` + arguments: 1 + default: `off` + context: http, server, location + legacy name: push_authorized_channels_only + > Whether or not a subscriber may create a channel by sending a request to a subscriber location. If set to on, a publisher must send a POST or PUT request before a subscriber can request messages on the channel. Otherwise, all subscriber requests to nonexistent channels will get a 403 Forbidden response. - **nchan_message_buffer_length** `[ | ]` arguments: 1 @@ -574,6 +1314,12 @@ Additionally, `nchan_stub_status` data is also exposed as variables. These are a legacy names: push_max_message_buffer_length, push_message_buffer_length > Publisher configuration setting the maximum number of messages to store per channel. A channel's message buffer will retain a maximum of this many most recent messages. An Nginx variable can also be used to set the buffer length dynamically. +- **nchan_message_temp_path** `` + arguments: 1 + default: `` + context: http + > Large messages are stored in temporary files in the `client_body_temp_path` or the `nchan_message_temp_path` if the former is unavailable. Default is the built-in default `client_body_temp_path` + - **nchan_message_timeout** `[