diff -Nru nginx-1.19.4/auto/make nginx-1.19.5/auto/make --- nginx-1.19.4/auto/make 2020-10-27 15:09:20.000000000 +0000 +++ nginx-1.19.5/auto/make 2020-11-24 15:06:34.000000000 +0000 @@ -313,7 +313,7 @@ END fi - done + done fi @@ -343,7 +343,7 @@ $ngx_cc$ngx_tab$ngx_objout$ngx_obj$ngx_tab$ngx_src$NGX_AUX END - done + done fi @@ -373,7 +373,7 @@ $ngx_cc$ngx_tab$ngx_objout$ngx_obj$ngx_tab$ngx_src$NGX_AUX END - done + done fi @@ -399,7 +399,7 @@ $ngx_cc$ngx_tab$ngx_objout$ngx_obj$ngx_tab$ngx_src$NGX_AUX END - done + done fi @@ -431,7 +431,7 @@ $ngx_cc$ngx_tab$ngx_objout$ngx_obj$ngx_tab$ngx_src$NGX_AUX END - done + done fi @@ -502,6 +502,7 @@ for ngx_module in $DYNAMIC_MODULES do eval ngx_module_srcs="\$${ngx_module}_SRCS" + eval ngx_module_shrd="\$${ngx_module}_SHRD" eval eval ngx_module_libs="\\\"\$${ngx_module}_LIBS\\\"" eval ngx_module_modules="\$${ngx_module}_MODULES" @@ -567,7 +568,7 @@ | sed -e "s/\(.*\.\)c/\1$ngx_objext/"` ngx_module_objs= - for ngx_src in $ngx_module_srcs + for ngx_src in $ngx_module_srcs $ngx_module_shrd do case "$ngx_src" in src/*) diff -Nru nginx-1.19.4/auto/module nginx-1.19.5/auto/module --- nginx-1.19.4/auto/module 2020-10-27 15:09:20.000000000 +0000 +++ nginx-1.19.5/auto/module 2020-11-24 15:06:34.000000000 +0000 @@ -17,7 +17,6 @@ done DYNAMIC_MODULES="$DYNAMIC_MODULES $ngx_module" - eval ${ngx_module}_SRCS=\"$ngx_module_srcs\" eval ${ngx_module}_MODULES=\"$ngx_module_name\" @@ -31,6 +30,30 @@ eval ${ngx_module}_ORDER=\"$ngx_module_order\" fi + srcs= + shrd= + for src in $ngx_module_srcs + do + found=no + for old in $DYNAMIC_MODULES_SRCS + do + if [ $src = $old ]; then + found=yes + break + fi + done + + if [ $found = no ]; then + srcs="$srcs $src" + else + shrd="$shrd $src" + fi + done + eval ${ngx_module}_SRCS=\"$srcs\" + eval ${ngx_module}_SHRD=\"$shrd\" + + DYNAMIC_MODULES_SRCS="$DYNAMIC_MODULES_SRCS $srcs" + if test -n "$ngx_module_incs"; then CORE_INCS="$CORE_INCS $ngx_module_incs" fi @@ -107,7 +130,24 @@ eval ${ngx_module_type}_MODULES=\"\$${ngx_module_type}_MODULES \ $ngx_module_name\" - NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_module_srcs" + srcs= + for src in $ngx_module_srcs + do + found=no + for old in $NGX_ADDON_SRCS + do + if [ $src = $old ]; then + found=yes + break + fi + done + + if [ $found = no ]; then + srcs="$srcs $src" + fi + done + + NGX_ADDON_SRCS="$NGX_ADDON_SRCS $srcs" if test -n "$ngx_module_incs"; then eval ${ngx_var}_INCS=\"\$${ngx_var}_INCS $ngx_module_incs\" diff -Nru nginx-1.19.4/auto/options nginx-1.19.5/auto/options --- nginx-1.19.4/auto/options 2020-10-27 15:09:20.000000000 +0000 +++ nginx-1.19.5/auto/options 2020-11-24 15:06:34.000000000 +0000 @@ -132,8 +132,10 @@ STREAM_SSL_PREREAD=NO DYNAMIC_MODULES= +DYNAMIC_MODULES_SRCS= NGX_ADDONS= +NGX_ADDON_SRCS= NGX_ADDON_DEPS= DYNAMIC_ADDONS= diff -Nru nginx-1.19.4/CHANGES nginx-1.19.5/CHANGES --- nginx-1.19.4/CHANGES 2020-10-27 15:09:24.000000000 +0000 +++ nginx-1.19.5/CHANGES 2020-11-24 15:06:38.000000000 +0000 @@ -1,4 +1,19 @@ +Changes with nginx 1.19.5 24 Nov 2020 + + *) Feature: the -e switch. + + *) Feature: the same source files can now be specified in different + modules while building addon modules. + + *) Bugfix: SSL shutdown did not work when lingering close was used. + + *) Bugfix: "upstream sent frame for closed stream" errors might occur + when working with gRPC backends. + + *) Bugfix: in request body filters internal API. + + Changes with nginx 1.19.4 27 Oct 2020 *) Feature: the "ssl_conf_command", "proxy_ssl_conf_command", diff -Nru nginx-1.19.4/CHANGES.ru nginx-1.19.5/CHANGES.ru --- nginx-1.19.4/CHANGES.ru 2020-10-27 15:09:23.000000000 +0000 +++ nginx-1.19.5/CHANGES.ru 2020-11-24 15:06:37.000000000 +0000 @@ -1,4 +1,20 @@ +Изменения в nginx 1.19.5 24.11.2020 + + *) Добавление: ключ -e. + + *) Добавление: при сборке дополнительных модулей теперь можно указывать + одни и те же исходные файлы в разных модулях. + + *) Исправление: SSL shutdown не работал при закрытии соединений с + ожиданием дополнительных данных (lingering close). + + *) Исправление: при работе с gRPC-бэкендами могли возникать ошибки + "upstream sent frame for closed stream". + + *) Исправление: во внутреннем API для обработки тела запроса. + + Изменения в nginx 1.19.4 27.10.2020 *) Добавление: директивы ssl_conf_command, proxy_ssl_conf_command, diff -Nru nginx-1.19.4/configure nginx-1.19.5/configure --- nginx-1.19.4/configure 2020-10-27 15:09:20.000000000 +0000 +++ nginx-1.19.5/configure 2020-11-24 15:06:34.000000000 +0000 @@ -87,6 +87,10 @@ have=NGX_LOCK_PATH value="\"$NGX_LOCK_PATH\"" . auto/define have=NGX_ERROR_LOG_PATH value="\"$NGX_ERROR_LOG_PATH\"" . auto/define +if [ ".$NGX_ERROR_LOG_PATH" = "." ]; then + have=NGX_ERROR_LOG_STDERR . auto/have +fi + have=NGX_HTTP_LOG_PATH value="\"$NGX_HTTP_LOG_PATH\"" . auto/define have=NGX_HTTP_CLIENT_TEMP_PATH value="\"$NGX_HTTP_CLIENT_TEMP_PATH\"" . auto/define diff -Nru nginx-1.19.4/debian/changelog nginx-1.19.5/debian/changelog --- nginx-1.19.4/debian/changelog 2020-10-30 13:30:51.000000000 +0000 +++ nginx-1.19.5/debian/changelog 2020-11-26 10:08:15.000000000 +0000 @@ -1,13 +1,19 @@ -nginx (1.19.4-0+groovy1) groovy; urgency=medium +nginx (1.19.5-0+groovy1) groovy; urgency=medium * Non-maintainer upload. + * New upstream Mainline version (1.19.5) - full changelog available from + http://nginx.org/en/CHANGES + + -- Filip Chabik Thu, 26 Nov 2020 10:08:15 +0000 + +nginx (1.19.4-0+focal1) focal; urgency=medium + * New upstream Mainline version (1.19.4) - full changelog available from http://nginx.org/en/CHANGES - * nchan module disabled due to failure during compilation. -- Filip Chabik Fri, 30 Oct 2020 13:30:51 +0000 -nginx (1.19.3-0+groovy1) groovy; urgency=medium +nginx (1.19.3-0+focal1) focal; urgency=medium * New upstream Mainline version (1.19.3) - full changelog available from http://nginx.org/en/CHANGES @@ -19,7 +25,7 @@ -- Filip Chabik Wed, 30 Sep 2020 07:41:47 +0000 -nginx (1.19.2-0+groovy1) groovy; urgency=medium +nginx (1.19.2-0+focal1) focal; urgency=medium * New upstream Mainline release (1.19.2) - full changelog available from http://nginx.org/en/CHANGES diff -Nru nginx-1.19.4/debian/control nginx-1.19.5/debian/control --- nginx-1.19.4/debian/control 2020-10-30 13:30:51.000000000 +0000 +++ nginx-1.19.5/debian/control 2020-11-26 10:08:15.000000000 +0000 @@ -204,6 +204,7 @@ libnginx-mod-http-xslt-filter (= ${binary:Version}), libnginx-mod-http-vhost-traffic-status (= ${binary:Version}), libnginx-mod-mail (= ${binary:Version}), + libnginx-mod-nchan (= ${binary:Version}), libnginx-mod-stream-server-traffic-status (= ${binary:Version}), nginx-common (= ${source:Version}), iproute2, @@ -324,6 +325,19 @@ features that are seen from a user's point of view - it's just designed to help reduce the code that Nginx module developers need to write. +Package: libnginx-mod-nchan +Architecture: any +Depends: ${misc:Depends}, ${shlibs:Depends} +Description: Fast, flexible pub/sub server for Nginx + Nchan is a scalable, flexible pub/sub server for the modern web, It can be + configured as a standalone server, or as a shim between your application and + tens, thousands, or millions of live subscribers. It can buffer messages in + memory, on-disk, or via Redis. All connections are handled asynchronously and + distributed among any number of worker processes. It can also scale to many + nginx server instances with Redis. + . + Full documentation available at https://nchan.slact.net + Package: libnginx-mod-http-echo Architecture: any Depends: ${misc:Depends}, ${shlibs:Depends} diff -Nru nginx-1.19.4/debian/copyright nginx-1.19.5/debian/copyright --- nginx-1.19.4/debian/copyright 2020-10-30 13:30:51.000000000 +0000 +++ nginx-1.19.5/debian/copyright 2020-11-26 10:08:15.000000000 +0000 @@ -70,6 +70,10 @@ Igor Sysoev License: BSD-2-clause +Files: debian/modules/nchan/* +Copyright: 2009-2016 Leo Ponomarev +License: MIT + Files: debian/modules/nchan/src/store/redis/cmp.* Copyright: 2015 Charles Gunyon License: MIT diff -Nru nginx-1.19.4/debian/libnginx-mod.conf/mod-nchan.conf nginx-1.19.5/debian/libnginx-mod.conf/mod-nchan.conf --- nginx-1.19.4/debian/libnginx-mod.conf/mod-nchan.conf 1970-01-01 00:00:00.000000000 +0000 +++ nginx-1.19.5/debian/libnginx-mod.conf/mod-nchan.conf 2020-11-26 10:08:15.000000000 +0000 @@ -0,0 +1 @@ +load_module modules/ngx_nchan_module.so; diff -Nru nginx-1.19.4/debian/libnginx-mod-nchan.nginx nginx-1.19.5/debian/libnginx-mod-nchan.nginx --- nginx-1.19.4/debian/libnginx-mod-nchan.nginx 1970-01-01 00:00:00.000000000 +0000 +++ nginx-1.19.5/debian/libnginx-mod-nchan.nginx 2020-11-26 10:08:15.000000000 +0000 @@ -0,0 +1,13 @@ +#!/usr/bin/perl -w + +use File::Basename; + +# Guess module name +$module = basename($0, '.nginx'); +$module =~ s/^libnginx-mod-//; + +$modulepath = $module; +$modulepath =~ s/-/_/g; + +print "mod debian/build-extras/objs/ngx_${modulepath}_module.so\n"; +print "mod debian/libnginx-mod.conf/mod-${module}.conf\n"; diff -Nru nginx-1.19.4/debian/modules/nchan/changelog.txt nginx-1.19.5/debian/modules/nchan/changelog.txt --- nginx-1.19.4/debian/modules/nchan/changelog.txt 1970-01-01 00:00:00.000000000 +0000 +++ nginx-1.19.5/debian/modules/nchan/changelog.txt 2020-11-26 10:08:15.000000000 +0000 @@ -0,0 +1,505 @@ +1.2.7 (Mar. 17 2020) + fix: unidirectional subscribers have their connection terminated if they send any data to the server + after the initial request handshake. This applies to all subscribers except Websocket + feature: periodic pings for EventSource subscribers + fix: Redis pending commands count may be incorrect in nchan's stub status page + fix: channel deletion fails to propagate to Redis slaves + fix: possible stack overflow when using websocket subscribers +1.2.6 (Jun. 18 2019) + fix: when using Redis, a channel can stop receiving new messages if + they are published faster than they can be sent to subscribers and the + message buffer is sufficiently small + fix: websocket PONG response did not contain PING frame data + fix: multiplexed channels may stop receiving messages + fix (security): specially crafted websocket publisher requests when using Redis + may result in use-after-free memory access + fix: Nginx config reload may result in crash when using Redis cluster +1.2.5 (Mar. 20 2019) + fix: using multiplexed channels with Redis in backup mode may result in worker crash + fix: nchan_publisher_channel_id could not be set exclusively in a publisher location + fix: Google pagespeed module compatibility + fix: nchan prevents nginx from starting if no http {} block is configured +1.2.4 (Feb. 25 2019) + fix: Redis cluster info with zero-length hostname may result in worker crash + fix: build problems with included hiredis lib in FreeBSD + feature: nchan_redis_namespace and nchan_redis_ping_interval now work in upstream blocks + fix: websocket publisher did not publishing channel events + fix: Redis namespace was limited to 8 bytes +1.2.3 (Oct. 15 2018) + fix: possible invalid memory access when the initial connection to a Redis cluster node times out +1.2.2 (Oct. 9 2018) + fix (security): using an unresponsive, overloaded Redis server may result in invalid memory access + fix: incorrect logging of discovered Redis cluster nodes + fix: better handling of connection loss when Redis server is unresponsive + fix: presence of Redis cluster nodes with no known address ("noaddr") nodes could result in worker crash + fix (security): subscriber may erroneously receive a 400 Bad Request or crash a worker + based on data from a previous subscriber + feature: built-in backend benchmark + feature: add optimized fastpublish option to Redis nostore mode for maximum + message publishing thoroughput via Redis + feature: add no-store Redis mode that uses Redis for broadcasting messages, not storage + fix: connecting to load-balancing Redis proxy resulted in crash + fix: using longpoll-multipart in "raw" mode cound result in worker crash + fix: channel events used with Redis resulted in segfault +1.2.1 (Aug. 2 2018) + fix: channel last_requested was set to 0 instead of -1 on channel creation + fix: authentication failure body not forwarded for Nginx > 1.13.10 + fix: possible invalid memory access for websocket unsubscribe requests + fix: building Nchan could interfere with building other modules +1.2.0 (Jul. 23 2018) + feature: configurable support for CORS Access-Control-Allow-Credentials header + fix: better compliance with RFC7692 Websocket permessage-deflate parameter negotiation + fix (security): possible busy-loop denial-of-service for specially crafted + handshakes from Websocket subscribers using permessage-deflate + (Thanks, Benjamin Michéle) + fix: nchan_permessage_deflate_compression_memlevel was not applied when set + refactor: all publisher and subscriber upstream requests are now more memory-efficient + fix: Using websocket publisher upstream requests may result in invalid memory access + fix: publishing Redis-backed messages with 1-second expiration may fail after + cluster restart + change: nchan_redis_wait_after_connecting directive is now obsolete, and is ignored + feature: nchan_redis_optimize_target for "cpu" or "bandwidth". Trades off CPU + load on Redis slaves for syncronization bandwidth. + feature: configurable Redis master/slave channel subscribe weights with + nchan_redis_subscribe_weights + fix: Compilation issues on OS X and systems lacking non-POSIX memrchr() + fix: nchan_pubsub CORS Allowed headers did not include headers used by subscribers + fix: Redis-backed channel buffer length could exceed nchan_message_buffer_length + fix: Publisher upstream compatibility for Nginx > 1.13.10 + feature: nchan_redis_connect_timeout to configure maximum connection time + to Redis servers + feature: Offload Redis SUBSCRIBE traffic to slaves + (one SUBSCRIBE per channel per worker) + fix: Redis cluster and master/slave failover and reconnection issues + refactor: Redis connection handling rewritten from scratch + fix: subscribers may not receive new messages after reconnecting to Redis + fix: publishing to an unavailable Redis-backed channel may result in a + following 400 Bad Request + change: Old Redis-backed channel messages are now delivered after the message + buffer is fully loaded into memory. Previously they were delivered + incrementally while the buffer loaded. + fix: multiplexed Redis-backed channels may not deliver messages if one or + more channels' messages all expire + fix: possible crash when catching up to reconnected Redis channel with + subscribers waiting for consecutive messages + fix: possible crash from rapidly creating and deleting channels +1.1.15 (Apr. 27 2018) + fix: A disconnect from a Redis cluster node can result in a segfault + fix: Using Redis-backed multiplexed channels can result in a segfault +1.1.14 (Jan. 10 2018) + feature: added nchan_redis_wait_after_connecting setting + fix: compatibility with Redis >= 4.0 cluster +1.1.13 (Dec. 4 2017) + fix: added Redis backwards compatibility with Nchan 1.1.7 and below + for online upgrades with mixed-version Nchan cluster +1.1.12 (Dec. 1 2017) + fix: possible "Unexpected spool == nuspool" worker crash + fix: subscriber messages delivered during active nchan_subscribe subrequest + may be garbled +1.1.11 (Nov. 29 2017) + fix: Redis backup-mode not working (since 1.1.9) + fix: incorrect handling of Redis permessage-deflated messages results in + missing first char of eventsource event type + fix: worker crash when unable to create temp file for large websocket + permessage-deflate message + fix: CPU-bound overloaded Nginx may result in worker crashes + (may occur with large Openresty Lua load) + change: default nchan_shared_memory_size is now 128M + fix: some channel info from publisher GET requests may be incorrect with Redis + fix: file descriptor leak when reconnecting to Redis +1.1.10 (Nov. 13 2017) + feature: nchan_authorize_request failure response forwarded back to subscriber + Sponsored by Symless (https://symless.com/) + fix: allow nchan_access_control_allow_origin in if blocks + fix: longpoll-multipart may read uninitialized memory when receiving + zero-length message + fix (security): invalid memory access for aborted websocket subscriber + after channel existence check via Redis + fix: websocket handhshake failure handled incorrectly when messages + are available + fix (security): websocket subscriber disconnecting before handshake may + result in invalid memory access + fix (security): possible invalid memory access for disappearing longpoll sub + feature: add "shared memory limit" to nchan_stub_status output +1.1.9 (Oct. 30 2017) + fix: more proper websocket extension negotiation with more + informative failure messages + fix: websocket handshake failure response included superfluous CLOSE frame + feature: websocket deflate-frame and x-webkit-deflate-frame support +1.1.8 (Oct. 26 2017) + feature: websocket permessage-deflate support + Sponsored by HYFN (https://hyfn.com/) + fix (security): websocket publisher may crash worker when publishing with + channel group accounting on to a new group + fix: messages published to Nchan via websocket binary frames + should have content-type set to "application/octet-stream" + fix: accept websocket publisher binary frames (thanks @rponczkowski) + fix: multiplexing over exactly 255 channels results in worker crash + fix (security): Specially crafted invalid subscriber msgid may crash worker + fix: nchan_subscriber_first_message <= 0 (newest) with existing Redis data + incorrectly treated as "oldest" for initial subscribers + fix: 0-length channel name may crash worker + fix: subscribe/unsubscribe callback requests do not work when used with + authorization callback request + fix (security): Messages published with Redis through websocket publisher + may result in worker crash (bug introduced in 1.1.5) + fix: nchan_pubsub setting may not be parsed correctly +1.1.7 (Jul. 3 2017) + fix: possible read-after-free after redis disconnect + fix: publishing to redis cluster before it is connected results in worker crash + fix: possible use-after-free for suddenly disconnected longpoll-multipart subscriber + fix: possible use-after-free when using nchan_authorize_request for slow subscribers and slow upstream + fix: nchan_stub_status "stored messages" value could be incorrect when using Redis +1.1.6 (May 9 2017) + fix: messages published through Redis may crash worker (introduced in 1.1.5) + fix (security): urlencoded message id in url parsed incorrectly can result in worker crash +1.1.5 (May 3 2017) + feature: get current Nchan version through $nchan_version variable + and nchan_stub_status + fix (security): invalid memory access for multiplexed channel subscribers + with buffered output (Thanks Casey Forbes (@caseyf) for debugging.) + fix: "redis pending commands" nchan_stub_status stat could be wrong after + deleting channels + fix: invalid memory access when using Redis under high load + fix: possible "message from the past" errors under high publishing load + fix: graceful publisher/subscriber notifications when out of shared memory + (via HTTP 507 Insufficient Storage status code) + fix: compatibility with limit_except directive +1.1.4 (Apr. 25 2017) + fix (security): possible memory corruption using multiplexed channels + at high load (Thanks Giovanni Caporaletti (@TrustNoOne) for debugging.) + fix: possible crash when reconnecting to Redis cluster (introduced in 1.1.3) +1.1.3 (Mar. 25 2017) + fix (security): incorrect handling of WS optimization could trigger SIGABRT + fix: Redis cluster reconnect readiness verification +1.1.2 (Mar. 1 2017) + change: "interprocess alert X delayed by Y sec" log messages downgraded + from ERROR to NOTICE + fix: "group info string too short" error + fix: Incorrect handling of connections to Redis cluster nodes with round-robin + DNS hostnames (Thanks to ring.com for sponsoring this fix!) +1.1.1 (Feb. 8 2017) + fix: incorrect stats for nchan_stub_status after reload. + (Stats are no longer reset after reload) + fix: websocket subscriber may receive two CLOSE frames + fix: websocket with ws+meta.nchan subprotocol did not receive empty messages + feature: websocket client heartbeats with nchan_websocket_client_heartbeat + fix: websocket now echoes code and reason when connection close initiated from client +1.1.0 (Jan. 4 2017) + feature: websocket subscribers now receive "application/octet-stream" messages + in binary frame rather than text + fix: publisher request variables not always passed to nchan_publisher_upstream_request + feature: Redis storage 'backup' mode strictly for data persistence + fix: possible lingering subscriber if connection is closed just before subscribing + fix: possible memory leak when using multiplexed channels + security fix: subscribing with If-Modified-Since and without If-None-Match headers + crashed the Nginx worker (thanks @supertong) + security fix: sending an empty message to multipart/mixed subscriber crashed Nginx worker + fix: publisher & subscriber response codes were logged incorrectly + fix: websocket subscriber memory leak on upstream authentication failure + fix: possible crash after reloading when using several instances of Nchan with Redis + feature: nchan_access_control_allow_origin can accept nginx variables + feature: Redis key namespaces + feature: all size configurations can now parse decimal values + fix: off-by-one subscriber count when using multiplexed channels + feature: accounting and dynamic limits for channel groups +1.0.8 (Nov. 28 2016) + fix: possible crash under severely heavy load, introduced in 1.0.7 with stack-overflow fix +1.0.7 (Nov. 27 2016) + fix: memory leak after websocket publisher uncleanly aborts connection + fix: misbehaving websocket publisher with nchan_publisher_upstream_request + fix: potential stack overflow with very large message buffers + fix: invalid memory access with empty nchan_publisher_upstream_request for websocket publisher + fix: incorrect handling of chunked response from nchan_publisher_upstream_request + fix: publishing through websocket too fast may result in buffered messages that never arrive + fix: DELETE to multiplexed channel should delete all listed channels + fix: abort if publishing to multiple channels while using redis +1.0.6 (Nov. 15 2016) + fix: large messages were sometimes incorrectly cleaned up, leaving behind temp files + fix: file descriptor leak when listening on a unix socket and suddenly + aborting client connections + fix: invalid memory access after reloading twice with redis enabled + fix: crash after shutting down nginx when 'master_process' set to 'off' + change: nchan_max_channel_subscribers now always refers to subscribers on this instance of + Nchan, even when using Redis. + feature: subscribe/unsubscribe callbacks with nchan_subscribe_request and nchan_unsubscribe_request +1.0.4 (Oct. 28 2016) + security: fix crash when receiving large messages over websocket with ws+nchan subprotocol +1.0.3 (Sept. 3 2016) + feature: nchan_message_timeout and nchan_message_buffer_length + can now use nginx variables for dynamic values + fix: unsolicited websocket PONGs disconnected the subscriber in violation of RFC6455 + fix: possible script error when getting channel from Redis + fix: possible incorrect message IDs when using Redis (thanks @supertong) + security: possible invalid memory access on publisher GET, POST, or DELETE when + using Redis and the publisher connection is terminated before receiving + a response + fix: correct publisher response code when nchan_authorize_request is unavailable + (502 instead of 500) + security: crash if publisher POSTs request with no Content-Length header when + using nchan_authorize_request +1.0.2 (Aug. 29 2016) + fix: more informative missed-message warnings + fix: invalid memory access when Redis enabled without setting server URL + fix: incomplete redis channel deletion + fix: Redis command responses may not be processed after large message + until next command + feature: catch up with missed messages after reconnecting to Redis cluster + fix: possible invalid memory access after disconnecting from Redis cluster + fix: Redis-stored unbuffered messages may not be delivered + fix: possible invalid memory access when using previously idling channels + fix: invalid memory access if publisher POST request's connection terminates + before receiving response + fix: messages published rapidly to Redis via different Ncnan servers may + be received out of order + fix: possible stack overflow when receiving messages through Redis + for multiplexed channels + fix: channels with 'nchan_store_messages off' published 1 message per second + fix: issue warning when out-of-order published message is detected + fix: Redis cluster compatibility with channel ids containing '}' character + fix: Redis-stored channel deleted too quickly when publishing short-lived messages +1.0.1 (Aug. 22 2016) + feature: nchan_stub_status shared memory accounting + fix: various compiler warnings +1.0.0 (Aug. 20 2016) + fix: incorrectly repeated subscriber_enqueue channel events + fix: badly handled Redis messages with TTL < 1 (again) + fix: websocket didn't close connection on PING fail + feature: nchan_stub_status stats location + fix: bad memory access for Redis channels when unsubscribing and very busy + optimize: SSE2 & AVX2 optimizations for websocket frame unmasking + feature: Redis Cluster support + (WARNING:) data in Redis from previous versions will be inaccessible + feature: different locations can use different Redis servers + feature: nchan_subscriber_first_message can take a number (positive or negative) + for nth message (from first or last) + feature: expire Redis-stored idle channels with nchan_redis_idle_channel_cache_timeout + fix: some multiplexed channels never garbage-collected when inactive + fix: unbuffered message garbage collector was too lazy + fix: update nchan_message_buffer_length correctly when using Redis (thanks @supertong) + fix: incorrect handling of missing/expired messages in multiplexed channels + fix: memory leak when publishing via Websocket on a pubsub location + fix: multiplexed channel DELETE when using Redis handled incorrectly + fix: rare Redis script error when publishing message + fix: Redis connection ping infinite loop when reloading + fix: crash if Redis message TTL less than 1 sec + fix: message delivery occasionally stopped when using Redis + and rapidly publishing messages + fix: logpoll-multipart sometimes failed to respond when using Redis + and rapidly publishing messages + fix: don't crash if Redis server is busy loading data +0.99.16 (Jun 10 2016) + fix: invalid memory access when upstream subscriber authorize request failed + fix: longpoll-multipart subscriber was managed incorrectly on channel deletion + fix: subscribers may not receive messages after Redis reconnection +0.99.15 (May 31 2016) + feature: Redis client keepalive configurable with nchan_redis_ping_interval + feature: try to reconnect to Redis after lost connection to Redis + fix: invalid memory access after lost connection to Redis + fix: use-after-free error if subscriber disconnects before response + from upstream authorize server (thanks Filip Jenicek) + fix: corrupt longpoll-multipart boundary data with long messages + feature: 'raw' mode for longpoll-multipart + feature: http-raw-stream client, like Push Stream Module's 'stream' mode + fix: incomplete longpoll-multipart response when using Redis + fix: "subrequests cycle" error for websocket publisher for nginx > 1.9.4 + fix: nchan_channel_id_split_delimiter inheritance + fix: subscriber memory leak from 0.99.8 + fix: reload crash from 0.99.14 +0.99.14 (May 4 2016) + fix: trailing NULL character in Publisher response content-type for json, xml, and yaml + fix: don't crash when out of shared memory + fix: invalid memory access when using nchan_publisher_upstream_request with websocket + fix: incorrect stored messages count when using Redis store + fix: incorrect last_message_id on publisher GETs (memstore and Redis) + fix: incorrect behavior when subscribing right after startup before all workers are ready + fix: some internal event loop timers were not being canceled, leading to slow shutdown + fix: resuming some subscribers with valid message ids didn't work when using Redis store + fix: possible invalid memory access when restarting Nginx after using multiplexed channels + fix: accept url-encoded message ids + feature: add ws+meta.nchan websocket subprotocol that include message metadata + fix: all requests after X-Accel-Redirect from upstream were treated as GETs +0.99.13 (Apr. 20 2016) + fix: invalid content-length for nchan_authorize_request publisher requests + fix: "subrequests cycle" error after 200 websocket publish requests + fix: zero-size buf warning when publishing empty messages via websocket + fix: nchan_max_channel_subscribers was ignored + fix: use a blocking Redis connection for commands during shutdown to ensure commands are sent + fix: better TTL handling for Redis keys +0.99.12 (Apr. 10 2016) + fix: SPDY compatibility with EventSource and multipart/mixed subscribers + fix: warnings when shutting down Redis storage + feature: use system's hiredis library if present + fix: incorrect handling of missing messages when publishing to Redis +0.99.11 (Apr. 3 2016) + feature: nchan can be built as a dynamic module (for nginx >= 1.9.11) +0.99.10 (Apr. 2 2016) + fix: messages not freed until expired after being deleted from channel + fix: buffering and output issues for large messages + update: hiredis updated to v0.13.3 + fix: Redis publishing and subscribing memory leaks + optimize: per-channel Redis subscriber counts batched into 100-ms intervals + to prevent Redis roundtrip floods + fix: Redis subscriber memory leak + refactor: extracted shared subscriber and message store logic + fix: use-after-free error for Redis channels without subscribers + fix: channel readying logic sometimes got confused and tripped up assert()s + fix: even more proper handling of websocket close frames + change: 408 Request Timeout instead of 304 No Content status code for timed out subscribers +0.99.8 (Mar. 13 2016) + fix: multipart/mixed subscriber output issues + fix: memory leak for multiplexed > 4 channels + fix: invalid memory access for aborted subscriber connection with Redis + and nchan_subscribe_existing_channels_only + fix: accept websocket binary data frames + fix: proper handling of websocket close frames + fix: incorrect expire calculation for cached Redis-stored messages + fix: double free for multiplexed >4 websocket subs +0.99.7 (Mar. 10 2016) + fix: websocket infinite ping loop after reload + feature: nchan_subscriber_message_id_custom_etag_header for misbehaving proxies that eat etags + fix: 100% cpu after lost Redis connection + fix: refined CORS cross-origin access control headers and logic + fix: longpoll subscriber in multipart mode didn't output all messages + fix: longpoll subscriber in multipart mode could access invalid memory + fix: compatibility with supported Redis versions < 2.8.14 + fix: nchan_message_timeout 0 should not expire messages +0.99.6 (Feb. 22 2016) + fix: SIGHUP reloading under load +0.99.5 (Feb 15 2016) + fix: publishing with client_body_in_file_only enabled +0.99.4 (Feb 12 2016) + fix: invalid memory access in channel DELETE response + fix: race condition in IPC during channel creation (thanks vtslothy) +0.99.3 (Feb 10 2016) + fix: SIGHUP reloading + fix: startup with insufficient file descriptors shouldn't crash + fix: longpoll-multipart failure to immediately respond + fix: longpoll-multipart abort handling + fix: Redis-store cached message timeouts + fix: Redis connection-lost handling + fix: startup with 'master_process off' (single-process mode) + feature: EventSource 'event:' line support with custom header or config +0.98 (Jan 21 2016) + feature: publish to multiple channels with one request + feature: nchan_longpoll_multipart_response config setting + fix: large message (in-file) handling for multipart/mixed and chunked subscribers + fix: 400 Bad Request error on 32-bit systems + fix: memory allocation error for >8 multi-channel subscribers +0.97 (Jan 5 2016) + fix: build issues with debian + fix: compatibility with nginx versions down to 1.0.15 + fix: publishing bug introduced in 0.96 +0.961 (Jan 4 2016) + fix: compiler warning +0.96 (Jan 1. 2016) + feature: websocket ping with nchan_websocket_ping_interval + fix: unsafe memory access for Redis publisher + feature: nchan_publisher_upstream_request + fix: http/2 compatibility for EventSource and multipart/mixed + fix: nchan_authorize_request for publisher location endpoints + fix: publishing long (stored in file) messages to Redis-store +0.95 (Dec. 24 2015) + feature: configurable nchan_access_control_origin_header, default to * + fix: recognize non-preflighted CORS requests + fix: Redis invalid memory access after timeout +0.94 (Dec. 22 2015) + feature: last mesage id in channel info response + feature: subscribe up to 255 channel ids using nchan_channel_id_split_delimiter + fix: tried connecting to Redis when not needed + change: "last requested" no longer has a -1 value for 'never requested'. + fix: "last requested" in channel info sometimes not updated + fix: deleting empty channels + change: more compact message ids +0.931 (Dec. 14 2015) + optimize: inter-process internal subscriber fetched too many messages +0.93 (Dec. 12 2015) + feature: optionally only use Etag for subscriber message id + feature: optionally get requested message id from variable config +0.92 (Dec. 11 2015) + feature: HTTP multipart/mixed subscriber + fix: EventSource bad memory access on disconnect + feature: HTTP chunked encoding subscriber + fix: resolved some strict compiler warnings + fix: more stringent out-of-memory detection during response output. thanks @woodyhymns + fix: less-than-optimal cache filename handling. thanks @ZhouBox + fix: incorrect EventSource charset in header. thanks @eschultz + fix: segfault when websocket publishes message and immediately disconnects + fix: Duplicate "Connection: Upgrade" header for websocket handshake. thanks @eschultz +0.904 (Dec. 7 2015) + fix: more flexible Websocket handshake for "Connection" header. thanks @eschultz + fix: out-of-memory safety check. thanks @woodyhymns +0.903 (Dec 3 2015) + fix: better Redis engine connection initializer + change: simpler message buffer settings + fix: more backwards-compatibility for pushmodule config settings +0.9 (Dec. 2 2015) - first beta pre-release tag after rebranding as Nchan + feature: meta channel events: track when subscribers connect and disconnect, and when messages are + published, with configurable event strings + feature: request authorization: send upstream request before publishing or subscribing. + works just like the auth_request module. + feature: channel multiplexing. up to 4 channels can be subscribed to from a single location + fix: channel ids were not set within if statements in the nginx config + feature: hybrid memstore + Redis storage. local caching + distributed message publishing, the best + of both worlds. (still slower than pure memstore though) + feature: pubsub locations, optional separate publisher and subscriber channel ids per location + feature: websocket publisher support + name change: we're nchan now. code renamed, and cleaned up. config options are backwards-compatible. + feature: websocket subscriber support + huge refactor: completely new in-memory storage engine. No more global lock. + Actually, no more locks at all! + feature: Redis storage engine. +0.73 (Sep. 2 2014) + fix: turning on gzip cleared Etag subscriber response header + fix: channels incorrectly deleted when overwhelmed with connections + feature: CORS support via OPTIONS request method response + fix: file descriptor leak when restarting nginx via SIGHUP + improve: concurrency for interprocess notifications + refactor: completely encapsulated message store + fix: slow memory leak introduced in 0.7 + fix: memory leak when not using message buffer +0.712 (Mar. 21 2014) + fix: intermittently dropped long-polling connections on internal redirects + fix: unable to proxy long-polling subscribers. (thanks wandenberg and sanmai) +0.711 (Mar. 13 2014) + fix: incompatibility with cache manager (proxy_cache and fastcgi_cache directives) +0.71 (Mar. 1 2014) + fix: removed unused variables and functions to quiet down GCC +0.7: (Feb. 20 2014) + fix: last-in concurrency setting wasn't working reliably + refactor: partially separated message storage. add a test harness. + fix: segfault from concurrency bug while garbage-collecting channels + fix: some large messages got lost +0.692 (Feb. 3 2010) + fix: error log reported failed close() for some publisher requests with large messages + fix: occasional memory leak during message deletion + fix: worker messages intended for dead worker processes were not deleted +0.691 (Feb. 2 2010) + fix: server reload (via SIGHUP signal) was failing + fix: segfault on messages longer than client_body_buffer_size (thanks wfelipe) + change: removed push_min_message_recipients, added push_delete_oldest_received_message +0.69 (Nov. 17 2009) + fix: publisher got a 201 Created response even if the channel had no subscribers at the time (should be 202 Accepted) + fix: small memory leak after each message broadcast to a channel + feature: optional push_max_channel_subscribers setting added + fix: first-in concurrency setting wasn't responding to subscribers with a correct status code on conflict + fix: reused subscriber connections sometimes failed to receive messages + unfeature: no more nginx 0.6 support. not worth the hassle. +0.683 (Nov. 10 2009) + change: default max. reserved memory size changed form 16MB to 32 MB + change: unused node garbage collection made a little more aggressive (max. 3 unused channels per channel search instead of 1) + fix: unused nodes were deleted only on channel id hash collision (very rare) + fix: segmentation fault from allocating insufficient memory for interprocess messaging +0.681 (Nov. 6 2009) + feature: added push_message_buffer_length setting, which sets push_message_max_buffer_length and push_message_min_buffer_length at once. + fix: publisher channel info text/json response now uses double quotes instead of single. + fix: interprocess messages were not removed from shared memory correctly, causing weird errors +0.68 (Nov. 5 2009) + change: default push_subscriber_concurrency value is now "broadcast" + fix: incorrect error messages for invalid push_pubscriber and push_subscriber_concurrency settings + change: removed deprecated push_buffer_size and push_queue_messages settings + feature: rudimentary content-type negotiation for publisher channel info response. + support text/plain, text/json, text/yaml and application/xml (and mimetype equivalents) + fix: publisher GET response has HTTP status 0 +0.67beta (Nov. 4 2009) and older + see git repository diff -Nru nginx-1.19.4/debian/modules/nchan/cloc-exclude.txt nginx-1.19.5/debian/modules/nchan/cloc-exclude.txt --- nginx-1.19.4/debian/modules/nchan/cloc-exclude.txt 1970-01-01 00:00:00.000000000 +0000 +++ nginx-1.19.5/debian/modules/nchan/cloc-exclude.txt 2020-11-26 10:08:15.000000000 +0000 @@ -0,0 +1,16 @@ +src/uthash.h +src/hiredis +src/util/ngx_nchan_hacked_slab.c +src/util/hdr_histogram.c +src/util/hdr_histogram.h +src/store/redis/cmp.c +src/store/redis/cmp.h +src/store/redis/redis_lua_commands.h +src/nginx-source +src/nchan_config_commands.c +dev/bench +dev/nginx-pkg +dev/clang-analyzer +dev/package +dev/src +dev/redis-trib.rb diff -Nru nginx-1.19.4/debian/modules/nchan/config nginx-1.19.5/debian/modules/nchan/config --- nginx-1.19.4/debian/modules/nchan/config 1970-01-01 00:00:00.000000000 +0000 +++ nginx-1.19.5/debian/modules/nchan/config 2020-11-26 10:08:15.000000000 +0000 @@ -0,0 +1,156 @@ +ngx_addon_name=ngx_nchan_module + +nchan_libs="" +#do we have hiredis on the platform? +# it's currently no longer possible to link the platform's hiredis lib, +# because we now use a hacked connect function +# maybe it can be brought back at some later time... +ngx_feature="hiredis with stored sockaddr" +ngx_feature_name="NCHAN_HAVE_HIREDIS_WITH_SOCKADDR" +ngx_feature_run=yes +ngx_feature_path= +ngx_feature_incs=" \ + #include + #include +" +ngx_feature_libs="-lhiredis" +ngx_feature_test=" \ + redisContext c; \ + if(HIREDIS_SONAME < 0.13) { return 1; } \ + if(sizeof(c.sockaddr) != sizeof(struct sockaddr)) { return 1;} \ +" +. auto/feature +if [ $ngx_found = no ]; then + _NCHAN_HIREDIS_SRCS="\ + ${ngx_addon_dir}/src/store/redis/hiredis/hiredis.c \ + ${ngx_addon_dir}/src/store/redis/hiredis/read.c \ + ${ngx_addon_dir}/src/store/redis/hiredis/async.c \ + ${ngx_addon_dir}/src/store/redis/hiredis/sds.c \ + ${ngx_addon_dir}/src/store/redis/hiredis/net.c \ + " + ngx_feature_libs="" +else + nchan_libs="$nchan_libs $ngx_feature_libs" + _NCHAN_HIREDIS_SRCS="" +fi + +ngx_feature="math lib" +ngx_feature_name="NCHAN_HAVE_MATH" +ngx_feature_run=yes +ngx_feature_path= +ngx_feature_incs="#include " +ngx_feature_libs="-lm" +ngx_feature_test="sqrt(20);" +. auto/feature +if [ $ngx_found = yes ]; then + nchan_libs="$nchan_libs $ngx_feature_libs" +fi + +#do we have memrchr() on the platform? +ngx_feature="memrchr()" +ngx_feature_name="NCHAN_HAVE_MEMRCHR" +ngx_feature_run=yes +ngx_feature_path= +ngx_feature_libs= +ngx_feature_incs=" \ + #include + #include +" +ngx_feature_test=" \ + const char *str = \"aboobar\"; \ + const void *place = &str[4]; \ + const void *found = memrchr(str, 'b', strlen(str)); \ + if(place != found) { return 1; } \ +" +. auto/feature + +_NCHAN_SUBSCRIBERS_SRCS="\ + ${ngx_addon_dir}/src/subscribers/common.c \ + ${ngx_addon_dir}/src/subscribers/longpoll.c \ + ${ngx_addon_dir}/src/subscribers/intervalpoll.c \ + ${ngx_addon_dir}/src/subscribers/eventsource.c \ + ${ngx_addon_dir}/src/subscribers/http-chunked.c \ + ${ngx_addon_dir}/src/subscribers/http-multipart-mixed.c \ + ${ngx_addon_dir}/src/subscribers/http-raw-stream.c \ + ${ngx_addon_dir}/src/subscribers/websocket.c \ + ${ngx_addon_dir}/src/nchan_websocket_publisher.c \ + ${ngx_addon_dir}/src/subscribers/internal.c \ + ${ngx_addon_dir}/src/subscribers/memstore_ipc.c \ + ${ngx_addon_dir}/src/subscribers/memstore_multi.c \ + ${ngx_addon_dir}/src/subscribers/memstore_redis.c \ + ${ngx_addon_dir}/src/subscribers/getmsg_proxy.c \ + ${ngx_addon_dir}/src/subscribers/benchmark.c \ +" + +_NCHAN_REDIS_STORE_SRCS="\ + ${_NCHAN_HIREDIS_SRCS} \ + ${ngx_addon_dir}/src/store/redis/cmp.c \ + ${ngx_addon_dir}/src/store/redis/redis_lua_commands.c \ + ${ngx_addon_dir}/src/store/redis/redis_nodeset_parser.c \ + ${ngx_addon_dir}/src/store/redis/redis_nodeset.c \ + ${ngx_addon_dir}/src/store/redis/rdsstore.c \ + ${ngx_addon_dir}/src/store/redis/redis_nginx_adapter.c \ +" +_NCHAN_MEMORY_STORE_SRCS="\ + ${ngx_addon_dir}/src/store/memory/ipc.c \ + ${ngx_addon_dir}/src/store/memory/ipc-handlers.c \ + ${ngx_addon_dir}/src/store/memory/groups.c \ + ${ngx_addon_dir}/src/store/memory/memstore.c \ +" + +_nchan_util_dir="${ngx_addon_dir}/src/util" +_NCHAN_UTIL_SRCS=" \ + $_nchan_util_dir/nchan_debug.c \ + $_nchan_util_dir/nchan_list.c \ + $_nchan_util_dir/nchan_slist.c \ + $_nchan_util_dir/ngx_nchan_hacked_slab.c \ + $_nchan_util_dir/shmem.c \ + $_nchan_util_dir/nchan_rbtree.c \ + $_nchan_util_dir/nchan_reuse_queue.c \ + $_nchan_util_dir/nchan_output.c \ + $_nchan_util_dir/nchan_util.c \ + $_nchan_util_dir/nchan_fake_request.c \ + $_nchan_util_dir/nchan_bufchainpool.c \ + $_nchan_util_dir/nchan_channel_id.c \ + $_nchan_util_dir/nchan_output_info.c \ + $_nchan_util_dir/nchan_msg.c \ + $_nchan_util_dir/nchan_thingcache.c \ + $_nchan_util_dir/nchan_reaper.c \ + $_nchan_util_dir/nchan_subrequest.c \ + $_nchan_util_dir/nchan_benchmark.c \ + $_nchan_util_dir/hdr_histogram.c \ +" + +_NCHAN_STORE_SRCS="\ + ${ngx_addon_dir}/src/store/spool.c \ + ${ngx_addon_dir}/src/store/ngx_rwlock.c \ + ${ngx_addon_dir}/src/store/store_common.c \ + $_NCHAN_MEMORY_STORE_SRCS \ + $_NCHAN_REDIS_STORE_SRCS \ +" + +_NCHAN_SRCS="\ + ${ngx_addon_dir}/src/nchan_defs.c \ + ${ngx_addon_dir}/src/nchan_variables.c \ + ${ngx_addon_dir}/src/nchan_module.c \ + $_NCHAN_UTIL_SRCS \ + $_NCHAN_SUBSCRIBERS_SRCS \ + $_NCHAN_STORE_SRCS \ +" + +ngx_module_incs=$ngx_addon_dir/src + +have=NGX_HTTP_HEADERS . auto/have + +if test -n "$ngx_module_link"; then + ngx_module_type=HTTP + ngx_module_name=$ngx_addon_name + ngx_module_srcs="$_NCHAN_SRCS" + ngx_module_libs=$nchan_libs + . auto/module +else + NGX_ADDON_SRCS="$NGX_ADDON_SRCS $_NCHAN_SRCS" + CORE_LIBS="$CORE_LIBS $nchan_libs" + CORE_INCS="$CORE_INCS $ngx_module_incs" + HTTP_MODULES="$HTTP_MODULES $ngx_addon_name" +fi diff -Nru nginx-1.19.4/debian/modules/nchan/LICENCE nginx-1.19.5/debian/modules/nchan/LICENCE --- nginx-1.19.4/debian/modules/nchan/LICENCE 1970-01-01 00:00:00.000000000 +0000 +++ nginx-1.19.5/debian/modules/nchan/LICENCE 2020-11-26 10:08:15.000000000 +0000 @@ -0,0 +1,24 @@ +This work is distributed under the MIT Licence. + +Written by Leo Ponomarev (slact) 2009-2015. + +Permission is hereby granted, free of charge, to any person +obtaining a copy of this software and associated documentation +files (the "Software"), to deal in the Software without +restriction, including without limitation the rights to use, +copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following +conditions: + +The above authorship notice and this permission notice shall be +included in all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES +OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND +NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT +HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, +WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR +OTHER DEALINGS IN THE SOFTWARE. diff -Nru nginx-1.19.4/debian/modules/nchan/README.md nginx-1.19.5/debian/modules/nchan/README.md --- nginx-1.19.4/debian/modules/nchan/README.md 1970-01-01 00:00:00.000000000 +0000 +++ nginx-1.19.5/debian/modules/nchan/README.md 2020-11-26 10:08:15.000000000 +0000 @@ -0,0 +1,1457 @@ + + +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 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](#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](#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 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. + +#### 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.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 + +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](#redis-cluster). + + +## Install + +#### Download Packages + - [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 +Grab the latest copy of Nginx from [nginx.org](http://nginx.org). Grab the latest Nchan source from [github](https://github.com/slact/nchan/releases). Follow the instructions for [building Nginx](https://www.nginx.com/resources/wiki/start/topics/tutorials/install/#source-releases), except during the `configure` stage, add +``` +./configure --add-module=path/to/nchan ... +``` + +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`, then `make install`. + +## Getting Started + +Once you've built and installed Nchan, it's very easy to start using. Add two locations to your nginx config: + +```nginx +#... +http { + server { + #... + + location = /sub { + nchan_subscriber; + nchan_channel_id $arg_id; + } + + location = /pub { + nchan_publisher; + nchan_channel_id $arg_id; + } + } +} +``` + +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 + +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? + +Well... the trouble is that nginx configuration does not deal with channels, publishers, and subscribers. Rather, it has several sections for incoming requests to match against *server* and *location* sections. **Nchan configuration directives map servers and locations onto channel publishing and subscribing endpoints**: + +```nginx +#very basic nchan config +worker_processes 5; + +http { + server { + listen 80; + + location = /sub { + nchan_subscriber; + nchan_channel_id foobar; + } + + location = /pub { + nchan_publisher; + nchan_channel_id foobar; + } + } +} +``` + +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 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 + +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`: + +```console +> curl --request POST --data "test message" http://127.0.0.1:80/pub + + queued messages: 5 + last requested: 18 sec. ago + active subscribers: 0 + last message id: 1450755280:0 +``` + +The response can be in plaintext (as above), JSON, or XML, based on the request's *`Accept`* header: + +```console +> curl --request POST --data "test message" -H "Accept: text/json" http://127.0.0.2:80/pub + + {"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. + +The response code for an HTTP request is *`202` Accepted* if no subscribers are present at time of publication, or *`201` Created* if at least 1 subscriber was present. + +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 + +**HTTP `GET`** requests return channel information without publishing a message. The response code is `200` if the channel exists, and `404` otherwise: +```console +> curl --request POST --data "test message" http://127.0.0.2:80/pub + ... + +> curl -v --request GET -H "Accept: text/json" http://127.0.0.2:80/pub + + {"messages": 1, "requested": 7, "subscribers": 0, "last_message_id": "1450755421:0" } +``` + + +**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. + +### 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*. + +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). + +```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. + Sending a request without a "`If-Modified-Since`" or "`If-None-Match`" headers returns the oldest message in a channel's message queue, or waits until the next published message, depending on the value of the `nchan_subscriber_first_message` config directive. + A message's associated content type, if present, will be sent to this subscriber with the `Content-Type` header. + + +- ### Interval-Polling + Works just like long-polling, except if the requested message is not yet available, immediately responds with a `304 Not Modified`. + 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 + 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. + 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
+  content-type: message_content_type
+  \n
+  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 + 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: `. + To resume a closed EventSource connection from the last-received message, one *should* start the connection with the "`Last-Event-ID`" header set to the last message's `id`. + Unfortunately, browsers [don't support setting](http://www.w3.org/TR/2011/WD-eventsource-20111020/#concept-event-stream-last-event-id) this header for an `EventSource` object, so by default the last message id is set either from the "`Last-Event-Id`" header or the `last_event_id` url query string argument. + This behavior can be configured via the [`nchan_subscriber_last_message_id`](#nchan_subscriber_last_message_id) config. + A message's `content-type` will not be received by an EventSource subscriber, as the protocol makes no provisions for this metadata. + 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) + 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. + Each message is terminated with the next multipart message's boundary **without a trailing newline**. While this conforms to the multipart spec, it is unusual as multipart messages are defined as *starting*, rather than ending with a boundary. + A message's associated content type, if present, will be sent to this subscriber with the `Content-Type` header. + + +- ### 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) + 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) + The response headers are sent right away, and each message will be sent as an individual chunk. Note that because a zero-length chunk terminates the transfer, **zero-length messages will not be sent** to the subscriber. + Unlike the other subscriber types, the `chunked` subscriber cannot be used with http/2 because it dissallows chunked encoding. + + +## PubSub Endpoint + +PubSub endpoints are Nginx config *locations* with the [*`nchan_pubsub`*](#nchan_pubsub) directive. + +A combination of *publisher* and *subscriber* endpoints, this location treats all HTTP `GET` +requests as subscribers, and all HTTP `POST` as publishers. One simple use case is an echo server: + +```nginx + location = /pubsub { + nchan_pubsub; + nchan_channel_id foo; + nchan_channel_group test; + } +``` + +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; + } +``` + +Here, subscribers will listen for messages on channel `foo`, and publishers will publish messages to channel `bar`. This can be useful when setting up websocket proxying between web clients and your application. + + + +## The Channel ID + +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 { + #channel id is the subscriber's IP address + nchan_subscriber; + nchan_channel_id $remote_addr; + } + + location /sub_by_querystring { + #channel id is the query string parameter chanid + # GET /sub/sub_by_querystring?foo=bar&chanid=baz will have the channel id set to 'baz' + nchan_subscriber; + nchan_channel_id $arg_chanid; + } + + location ~ /sub/(\w+)$ { + #channel id is the word after /sub/ + # GET /sub/foobar_baz will have the channel id set to 'foobar_baz' + # I hope you know your regular expressions... + nchan_subscriber; + nchan_channel_id $1; #first capture of the location match + } +``` + +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 + +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: + +Up to 7 channel ids can be specified for the `nchan_channel_id` or `nchan_channel_subscriber_id` config directive: + +```nginx + location ~ /multisub/(\w+)/(\w+)$ { + nchan_subscriber; + nchan_channel_id "$1" "$2" "common_channel"; + #GET /multisub/foo/bar will be subscribed to: + # channels 'foo', 'bar', and 'common_channel', + #and will receive messages from all of the above. + } +``` + +For more than 7 channels, `nchan_channel_id_split_delimiter` can be used to split the `nchan_channel_id` or `nchan_channel_subscriber_id` into up to 255 individual channel ids: + +```nginx + location ~ /multisub-split/(.*)$ { + nchan_subscriber; + nchan_channel_id "$1"; + nchan_channel_id_split_delimiter ","; + #GET /multisub-split/foo,bar,baz,a will be subscribed to: + # channels 'foo', 'bar', 'baz', and 'a' + #and will receive messages from all of the above. + } +``` + +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' + } +``` + +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 [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 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 + +[Redis](http://redis.io) can be used to add **data persistence** and **horizontal scalability**, **failover** and **high availability** to your Nchan setup. + + + +#### 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; + } + } +} +``` + + + +##### 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. + +### 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/(.+)$ { + 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_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
+ + +``` + +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. + +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. + +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: + +- `$nchan_channel_id` + The channel id extracted from a publisher or subscriber location request. For multiplexed locations, this is the first channel id in the list. + +- `$nchan_channel_id1`, `$nchan_channel_id2`, `$nchan_channel_id3`, `$nchan_channel_id4` + As above, but for the nth channel id in multiplexed channels. + +- `$nchan_subscriber_type` + For subscriber locations, this variable is set to the subscriber type (websocket, longpoll, etc.). + +- `$nchan_publisher_type` + 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: + +- `$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` + + +## Configuration Directives + +- **nchan_channel_id** + arguments: 1 - 7 + default: `(none)` + context: server, location, if + > Channel id for a publisher or subscriber location. Can have up to 4 values to subscribe to up to 4 channels. + [more details](#the-channel-id) + +- **nchan_channel_id_split_delimiter** + arguments: 1 + default: `(none)` + context: server, location, if + > 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` + context: server, location, if + legacy name: push_publisher + > Defines a server or location as a publisher endpoint. Requests to a publisher location are treated as messages to be sent to subscribers. See the protocol documentation for a detailed description. + [more details](#publisher-endpoints) + +- **nchan_publisher_channel_id** + arguments: 1 - 7 + default: `(none)` + context: server, location, if + > Channel id for publisher location. + +- **nchan_publisher_upstream_request** `` + arguments: 1 + 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](#message-forwarding) + +- **nchan_pubsub** `[ http | websocket | eventsource | longpoll | intervalpoll | chunked | multipart-mixed | http-raw-stream ]` + arguments: 0 - 6 + default: `http websocket eventsource longpoll chunked multipart-mixed` + context: server, location, if + > 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` + context: server, location, if + legacy name: push_subscriber + > Defines a server or location as a channel subscriber endpoint. This location represents a subscriber's interface to a channel's message queue. The queue is traversed automatically, starting at the position defined by the `nchan_subscriber_first_message` setting. + > The value is a list of permitted subscriber types. + [more details](#subscriber-endpoints) + +- **nchan_subscriber_channel_id** + arguments: 1 - 7 + default: `(none)` + context: server, location, if + > Channel id for subscriber location. Can have up to 4 values to subscribe to up to 4 channels. + +- **nchan_subscriber_compound_etag_message_id** + arguments: 1 + default: `off` + context: server, location, if + > Override the default behavior of using both `Last-Modified` and `Etag` headers for the message id. + > Enabling this option packs the entire message id into the `Etag` header, and discards + > `Last-Modified` and `If-Modified-Since` headers. + [more details]() + +- **nchan_subscriber_first_message** `[ oldest | newest | ]` + arguments: 1 + default: `oldest` + context: server, location, if + > Controls the first message received by a new subscriber. 'oldest' starts at the oldest available message in a channel's message queue, 'newest' waits until a message arrives. If a number `n` is specified, starts at `n`th message from the oldest. (`-n` starts at `n`th from now). 0 is equivalent to 'newest'. + +- **nchan_subscriber_http_raw_stream_separator** `` + arguments: 1 + default: `\n` + context: server, location, if + > Message separator string for the http-raw-stream subscriber. Automatically terminated with a newline character. + +- **nchan_subscriber_last_message_id** + arguments: 1 - 5 + default: `$http_last_event_id $arg_last_event_id` + context: server, location, if + > If `If-Modified-Since` and `If-None-Match` headers are absent, set the message id to the first non-empty of these values. Used primarily as a workaround for the inability to set the first `Last-Message-Id` of a web browser's EventSource object. + +- **nchan_subscriber_message_id_custom_etag_header** + arguments: 1 + default: `(none)` + context: server, location, if + > Use a custom header instead of the Etag header for message ID in subscriber responses. This setting is a hack, useful when behind a caching proxy such as Cloudflare that under some conditions (like using gzip encoding) swallow the Etag header. + +- **nchan_subscriber_timeout** ` (seconds)` + arguments: 1 + default: `0 (none)` + context: http, server, location, if + 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](#request-authorization) + +- **nchan_channel_group** `` + arguments: 1 + default: `(none)` + context: server, location, if + 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_channel_group_accounting** + arguments: 1 + 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_group_max_channels** `` + arguments: 1 + 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 + default: `10` + context: http, server, location + 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** `[