{"id":13500042,"url":"https://github.com/slact/nchan","last_synced_at":"2025-12-16T20:04:15.051Z","repository":{"id":633339,"uuid":"274218","full_name":"slact/nchan","owner":"slact","description":"Fast, horizontally scalable, multiprocess pub/sub queuing server and proxy for HTTP, long-polling, Websockets and EventSource (SSE), powered by Nginx.","archived":false,"fork":false,"pushed_at":"2025-08-19T01:56:39.000Z","size":8196,"stargazers_count":3060,"open_issues_count":125,"forks_count":294,"subscribers_count":112,"default_branch":"master","last_synced_at":"2025-12-03T06:46:41.820Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://nchan.io/","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/slact.png","metadata":{"files":{"readme":"README.md","changelog":"changelog.txt","contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2009-08-10T18:38:01.000Z","updated_at":"2025-11-14T21:32:38.000Z","dependencies_parsed_at":"2023-07-09T16:32:09.582Z","dependency_job_id":"210610b6-7f3f-4f29-82ec-ba1aa797f1fa","html_url":"https://github.com/slact/nchan","commit_stats":{"total_commits":3498,"total_committers":41,"mean_commits":85.3170731707317,"dds":"0.030017152658662116","last_synced_commit":"b4d6b42fea761af0ff06dce990f0caa11a7e8132"},"previous_names":["slact/nginx_http_push_module"],"tags_count":93,"template":false,"template_full_name":null,"purl":"pkg:github/slact/nchan","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slact%2Fnchan","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slact%2Fnchan/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slact%2Fnchan/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slact%2Fnchan/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/slact","download_url":"https://codeload.github.com/slact/nchan/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/slact%2Fnchan/sbom","scorecard":{"id":830955,"data":{"date":"2025-08-11","repo":{"name":"github.com/slact/nchan","commit":"9c6909d0a4c4611479b7182ac29b2065a5845614"},"scorecard":{"version":"v5.2.1-40-gf6ed084d","commit":"f6ed084d17c9236477efd66e5b258b9d4cc7b389"},"score":3.1,"checks":[{"name":"Dangerous-Workflow","score":-1,"reason":"no workflows found","details":null,"documentation":{"short":"Determines if the project's GitHub Action workflows avoid dangerous patterns.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#dangerous-workflow"}},{"name":"Code-Review","score":2,"reason":"Found 6/22 approved changesets -- score normalized to 2","details":null,"documentation":{"short":"Determines if the project requires human code review before pull requests (aka merge requests) are merged.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#code-review"}},{"name":"Maintained","score":1,"reason":"0 commit(s) and 2 issue activity found in the last 90 days -- score normalized to 1","details":null,"documentation":{"short":"Determines if the project is \"actively maintained\".","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#maintained"}},{"name":"Packaging","score":-1,"reason":"packaging workflow not detected","details":["Warn: no GitHub/GitLab publishing workflow detected."],"documentation":{"short":"Determines if the project is published as a package that others can easily download, install, easily update, and uninstall.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#packaging"}},{"name":"Token-Permissions","score":-1,"reason":"No tokens found","details":null,"documentation":{"short":"Determines if the project's workflows follow the principle of least privilege.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#token-permissions"}},{"name":"Binary-Artifacts","score":10,"reason":"no binaries found in the repo","details":null,"documentation":{"short":"Determines if the project has generated executable (binary) artifacts in the source repository.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#binary-artifacts"}},{"name":"Pinned-Dependencies","score":0,"reason":"dependency not pinned by hash detected -- score normalized to 0","details":["Info: Possibly incomplete results: error parsing shell code: \"}\" can only be used to close a block: dev/dev.conf:0","Info: Possibly incomplete results: error parsing shell code: \"}\" can only be used to close a block: dev/nginx.conf:0","Warn: pipCommand not pinned by hash: dev/python_check.sh:21","Info:   0 out of   1 pipCommand dependencies pinned"],"documentation":{"short":"Determines if the project has declared and pinned the dependencies of its build process.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#pinned-dependencies"}},{"name":"CII-Best-Practices","score":0,"reason":"no effort to earn an OpenSSF best practices badge detected","details":null,"documentation":{"short":"Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#cii-best-practices"}},{"name":"Security-Policy","score":0,"reason":"security policy file not detected","details":["Warn: no security policy file detected","Warn: no security file to analyze","Warn: no security file to analyze","Warn: no security file to analyze"],"documentation":{"short":"Determines if the project has published a security policy.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#security-policy"}},{"name":"Fuzzing","score":0,"reason":"project is not fuzzed","details":["Warn: no fuzzer integrations found"],"documentation":{"short":"Determines if the project uses fuzzing.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#fuzzing"}},{"name":"License","score":9,"reason":"license file detected","details":["Info: project has a license file: LICENCE:0","Warn: project license file does not contain an FSF or OSI license."],"documentation":{"short":"Determines if the project has defined a license.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#license"}},{"name":"Vulnerabilities","score":10,"reason":"0 existing vulnerabilities detected","details":null,"documentation":{"short":"Determines if the project has open, known unfixed vulnerabilities.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#vulnerabilities"}},{"name":"Signed-Releases","score":-1,"reason":"no releases found","details":null,"documentation":{"short":"Determines if the project cryptographically signs release artifacts.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#signed-releases"}},{"name":"Branch-Protection","score":0,"reason":"branch protection not enabled on development/release branches","details":["Warn: branch protection not enabled for branch 'master'"],"documentation":{"short":"Determines if the default and release branches are protected with GitHub's branch protection settings.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#branch-protection"}},{"name":"SAST","score":0,"reason":"SAST tool is not run on all commits -- score normalized to 0","details":["Warn: 0 commits out of 14 are checked with a SAST tool"],"documentation":{"short":"Determines if the project uses static code analysis.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#sast"}}]},"last_synced_at":"2025-08-23T17:47:30.792Z","repository_id":633339,"created_at":"2025-08-23T17:47:30.792Z","updated_at":"2025-08-23T17:47:30.792Z"},"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":27621682,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-12-09T02:00:09.185Z","response_time":54,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-31T22:00:50.247Z","updated_at":"2025-12-16T20:04:15.008Z","avatar_url":"https://github.com/slact.png","language":"C","readme":"\u003cimg class=\"logo\" alt=\"NCHAN\" src=\"https://nchan.io/github-logo.png\" /\u003e\n\nhttps://nchan.io\n\nNchan 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).\n\nMessages 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).\n\nIn 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).\n\n## Features\n - RESTful, HTTP-native [API](#publishing-messages).\n - Supports [Websocket](#websocket), [EventSource (Server-Sent Events)](#eventsource), [Long-Polling](#long-polling) and other HTTP-based subscribers.\n - Per-channel configurable message buffers with no-repeat, no-loss message delivery guarantees.\n - Subscribe to [hundreds of channels](#channel-multiplexing) over a single subscriber connection.\n - HTTP request [callbacks and hooks](#hooks-and-callbacks) for easy integration.\n - Introspection with [channel events](#channel-events) and [url for monitoring performance statistics](#nchan_stub_status-stats).\n - Channel [group](#channel-groups) usage [accounting and limits](#limits-and-accounting).\n - Fast, nonblocking [shared-memory local message storage](#memory-storage) and optional, slower, persistent storage with [Redis](#redis).\n - Horizontally scalable (using [Redis](#redis)).\n - Auto-failover and [high availability](#high-availability) with no single point of failure using [Redis Cluster](#redis-cluster).\n\n## Status and History\n\nThe latest Nchan release is 1.3.7 (September 19, 2024) ([changelog](https://nchan.io/changelog)).\n\nThe 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.\n\n#### Upgrade from Nginx HTTP Push Module\n\nAlthough 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.\n\n\n## Does it scale?\n\n\u003cimg class=\"benchmark_graph\" alt=\"benchmarking internal subscriber response times\" src=\"https://nchan.io/img/benchmark_internal_total.png\" /\u003e\n\nYes 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.\n\nWith 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).\n\n\n## Install\n\n#### Download Packages\n - [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.\n - Mac OS X: a [homebrew](http://brew.sh) package is available. `brew tap denji/nginx; brew install nginx-full --with-nchan-module`\n - [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).  \n 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`.\n - [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?...\n - [Fedora](https://fedoraproject.org): Dynamic module builds for Nginx \u003e 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). \n - [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).\n - 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).\n\n\n#### Build From Source\nGrab 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\n```\n./configure --add-module=path/to/nchan ...\n```\n\nIf you're using Nginx  \u003e 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`\n\nRun `make`, then `make install`.\n\n## Getting Started\n\nOnce you've built and installed Nchan, it's very easy to start using. Add two locations to your nginx config:\n\n```nginx\n#...\nhttp {  \n  server {\n    #...\n    \n    location = /sub {\n      nchan_subscriber;\n      nchan_channel_id $arg_id;\n    }\n    \n    location = /pub {\n      nchan_publisher;\n      nchan_channel_id $arg_id;\n    }\n  }\n}\n```\n\nYou 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.\n\nBut Nchan is very flexible and highly configurable. So, of course, it can get a lot more complicated...\n\n### Conceptual Overview\n\nThe 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? \n\nWell... 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**:\n\n```nginx\n#very basic nchan config\nworker_processes 5;\n\nhttp {  \n  server {\n    listen       80;\n    \n    location = /sub {\n      nchan_subscriber;\n      nchan_channel_id foobar;\n    }\n    \n    location = /pub {\n      nchan_publisher;\n      nchan_channel_id foobar;\n    }\n  }\n}\n```\n\nThe above maps requests to the URI `/sub` onto the channel `foobar`'s *subscriber endpoint* , and similarly `/pub` onto channel `foobar`'s *publisher endpoint*.\n\n\n## Publisher Endpoints\n\nPublisher endpoints are Nginx config *locations* with the [*`nchan_publisher`*](#nchan_publisher) directive.\n\nMessages 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.\n\n```nginx\n  location /pub {\n    #example publisher location\n    nchan_publisher;\n    nchan_channel_id foo;\n    nchan_channel_group test;\n    nchan_message_buffer_length 50;\n    nchan_message_timeout 5m;\n  }\n```\n\n\u003c!-- tag:publisher --\u003e\n\n### Publishing Messages\n\nRequests and websocket messages are responded to with information about the channel at time of message publication. Here's an example from publishing with `curl`:\n\n```console\n\u003e  curl --request POST --data \"test message\" http://127.0.0.1:80/pub\n\n queued messages: 5\n last requested: 18 sec. ago\n active subscribers: 0\n last message id: 1450755280:0\n```\n\nThe response can be in plaintext (as above), JSON, or XML, based on the request's *`Accept`* header:\n\n```console\n\u003e curl --request POST --data \"test message\" -H \"Accept: text/json\" http://127.0.0.2:80/pub\n\n {\"messages\": 5, \"requested\": 18, \"subscribers\": 0, \"last_message_id\": \"1450755280:0\" }\n```\n\nWebsocket publishers also receive the same responses when publishing, with the encoding determined by the *`Accept`* header present during the handshake.\n\nThe 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.\n\nMetadata 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.\n\n### Other Publisher Endpoint Actions\n\n**HTTP `GET`** requests return channel information without publishing a message. The response code is `200` if the channel exists, and `404` otherwise:  \n```console\n\u003e curl --request POST --data \"test message\" http://127.0.0.2:80/pub\n  ...\n\n\u003e curl -v --request GET -H \"Accept: text/json\" http://127.0.0.2:80/pub\n\n {\"messages\": 1, \"requested\": 7, \"subscribers\": 0, \"last_message_id\": \"1450755421:0\" }\n```\n\n\n**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.\n\n### How Channel Settings Work\n\n*A channel's configuration is set to the that of its last-used publishing location.*\nSo, 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*.\n\nYou 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.\n\n## Subscriber Endpoints\n\nSubscriber endpoints are Nginx config *locations* with the [*`nchan_subscriber`*](#nchan_subscriber) directive.\n\nNchan 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).\n\n```nginx\n  location /sub {\n    #example subscriber location\n    nchan_subscriber;\n    nchan_channel_id foo;\n    nchan_channel_group test;\n    nchan_subscriber_first_message oldest;\n  }\n```\n\n\u003c!-- tag:subscriber --\u003e\n\n- ### Long-Polling\n  The tried-and-true server-push method supported by every browser out there.  \n  Initiated by sending an HTTP `GET` request to a channel subscriber endpoint.  \n  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.  \n  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.  \n  A message's associated content type, if present, will be sent to this subscriber with the `Content-Type` header.\n  \u003c!-- tag:subscriber-longpoll --\u003e\n  \n- ### Interval-Polling\n  Works just like long-polling, except if the requested message is not yet available, immediately responds with a `304 Not Modified`.\n  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.\n\n- ### Websocket\n  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)).  \n  Initiated by sending a websocket handshake to the desired subscriber endpoint location.  \n  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.\n  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.\n  \u003cbr /\u003e\n  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\n  \u003cpre\u003e\n  id: message_id\n  content-type: message_content_type\n  \\n\n  message_data\n  \u003c/pre\u003e   \n  The `content-type:` line may be omitted.\n  \u003cbr /\u003e\n  #### Websocket Publisher\n  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.   \n  Messages published in a binary frame are automatically given the `content-type` \"`application/octet-stream`\".\n  #### Permessage-deflate\n  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.\n  \u003cbr /\u003e\n  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`.\n  \u003cbr /\u003e\n  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),\n  [`nchan_permessage_deflate_compression_strategy`](#nchan_permessage_deflate_compression_strategy), and \n  [`nchan_permessage_deflate_compression_window`](#nchan_permessage_deflate_compression_window) settings.\n  \u003cbr /\u003e\n  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`.\n  \u003cbr /\u003e\n  \u003c!-- tag:subscriber-websocket --\u003e\n  \n- ### EventSource\n  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).  \n  Initiated by sending an HTTP `GET` request to a channel subscriber endpoint with the \"`Accept: text/event-stream`\" header.    \n  Each message `data: ` segment will be prefaced by the message `id: `.  \n  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`.  \n  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.  \n  This behavior can be configured via the [`nchan_subscriber_last_message_id`](#nchan_subscriber_last_message_id) config.  \n  A message's `content-type` will not be received by an EventSource subscriber, as the protocol makes no provisions for this metadata.\n  A message's associated `event` type, if present, will be sent to this subscriber with the `event:` line.  \n  \u003c!-- tag:subscriber-eventsource --\u003e\n  \n- ### HTTP [multipart/mixed](http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html#z0)\n  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.  \n  Initiated by including an `Accept: multipart/mixed` header.  \n  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.  \n  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.  \n  A message's associated content type, if present, will be sent to this subscriber with the `Content-Type` header.\n  \u003c!-- tag:subscriber-multipart --\u003e\n  \n- ### HTTP Raw Stream\n  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`.\n  \u003c!-- tag:subscriber-rawstream --\u003e\n\n- ### HTTP [Chunked Transfer](http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1)\n  This subscription method uses the `chunked` `Transfer-Encoding` to receive messages.   \n  Initiated by explicitly including `chunked` in the [`TE` header](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.39):  \n  `TE: chunked` (or `TE: chunked;q=??` where the qval \u003e 0)  \n  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.  \n  Unlike the other subscriber types, the `chunked` subscriber cannot be used with http/2 because it disallows chunked encoding.\n  \u003c!-- tag:subscriber-chunked --\u003e\n\n## PubSub Endpoint  \n\nPubSub endpoints are Nginx config *locations* with the [*`nchan_pubsub`*](#nchan_pubsub) directive.\n\nA combination of *publisher* and *subscriber* endpoints, this location treats all HTTP `GET`\nrequests as subscribers, and all HTTP `POST` as publishers. Channels cannot be deleted through a pubsub endpoing with an HTTP `DELETE` request.\n\nOne simple use case is an echo server:\n\n```nginx\n  location = /pubsub {\n    nchan_pubsub;\n    nchan_channel_id foo;\n    nchan_channel_group test;\n  }\n```\n\nA more interesting setup may set different publisher and subscriber channel ids:\n\n```nginx\n  location = /pubsub {\n    nchan_pubsub;\n    nchan_publisher_channel_id foo;\n    nchan_subscriber_channel_id bar;\n    nchan_channel_group test;\n  }\n```\n\nHere, 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.\n\u003c!-- tag:pubsub --\u003e\n\n## The Channel ID\n\nSo 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:\n\n```nginx\n  location = /sub_by_ip {\n    #channel id is the subscriber's IP address\n    nchan_subscriber;\n    nchan_channel_id $remote_addr;\n  }\n  \n  location /sub_by_querystring {\n    #channel id is the query string parameter chanid\n    # GET /sub/sub_by_querystring?foo=bar\u0026chanid=baz will have the channel id set to 'baz'\n    nchan_subscriber;\n    nchan_channel_id $arg_chanid;\n  }\n\n  location ~ /sub/(\\w+)$ {\n    #channel id is the word after /sub/\n    # GET /sub/foobar_baz will have the channel id set to 'foobar_baz'\n    # I hope you know your regular expressions...\n    nchan_subscriber;\n    nchan_channel_id $1; #first capture of the location match\n  }\n```\n\nI recommend using the last option, a channel id derived from the request URL via a regular expression. It makes things nice and RESTful.\n\n\u003c!-- tag:channel-id --\u003e\n\n### Channel Multiplexing\n\nWith 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:\n\nUp to 7 channel ids can be specified for the `nchan_channel_id` or `nchan_channel_subscriber_id` config directive:\n\n```nginx\n  location ~ /multisub/(\\w+)/(\\w+)$ {\n    nchan_subscriber;\n    nchan_channel_id \"$1\" \"$2\" \"common_channel\";\n    #GET /multisub/foo/bar will be subscribed to:\n    # channels 'foo', 'bar', and 'common_channel',\n    #and will receive messages from all of the above.\n  }\n```\n\nFor 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:\n\n```nginx\n  location ~ /multisub-split/(.*)$ {\n    nchan_subscriber;\n    nchan_channel_id \"$1\";\n    nchan_channel_id_split_delimiter \",\";\n    #GET /multisub-split/foo,bar,baz,a will be subscribed to:\n    # channels 'foo', 'bar', 'baz', and 'a'\n    #and will receive messages from all of the above.\n  }\n```\n\nIt 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:\n\n```nginx\n  location ~ /multipub/(\\w+)/(\\w+)$ {\n    nchan_publisher;\n    nchan_channel_id \"$1\" \"$2\" \"another_channel\";\n    #POST /multipub/foo/bar will publish to:\n    # channels 'foo', 'bar', 'another_channel'\n    #DELETE /multipub/foo/bar will delete:\n    # channels 'foo', 'bar', 'another_channel'\n  }\n```\n\nWhen 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.\n\nSee the [Channel Security](#securing-channels) section about using good IDs and keeping private channels secure.\n\n\u003c!-- tag:channel-multiplexing --\u003e\n\n### Channel Groups\n\nChannels can be associated with groups to avoid channel ID conflicts:\n\n```nginx\n  location /test_pubsub {\n    nchan_pubsub;\n    nchan_channel_group \"test\";\n    nchan_channel_id \"foo\";\n  }\n  \n  location /pubsub {\n    nchan_pubsub;\n    nchan_channel_group \"production\";\n    nchan_channel_id \"foo\";\n    #same channel id, different channel group. Thus, different channel.\n  }\n  \n  location /flexgroup_pubsub {\n    nchan_pubsub;\n    nchan_channel_group $arg_group;\n    nchan_channel_id \"foo\";\n    #group can be set with request variables too\n  }\n```\n\n#### Limits and Accounting\n\nGroups can be used to track aggregate channel usage, as well as set limits on the number of channels, subscribers, stored messages, memory use, etc:\n\n```nginx\n  #enable group accounting\n  nchan_channel_group_accounting on;\n  \n  location ~ /pubsub/(\\w+)$ {\n    nchan_pubsub;\n    nchan_channel_group \"limited\";\n    nchan_channel_id $1;\n  }\n  \n  location ~ /prelimited_pubsub/(\\w+)$ {\n    nchan_pubsub;\n    nchan_channel_group \"limited\";\n    nchan_channel_id $1;\n    nchan_group_max_subscribers 100;\n    nchan_group_max_messages_memory 50M;\n  }\n  \n  location /group {\n    nchan_channel_group limited;\n    nchan_group_location;\n    nchan_group_max_channels $arg_max_channels;\n    nchan_group_max_messages $arg_max_messages;\n    nchan_group_max_messages_memory $arg_max_messages_mem;\n    nchan_group_max_messages_disk $arg_max_messages_disk;\n    nchan_group_max_subscribers $arg_max_subs;\n  }\n```\n\nHere, `/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`:\n\n```sh\n\u003e  curl http://localhost/group\n\nchannels: 10\nsubscribers: 0\nmessages: 219\nshared memory used by messages: 42362 bytes\ndisk space used by messages: 0 bytes\nlimits:\n  max channels: 0\n  max subscribers: 0\n  max messages: 0\n  max messages shared memory: 0\n  max messages disk space: 0  \n```\n\nBy default, the data is returned in human-readable plaintext, but can also be formatted as JSON, XML, or YAML:\n\n```sh\n\u003e  curl -H \"Accept: text/json\" http://localhost/group\n\n{\n  \"channels\": 21,\n  \"subscribers\": 40,\n  \"messages\": 53,\n  \"messages_memory\": 19941,\n  \"messages_disk\": 0,\n  \"limits\": {\n    \"channels\": 0,\n    \"subscribers\": 0,\n    \"messages\": 0,\n    \"messages_memory\": 0,\n    \"messages_disk\": 0\n  }\n}\n```\n\nThe data in the response are for the single Nchan instance only, regardless of whether Redis is used. A limit of 0 means 'unlimited'.\n\nLimits can be set per-location, as with the above `/prelimited_pubsub/...` location, or with a POST request to the `nchan_group_location`:\n```sh\n\u003e  curl -X POST \"http://localhost/group?max_channels=15\u0026max_subs=1000\u0026max_messages_disk=0.5G\"\n\nchannels: 0\nsubscribers: 0\nmessages: 0\nshared memory used by messages: 0 bytes\ndisk space used by messages: 0 bytes\nlimits:\n  max channels: 15\n  max subscribers: 1000\n  max messages: 0\n  max messages shared memory: 0\n  max messages disk space: 536870912\n\n```\n\nLimits are only applied locally, regardless of whether Redis is enabled. \nIf a publisher or subscriber request exceeds a group limit, Nchan will respond to it with a `403 Forbidden` response.\n\n\u003c!-- tag:group --\u003e\n\n## Hooks and Callbacks\n\n\u003c!-- tag:hook --\u003e\n  \n### Request Authorization\n\nThis 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).\n\nConsider the configuration:\n```nginx\n  upstream my_app {\n    server 127.0.0.1:8080;\n  }\n  location = /auth {\n    proxy_pass http://my_app/pubsub_authorize;\n    proxy_pass_request_body off;\n    proxy_set_header Content-Length \"\";\n    proxy_set_header X-Subscriber-Type $nchan_subscriber_type;\n    proxy_set_header X-Publisher-Type $nchan_publisher_type;\n    proxy_set_header X-Prev-Message-Id $nchan_prev_message_id;\n    proxy_set_header X-Channel-Id $nchan_channel_id;\n    proxy_set_header X-Original-URI $request_uri;\n    proxy_set_header X-Forwarded-For $remote_addr;\n  }\n  \n  location ~ /pubsub/auth/(\\w+)$ {\n    nchan_channel_id $1;\n    nchan_authorize_request /auth;\n    nchan_pubsub;\n    nchan_channel_group test;\n  }\n```\n\nHere, any request to the location `/pubsub/auth/\u003c...\u003e` 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.  \nAll non-`2xx` response codes (such as `403 Forbidden`) are interpreted as authorization failures. In this case, the failing response is proxied to the client. \n\nNote 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.\n\n\u003c!-- commands: nchan_authorize_request --\u003e\n\n### Subscriber Presence\n\nSubscribers can notify an application when they have subscribed and unsubscribed to a channel using the [`nchan_subscribe_request`](#nchan_subscribe_request)\nand [`nchan_unsubscribe_request`](#nchan_unsubscribe_request) settings. \nThese should point to Nginx locations configured to forward requests to an upstream proxy (your application):\n\n```nginx\n  location ~ /sub/(\\w+)$ {\n    nchan_channel_id $1;\n    nchan_subscribe_request /upstream/sub;\n    nchan_unsubscribe_request /upstream/unsub;\n    nchan_subscriber;\n    nchan_channel_group test;\n  }\n\n  location = /upstream/unsub {\n    proxy_pass http://127.0.0.1:9292/unsub;\n    proxy_ignore_client_abort on;  #!!!important!!!!\n    proxy_set_header X-Subscriber-Type $nchan_subscriber_type;\n    proxy_set_header X-Channel-Id $nchan_channel_id;\n    proxy_set_header X-Original-URI $request_uri;\n  } \n  location = /upstream/sub {\n    proxy_pass http://127.0.0.1:9292/sub;\n    proxy_set_header X-Subscriber-Type $nchan_subscriber_type;\n    proxy_set_header X-Message-Id $nchan_message_id;\n    proxy_set_header X-Channel-Id $nchan_channel_id;\n    proxy_set_header X-Original-URI $request_uri;\n  } \n```\n\nIn 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.\n\nNote 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.\n\n\u003c!-- commands: nchan_subscribe_request nchan_unsubscribe_request --\u003e\n\n### Message Forwarding\n\nMessages can be forwarded to an upstream application before being published using the `nchan_publisher_upstream_request` setting:\n\n```nginx\n  location ~ /pub/(\\w+)$ {\n    #publisher endpoint\n    nchan_channel_id $1;\n    nchan_pubsub;\n    nchan_publisher_upstream_request /upstream_pub;\n  }\n  \n  location = /upstream_pub {\n    proxy_pass http://127.0.0.1:9292/pub;\n    proxy_set_header X-Publisher-Type $nchan_publisher_type;\n    proxy_set_header X-Prev-Message-Id $nchan_prev_message_id;\n    proxy_set_header X-Channel-Id $nchan_channel_id;\n    proxy_set_header X-Original-URI $request_uri;\n  } \n```\nWith this configuration, incoming messages are first `POST`ed to `http://127.0.0.1:9292/pub`.\nThe upstream response code determines how publishing will proceed:\n  - `304 Not Modified` publishes the message as received, without modifification.\n  - `204 No Content` discards the message\n  - `200 OK` is used for modifying the message. Instead of the original incoming message, the message contained in this HTTP response is published.\n\nThere are two main use cases for `nchan_publisher_upstream_request`: forwarding incoming data from Websocket publishers to an application, and mutating incoming messages.\n\n\u003c!-- commands: nchan_publisher_upstream_request --\u003e\n\n## Storage\n\nNchan 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.\n\n### Memory Storage\n\nThis 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.\n\n\u003c!-- tag:memstore --\u003e\n\n### Redis\n\n[Redis](http://redis.io) can be used to add **data persistence** and **horizontal scalability**, **failover** and **high availability** to your Nchan setup. \n\n\u003c!-- tag:redis --\u003e\n\n#### Connecting to a Redis Server\nTo connect to a single Redis master server, use an `upstream` with `nchan_redis_server` and `nchan_redis_pass` settings:\n\n```nginx\nhttp {\n  upstream my_redis_server {\n    nchan_redis_server 127.0.0.1;\n  }\n  server {\n    listen 80;\n    \n    location ~ /redis_sub/(\\w+)$ {\n      nchan_subscriber;\n      nchan_channel_id $1;\n      nchan_redis_pass my_redis_server;\n    }\n    location ~ /redis_pub/(\\w+)$ {\n      nchan_redis_pass my_redis_server;\n      nchan_publisher;\n      nchan_channel_id $1;\n    }\n  }\n} \n```\n\nAll servers with the above configuration connecting to the same redis server share channel and message data.\n\nChannels 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.\n\nNchan can work with a single Redis master. It can also auto-discover and use Redis slaves to balance PUBSUB traffic.\n\n\u003c!-- commands: nchan_redis_server nchan_redis_pass --\u003e\n\n#### Redis Cluster\nNchan 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 configured and used like so:\n\n```nginx\nhttp {\n  upstream redis_cluster {\n    nchan_redis_server redis://127.0.0.1:7000;\n    nchan_redis_server redis://127.0.0.1:7001;\n    nchan_redis_server redis://127.0.0.1:7002;\n    # you don't need to specify all the nodes, they will be autodiscovered\n    # however, it's recommended that you do specify at least a few master nodes.\n  }\n  server {\n    listen 80;\n    \n    location ~ /sub/(\\w+)$ {\n      nchan_subscriber;\n      nchan_channel_id $1;\n      nchan_redis_pass redis_cluster;\n    }\n    location ~ /pub/(\\w+)$ {\n      nchan_publisher;\n      nchan_channel_id $1;\n      nchan_redis_pass redis_cluster;\n    }\n  }\n} \n```\n\n\u003c!-- commands: nchan_redis_server nchan_redis_pass --\u003e\n\n##### High Availability\nRedis 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.\n\nAll 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.\n\n##### Failover Recovery\nStarting with version 1.3.0, Nchan will attempt to recover from cluster node failures, keyslot errors, and cluster epoch changes without disconnecting from the entire cluster. It will attempt to do this until [`nchan_redis_cluster_max_failing_time`](#nchan_redis_cluster_max_failing_time) is exceeded. Additionally, [recovery attempt delays](#nchan_redis_cluster_recovery_delay) have configurable [jitter](#nchan_redis_cluster_recovery_delay_jitter), [exponential backoff](#nchan_redis_cluster_recovery_delay_backoff), and [maximum](#nchan_redis_cluster_recovery_delay_max) values.\n\n#### Using Redis securely\n\nRedis servers can be connected to via TLS by using the [`nchan_redis_ssl`](#nchan_redis_ssl) config setting in an `upstream` block, or by using the `rediss://`  schema for the server URLs.\n\nA password and optional username for the `AUTH` command can be set by the [`nchan_redis_username`](#nchan_redis_username) and [`nchan_redis_password`](#nchan_redis_password) config settings in an `upstream` block, or by using the `redis://\u003cusername\u003e:\u003cpassword\u003e@hostname` server URL schema.\n\nNote that autodiscovered Redis nodes inherit their parent's SSL, username, and password settings.\n\n#### Tweaks and Optimizations\n\nAs 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.\n\nAlso 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.\n\n#### Performance Statistics\n\nRedis command statistics were added in version 1.3.5. These provide total number of times different Redis commands were run on, and the total amount of time they took. The stats are for a given Nchan server, *not* all servers connected to a Redis upstream. They are grouped by each upstream, and totaled per node.\n\n```nginx\nhttp {\n  upstream my_redis_cluster {\n    nchan_redis_server 127.0.0.1;\n  }\n  \n  server {\n    #[...]\n    \n    location ~ /nchan_redis_cluster_stats$ {\n      nchan_redis_upstream_stats my_redis_cluster;\n    }\n  }\n\n```\n\nTo get the stats, send a GET request to the stats location.\n\n```console\n  curl http://localhost/nchan_redis_cluster_stats\n```\n\nThe response is JSON of the form:\n\n```js\n{\n  \"upstream\": \"redis_cluster\",\n  \"nodes\": [\n    {\n      \"address\"        : \"127.0.0.1:7000\",\n      \"id\"             : \"f13d71b1d14d8bf92b72cebee61421294e95dc72\",\n      \"command_totals\" : {\n        \"connect\"    : {\n          \"msec\"     : 357,\n          \"times\"    : 5\n        },\n        \"pubsub_subscribe\": {\n          \"msec\"     : 749,\n          \"times\"    : 37\n        },\n        \"pubsub_unsubsribe\": {\n          \"msec\"     : 332,\n          \"times\"    : 37\n        }\n        /*[...]*/\n      }\n    },\n    {\n      \"address\"        : \"127.0.0.1:7001\",\n      \"id\"             : \"b768ecb4152912bed6dc927e8f70284191a79ed7\",\n      \"command_totals\" : {\n        \"connect\"    : {\n          \"msec\"     : 4281,\n          \"times\"    : 5\n        },\n        \"pubsub_subscribe\": {\n          \"msec\"     : 309,\n          \"times\"    : 33\n        },\n        \"pubsub_unsubsribe\": {\n          \"msec\"     : 307,\n          \"times\"    : 30\n        },\n        /*[...]*/\n      },\n    }\n    /*[...]*/\n  ]\n}\n```\n\nFor brevity, the entire `command_totals` hash is omitted in this documentation.\n\n\u003c!-- commands: nchan_redis_upstream_stats nchan_redis_upstream_stats_disconnected_timeout nchan_redis_upstream_stats_enabled --\u003e\n\n## Introspection\n\nThere are several ways to see what's happening inside Nchan. These are useful for debugging application integration and for measuring performance.\n\n### Channel Events\n\nChannel 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.\n\nChannel events are published to special 'meta' channels associated with normal channels. Here's how to configure them:\n\n```nginx\nlocation ~ /pubsub/(.+)$ {\n  nchan_pubsub;\n  nchan_channel_id $1;\n  nchan_channel_events_channel_id $1; #enables channel events for this location\n}\n\nlocation ~ /channel_events/(.+) {\n  #channel events subscriber location\n  nchan_subscriber;\n  nchan_channel_group meta; #\"meta\" is a SPECIAL channel group\n  nchan_channel_id $1;\n}\n```\n\nNote the `/channel_events/...` location has a *special* `nchan_channel_group`, `meta`. This group is reserved for accessing \"channel events channels\", or\"metachannels\".\n\nNow, say I subscribe to `/channel_events/foo` I will refer to this as the channel events subscriber.\n\nLet's see what this channel events subscriber receives when I publish messages to \n\nSubscribing to `/pubsub/foo` produces the channel event\n```\nsubscriber_enqueue foo\n```\n\nPublishing a message to `/pubsub/foo`:\n```\nchannel_publish foo\n```\n\nUnsubscribing from `/pubsub/foo`:\n```\nsubscriber_dequeue foo\n```\n\nDeleting `/pubsub/foo` (with HTTP `DELETE /pubsub/foo`):\n```\nchannel_delete foo\n```\n\nThe 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`. \nThis string can use any Nginx and [Nchan variables](/#variables).\n\n\n### nchan_stub_status Stats\n\nLike Nginx's [stub_status](https://nginx.org/en/docs/http/ngx_http_stub_status_module.html),\n`nchan_stub_status` is used to get performance metrics.\n\n```nginx\n  location /nchan_stub_status {\n    nchan_stub_status;\n  }\n```\n\nSending a GET request to this location produces the response:\n\n```text\ntotal published messages: 1906\nstored messages: 1249\nshared memory used: 1824K\nchannels: 80\nsubscribers: 90\nredis pending commands: 0\nredis connected servers: 0\nredis unhealthy upstreams: 0\ntotal redis commands sent: 0\ntotal interprocess alerts received: 1059634\ninterprocess alerts in transit: 0\ninterprocess queued alerts: 0\ntotal interprocess send delay: 0\ntotal interprocess receive delay: 0\nnchan version: 1.1.5\n```\n\nHere's what each line means, and how to interpret it:\n  - `total published messages`: Number of messages published to all channels through this Nchan server.\n  - `stored messages`: Number of messages currently buffered in memory\n  - `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`.\n  - `channels`: Number of channels present on this Nchan server.\n  - `subscribers`: Number of subscribers to all channels on this Nchan server.\n  - `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.\n  - `redis connected servers`: Number of redis servers to which Nchan is currently connected.\n  - `redis unhealthy upstreams`: Number of redis upstreams (individual server or cluster mode) that are currently not usable for publishing and subscribing.\n  - `total redis commands sent`: Total number of commands this Nchan instance sent to Redis.\n  - `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.\n  - `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.\n  - `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.\n  - `total interprocess send delay`: Total amount of time interprocess communication packets spend being queued if delayed. May increase during high load.\n  - `total interprocess receive delay`: Total amount of time interprocess communication packets spend in transit if delayed. May increase during high load.\n  - `nchan_version`: current version of Nchan. Available for version 1.1.5 and above.\n\nAdditionally, when there is at least one `nchan_stub_status` location, this data is also available [through variables](#variables).\n  \n## Securing Channels\n\n### Securing Publisher Endpoints\nConsider the use case of an application where authenticated users each use a private, dedicated channel for live updates. The configuration might look like this:\n\n```nginx\nhttp {\n  server {\n    #available only on localhost\n    listen  127.0.0.1:8080;\n    location ~ /pub/(\\w+)$ {\n      nchan_publisher;\n      nchan_channel_group my_app_group;\n      nchan_channel_id $1;\n    }\n  }\n  \n  server {\n    #available to the world\n    listen 80;\n    \n    location ~ /sub/(\\w+)$ {\n      nchan_subscriber;\n      nchan_channel_group my_app_group;\n      nchan_channel_id $1;\n    }\n  }\n}\n\n```\n\nHere, 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:\n\n```nginx\n\n  server {\n    #available to the world\n    listen 80; \n    location ~ /pub/(\\w+)$ {\n      allow 127.0.0.1;\n      deny all;\n      nchan_publisher;\n      nchan_channel_group my_app_group;\n      nchan_channel_id $1;\n    }\n```\n\nHere, 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.\n\n### Keeping a Channel Private\n\nA 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? \n\nFirst, if you intend on securing the channel contents, you must use TLS/SSL:\n\n```nginx \nhttp {\n  server {\n    #available only on localhost\n    listen  127.0.0.1:8080;\n    #...publisher endpoint config\n  }\n  server {\n    #available to the world\n    listen 443 ssl;\n    #SSL config goes here\n    location ~ /sub/(\\w+)$ {\n      nchan_subscriber;\n      nchan_channel_group my_app_group;\n      nchan_channel_id $1;\n    }\n  }\n}\n```\n\nNow 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. \n\nYou must also take care to do at least one of the following:\n  - [Generate good, high-entropy Channel IDs](#good-ids).\n  - [Authorize all subscribers with the `nchan_authorize_request` config directive](#request-authorization).\n  - [Authorize subscribers and hide channel IDs with the \"`X-Accel-Redirect`\" mechanism](#x-accel-redirect).\n  \n#### Good IDs\n\nAn 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.\n\n#### X-Accel-Redirect\n\nThis 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.\nIt allows a subscriber client to be authenticated by your application, and then redirected by nginx internally to a location chosen by your application (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.\n\nConsider the following configuration:\n```nginx \nupstream upstream_app {\n  server 127.0.0.1:8080;\n}\n\nserver {\n  listen 80; \n  \n  location = /sub_upstream {\n    proxy_pass http://upstream_app/subscriber_x_accel_redirect;\n    proxy_set_header X-Forwarded-For $remote_addr;\n  }\n  \n  location ~ /sub/internal/(\\w+)$ {\n    internal; #this location only accessible for internal nginx redirects\n    nchan_subscriber;\n    nchan_channel_id $1;\n    nchan_channel_group test;\n  }\n}\n```\n\nAs commented, `/sub/internal/` is inaccessible from the outside:\n```console\n\u003e curl  -v  http://127.0.0.1/sub/internal/foo\n  \n  \u003c HTTP/1.1 404 Not Found\n  \u003c Server: nginx/1.9.5\n  \u003c\n  \u003chtml\u003e\n  \u003chead\u003e\u003ctitle\u003e404 Not Found\u003c/title\u003e\u003c/head\u003e\n  \u003cbody bgcolor=\"white\"\u003e\n  \u003ccenter\u003e\u003ch1\u003e404 Not Found\u003c/h1\u003e\u003c/center\u003e\n  \u003chr\u003e\u003ccenter\u003enginx/1.9.5\u003c/center\u003e\n  \u003c/body\u003e\n  \u003c/html\u003e\n```\n\nBut 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`.\nNote 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, \nbut unlike the case with `nchan_authorize_request`, Nchan-specific variables are not available.\n\nNow, 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.\n\nIf your application successfully authenticates the subscriber request, you now need to instruct Nginx to issue an internal redirect to `/sub/internal/my_channel_id`.\nThis is accomplished by responding with an empty `200 OK` response that includes two headers:\n- `X-Accel-Redirect: /sub/internal/my_channel_id`\n- `X-Accel-Buffering: no`\n\nIn 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`. \nThis will behave as if the client had requested the subscriber endpoint location directly.\n\nThus using X-Accel-Redirect it is possible to both authenticate all subscribers *and* keep channel IDs completely hidden from subscribers.\n\nThis 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.\n\n### Revoking Channel Authorization\n\nIn 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:\n\n```nginx\nlocation ~ /sub/(\\w+) {\n  nchan_subscriber;\n  nchan_channel_id shared_$1 user_$arg_userid;\n  nchan_authorize_request /authorize;\n}\n\nlocation /pub/user {\n  nchan_publisher;\n  nchan_channel_id user_$arg_userid;\n}\n```\n\nA 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\".\n  \n## Variables\n\nNchan makes several variables usabled in the config file:\n \n- `$nchan_channel_id`  \n  The channel id extracted from a publisher or subscriber location request. For multiplexed locations, this is the first channel id in the list.\n\n- `$nchan_channel_id1`, `$nchan_channel_id2`, `$nchan_channel_id3`, `$nchan_channel_id4`  \n  As above, but for the nth channel id in multiplexed channels.\n\n- `$nchan_subscriber_type`  \n  For subscriber locations, this variable is set to the subscriber type (websocket, longpoll, etc.).\n\n- `$nchan_channel_subscriber_last_seen`  \n  For publisher locations, this variable is set to the timestamp for the last connected subscriber.\n  \n- `$nchan_channel_subscriber_count`  \n  For publisher locations, this variable is set to the number of subscribers in the published channel.\n  \n- `$nchan_channel_message_count`  \n  For publisher locations, this variable is set to the number of messages buffered in the published channel.\n  \n- `$nchan_publisher_type`  \n  For publisher locations, this variable is set to the subscriber type (http or websocket).\n  \n- `$nchan_prev_message_id`, `$nchan_message_id`  \n  The current and previous (if applicable) message id for publisher request or subscriber response.\n\n- `$nchan_channel_event`  \n  For channel events, this is the event name. Useful when configuring `nchan_channel_event_string`.\n\n- `$nchan_version`  \n  Current Nchan version. Available since 1.1.5.\n  \nAdditionally, `nchan_stub_status` data is also exposed as variables. These are available only when `nchan_stub_status` is enabled on at least one location:\n\n- `$nchan_stub_status_total_published_messages`  \n- `$nchan_stub_status_stored_messages`  \n- `$nchan_stub_status_shared_memory_used`  \n- `$nchan_stub_status_channels`  \n- `$nchan_stub_status_subscribers`  \n- `$nchan_stub_status_redis_pending_commands`  \n- `$nchan_stub_status_redis_connected_servers`  \n- `$nchan_stub_status_redis_unhealthy_upstreams`  \n- `$nchan_stub_status_total_ipc_alerts_received`  \n- `$nchan_stub_status_ipc_queued_alerts`  \n- `$nchan_stub_status_total_ipc_send_delay`  \n- `$nchan_stub_status_total_ipc_receive_delay`  \n\n\n## Configuration Directives\n\n- **nchan_channel_id**  \n  arguments: 1 - 7  \n  default: `(none)`  \n  context: server, location, if  \n  \u003e Channel id for a publisher or subscriber location. Can have up to 4 values to subscribe to up to 4 channels.    \n  [more details](#the-channel-id)  \n\n- **nchan_channel_id_split_delimiter**  \n  arguments: 1  \n  default: `(none)`  \n  context: server, location, if  \n  \u003e Split the channel id into several ids for multiplexing using the delimiter string provided.    \n  [more details](#channel-multiplexing)  \n\n- **nchan_deflate_message_for_websocket** `[ on | off ]`  \n  arguments: 1  \n  default: `off`  \n  context: server, location  \n  \u003e Store a compressed (deflated) copy of the message along with the original to be sent to websocket clients supporting the permessage-deflate protocol extension    \n\n- **nchan_eventsource_event**  \n  arguments: 1  \n  default: `(none)`  \n  context: server, location, if  \n  \u003e 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.    \n\n- **nchan_eventsource_ping_comment**  \n  arguments: 1  \n  default: `(empty)`  \n  context: server, location, if  \n  \u003e 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.    \n\n- **nchan_eventsource_ping_data**  \n  arguments: 1  \n  default: `(empty)`  \n  context: server, location, if  \n  \u003e 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.    \n\n- **nchan_eventsource_ping_event**  \n  arguments: 1  \n  default: `ping`  \n  context: server, location, if  \n  \u003e 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.    \n\n- **nchan_eventsource_ping_interval** `\u003cnumber\u003e (seconds)`  \n  arguments: 1  \n  default: `0 (none)`  \n  context: server, location, if  \n  \u003e Interval for sending ping messages to EventSource subscribers. Disabled by default.    \n\n- **nchan_longpoll_multipart_response** `[ off | on | raw ]`  \n  arguments: 1  \n  default: `off`  \n  context: server, location, if  \n  \u003e 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.    \n\n- **nchan_permessage_deflate_compression_level** `[ 0-9 ]`  \n  arguments: 1  \n  default: `6`  \n  context: http  \n  \u003e Compression level for the `deflate` algorithm used in websocket's permessage-deflate extension. 0: no compression, 1: fastest, worst, 9: slowest, best    \n\n- **nchan_permessage_deflate_compression_memlevel** `[ 1-9 ]`  \n  arguments: 1  \n  default: `8`  \n  context: http  \n  \u003e 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    \n\n- **nchan_permessage_deflate_compression_strategy** `[ default | filtered | huffman-only | rle | fixed ]`  \n  arguments: 1  \n  default: `default`  \n  context: http  \n  \u003e 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)    \n\n- **nchan_permessage_deflate_compression_window** `[ 9-15 ]`  \n  arguments: 1  \n  default: `10`  \n  context: http  \n  \u003e 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.    \n\n- **nchan_publisher** `[ http | websocket ]`  \n  arguments: 0 - 2  \n  default: `http websocket`  \n  context: server, location, if  \n  legacy name: push_publisher  \n  \u003e 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.    \n  [more details](#publisher-endpoints)  \n\n- **nchan_publisher_channel_id**  \n  arguments: 1 - 7  \n  default: `(none)`  \n  context: server, location, if  \n  \u003e Channel id for publisher location.    \n\n- **nchan_publisher_upstream_request** `\u003curl\u003e`  \n  arguments: 1  \n  context: server, location, if  \n  \u003e 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.    \n  \u003e 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.    \n  [more details](#message-forwarding)  \n\n- **nchan_pubsub** `[ http | websocket | eventsource | longpoll | intervalpoll | chunked | multipart-mixed | http-raw-stream ]`  \n  arguments: 0 - 6  \n  default: `http websocket eventsource longpoll chunked multipart-mixed`  \n  context: server, location, if  \n  \u003e 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.    \n  [more details](#pubsub-endpoint)  \n\n- **nchan_subscribe_request** `\u003curl\u003e`  \n  arguments: 1  \n  context: server, location, if  \n  \u003e Send GET request to internal location (which may proxy to an upstream server) after subscribing. Disabled for longpoll and interval-polling subscribers.    \n  [more details](#subscriber-presence)  \n\n- **nchan_subscriber** `[ websocket | eventsource | longpoll | intervalpoll | chunked | multipart-mixed | http-raw-stream ]`  \n  arguments: 0 - 5  \n  default: `websocket eventsource longpoll chunked multipart-mixed`  \n  context: server, location, if  \n  legacy name: push_subscriber  \n  \u003e 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.    \n  \u003e  The value is a list of permitted subscriber types.    \n  [more details](#subscriber-endpoints)  \n\n- **nchan_subscriber_channel_id**  \n  arguments: 1 - 7  \n  default: `(none)`  \n  context: server, location, if  \n  \u003e Channel id for subscriber location. Can have up to 4 values to subscribe to up to 4 channels.    \n\n- **nchan_subscriber_compound_etag_message_id**  \n  arguments: 1  \n  default: `off`  \n  context: server, location, if  \n  \u003e Override the default behavior of using both `Last-Modified` and `Etag` headers for the message id.    \n  \u003e Enabling this option packs the entire message id into the `Etag` header, and discards  \n  \u003e `Last-Modified` and `If-Modified-Since` headers.    \n  [more details]()  \n\n- **nchan_subscriber_first_message** `[ oldest | newest | \u003cnumber\u003e ]`  \n  arguments: 1  \n  default: `oldest`  \n  context: server, location, if  \n  \u003e 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'.    \n\n- **nchan_subscriber_http_raw_stream_separator** `\u003cstring\u003e`  \n  arguments: 1  \n  default: `\\n`  \n  context: server, location, if  \n  \u003e Message separator string for the http-raw-stream subscriber. Automatically terminated with a newline character if not explicitly set to an empty string.    \n\n- **nchan_subscriber_info**  \n  arguments: 0  \n  context: location  \n  \u003e A subscriber location for debugging the state of subscribers on a given channel. The subscribers of the channel specified by `nchan_channel_id` evaluate `nchan_subscriber_info_string` and send it back to the requested on this location. This is useful to see where subscribers are in an Nchan cluster, as well as debugging subscriber connection issues.    \n\n- **nchan_subscriber_info_string**  \n  arguments: 1  \n  default: `$nchan_subscriber_type $remote_addr:$remote_port $http_user_agent $server_name $request_uri $pid`  \n  context: server, location  \n  \u003e this string is evaluated by each subscriber on a given channel and sent to the requester of a `nchan_subscriber_info` location    \n\n- **nchan_subscriber_last_message_id**  \n  arguments: 1 - 5  \n  default: `$http_last_event_id $arg_last_event_id`  \n  context: server, location, if  \n  \u003e 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.     \n\n- **nchan_subscriber_message_id_custom_etag_header**  \n  arguments: 1  \n  default: `(none)`  \n  context: server, location, if  \n  \u003e 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.    \n\n- **nchan_subscriber_timeout** `\u003cnumber\u003e (seconds)`  \n  arguments: 1  \n  default: `0 (none)`  \n  context: http, server, location, if  \n  legacy name: push_subscriber_timeout  \n  \u003e 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.    \n\n- **nchan_unsubscribe_request** `\u003curl\u003e`  \n  arguments: 1  \n  context: server, location, if  \n  \u003e Send GET request to internal location (which may proxy to an upstream server) after unsubscribing. Disabled for longpoll and interval-polling subscribers.    \n  [more details](#subscriber-presence)  \n\n- **nchan_websocket_client_heartbeat** `\u003cheartbeat_in\u003e \u003cheartbeat_out\u003e`  \n  arguments: 2  \n  default: `none (disabled)`  \n  context: server, location, if  \n  \u003e 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).    \n\n- **nchan_websocket_ping_interval** `\u003cnumber\u003e (seconds)`  \n  arguments: 1  \n  default: `0 (none)`  \n  context: server, location, if  \n  \u003e Interval for sending websocket ping frames. Disabled by default.    \n\n- **nchan_access_control_allow_credentials**  \n  arguments: 1  \n  default: `on`  \n  context: http, server, location, if  \n  \u003e 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`.    \n\n- **nchan_access_control_allow_origin** `\u003cstring\u003e`  \n  arguments: 1  \n  default: `$http_origin`  \n  context: http, server, location, if  \n  \u003e 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.    \n\n- **nchan_authorize_request** `\u003curl\u003e`  \n  arguments: 1  \n  context: server, location, if  \n  \u003e 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.    \n  [more details](#request-authorization)  \n\n- **nchan_channel_group** `\u003cstring\u003e`  \n  arguments: 1  \n  default: `(none)`  \n  context: server, location, if  \n  legacy name: push_channel_group  \n  \u003e The accounting and security group a channel belongs to. Works like a prefix string to the channel id. Can be set with nginx variables.    \n\n- **nchan_channel_group_accounting**  \n  arguments: 1  \n  default: `off`  \n  context: server, location  \n  \u003e Enable tracking channel, subscriber, and message information on a per-channel-group basis. Can be used to place upper limits on channel groups.    \n\n- **nchan_group_location** `[ get | set | delete | off ]`  \n  arguments: 0 - 3  \n  default: `get set delete`  \n  context: location  \n  \u003e Group information and configuration location. GET request for group info, POST to set limits, DELETE to delete all channels in group.    \n\n- **nchan_group_max_channels** `\u003cnumber\u003e`  \n  arguments: 1  \n  default: `0 (unlimited)`  \n  context: location  \n  \u003e Maximum number of channels allowed in the group.    \n\n- **nchan_group_max_messages** `\u003cnumber\u003e`  \n  arguments: 1  \n  default: `0 (unlimited)`  \n  context: location  \n  \u003e Maximum number of messages allowed for all the channels in the group.    \n\n- **nchan_group_max_messages_disk** `\u003cnumber\u003e`  \n  arguments: 1  \n  default: `0 (unlimited)`  \n  context: location  \n  \u003e Maximum amount of disk space allowed for the messages of all the channels in the group.    \n\n- **nchan_group_max_messages_memory** `\u003cnumber\u003e`  \n  arguments: 1  \n  default: `0 (unlimited)`  \n  context: location  \n  \u003e Maximum amount of shared memory allowed for the messages of all the channels in the group.    \n\n- **nchan_group_max_subscribers** `\u003cnumber\u003e`  \n  arguments: 1  \n  default: `0 (unlimited)`  \n  context: location  \n  \u003e Maximum number of subscribers allowed for the messages of all the channels in the group.    \n\n- **nchan_max_channel_id_length** `\u003cnumber\u003e`  \n  arguments: 1  \n  default: `1024`  \n  context: http, server, location  \n  legacy name: push_max_channel_id_length  \n  \u003e 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.    \n\n- **nchan_max_channel_subscribers** `\u003cnumber\u003e`  \n  arguments: 1  \n  default: `0 (unlimited)`  \n  context: http, server, location  \n  legacy name: push_max_channel_subscribers  \n  \u003e Maximum concurrent subscribers to the channel on this Nchan server. Does not include subscribers on other Nchan instances when using a shared Redis server.    \n\n- **nchan_subscribe_existing_channels_only** `[ on | off ]`  \n  arguments: 1  \n  default: `off`  \n  context: http, server, location  \n  legacy name: push_authorized_channels_only  \n  \u003e 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.    \n\n- **nchan_message_buffer_length** `[ \u003cnumber\u003e | \u003cvariable\u003e ]`  \n  arguments: 1  \n  default: `10`  \n  context: http, server, location  \n  legacy names: push_max_message_buffer_length, push_message_buffer_length  \n  \u003e 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.    \n\n- **nchan_message_temp_path** `\u003cpath\u003e`  \n  arguments: 1  \n  default: `\u003cclient_body_temp_path\u003e`  \n  context: http  \n  \u003e 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`    \n\n- **nchan_message_timeout** `[ \u003ctime\u003e | \u003cvariable\u003e ]`  \n  arguments: 1  \n  default: `1h`  \n  context: http, server, location  \n  legacy name: push_message_timeout  \n  \u003e Publisher configuration setting the length of time a message may be queued before it is considered expired. If you do not want messages to expire, set this to 0. Note that messages always expire from oldest to newest, so an older message may prevent a newer one with a shorter timeout from expiring. An Nginx variable can also be used to set the timeout dynamically.    \n\n- **nchan_redis_accurate_subscriber_count**  \n  arguments: 1  \n  default: `off`  \n  context: upstream  \n  \u003e When disabled, use fast but potentially inaccurate subscriber counts. These may become inaccurate if Nginx workers exit uncleanly or are terminated. When enabled, use a slightly slower but completely accurate subscriber count. Defaults to 'off' for legacy reasons, but will be enabled by default in the future.    \n\n- **nchan_redis_cluster_check_interval_backoff** `\u003cfloating point\u003e \u003e= 0, ratio of current delay`  \n  arguments: 1  \n  default: `2 (increase delay by 200% each try)`  \n  context: upstream  \n  \u003e Add an exponentially increasing delay to the Redis cluster check interval. `Delay[n] = (Delay[n-1] + jitter) * (nchan_redis_cluster_check_interval_backoff + 1)`.    \n\n- **nchan_redis_cluster_check_interval_jitter** `\u003cfloating point\u003e \u003e= 0, (0 to disable)`  \n  arguments: 1  \n  default: `0.2 (20% of interval value)`  \n  context: upstream  \n  \u003e Introduce random jitter to Redis cluster check interval, where the range is `±(cluster_check_interval * nchan_redis_cluster_check_interval_jitter) / 2`.    \n\n- **nchan_redis_cluster_check_interval_max** `\u003ctime\u003e (0 to disable)`  \n  arguments: 1  \n  default: `30s`  \n  context: upstream  \n  \u003e Maximum Redis cluster check interval after backoff and jitter.    \n\n- **nchan_redis_cluster_check_interval_min** `\u003ctime\u003e`  \n  arguments: 1  \n  default: `1s (0 to disable)`  \n  context: upstream  \n  \u003e When connected to a cluster, periodically check the cluster state and layout via a random master node.    \n\n- **nchan_redis_cluster_connect_timeout**  \n  arguments: 1  \n  default: `15s`  \n  context: upstream  \n  \u003e Redis cluster connection timeout.    \n\n- **nchan_redis_cluster_max_failing_time**  \n  arguments: 1  \n  default: `30s`  \n  context: upstream  \n  \u003e Maximum time a Redis cluster can be in a failing state before Nchan disconnects from it. During this time, Nchan will try to recover from a cluster or node failure without disconnecting the entire cluster.    \n\n- **nchan_redis_cluster_recovery_delay** `\u003ctime\u003e`  \n  arguments: 1  \n  default: `100ms`  \n  context: upstream  \n  \u003e After a cluster recovery failure, wait this long to try again.    \n\n- **nchan_redis_cluster_recovery_delay_backoff** `\u003cfloating point\u003e \u003e= 0, ratio of current delay`  \n  arguments: 1  \n  default: `0.5 (increase delay by 50% each try)`  \n  context: upstream  \n  \u003e Add an exponentially increasing delay to Redis cluster recovery retries. `Delay[n] = (Delay[n-1] + jitter) * (nchan_redis_cluster_recovery_delay_backoff + 1)`.    \n\n- **nchan_redis_cluster_recovery_delay_jitter** `\u003cfloating point\u003e \u003e= 0, (0 to disable)`  \n  arguments: 1  \n  default: `0.5 (50% of delay value)`  \n  context: upstream  \n  \u003e Introduce random jitter to Redis cluster recovery retry time, where the range is `±(recovery_delay * nchan_redis_cluster_recovery_delay_jitter) / 2`.    \n\n- **nchan_redis_cluster_recovery_delay_max** `\u003ctime\u003e (0 to disable)`  \n  arguments: 1  \n  default: `2s`  \n  context: upstream  \n  \u003e Maximum Redis cluster recovery delay after backoff and jitter.    \n\n- **nchan_redis_command_timeout** `\u003ctime\u003e (0 to leave unlimited)`  \n  arguments: 1  \n  default: `5s`  \n  context: upstream  \n  \u003e If a Redis server exceeds this time to produce a command reply, it is considered unhealthy and is disconnected.    \n\n- **nchan_redis_connect_timeout**  \n  arguments: 1  \n  default: `10s`  \n  context: upstream  \n  \u003e Redis server connection timeout.    \n\n- **nchan_redis_discovered_ip_range_blacklist** `\u003cCIDR range\u003e`  \n  arguments: 1 - 7  \n  context: upstream  \n  \u003e do not attempt to connect to **autodiscovered** nodes with IPs in the specified ranges. Useful for blacklisting private network ranges for clusters and Redis slaves. NOTE that this blacklist applies only to autodiscovered nodes, and not ones specified in the upstream block    \n\n- **nchan_redis_idle_channel_cache_timeout** `\u003ctime\u003e`  \n  arguments: 1  \n  default: `30s`  \n  context: http, server, location  \n  \u003e A Redis-stored channel and its messages are removed from memory (local cache) after this timeout, provided there are no local subscribers.    \n\n- **nchan_redis_namespace** `\u003cstring\u003e`  \n  arguments: 1  \n  context: http, server, upstream, location  \n  \u003e Prefix all Redis keys with this string. All Nchan-related keys in redis will be of the form \"nchan_redis_namespace:*\" . Default is empty.    \n\n- **nchan_redis_nostore_fastpublish** `[ on | off ]`  \n  arguments: 1  \n  default: `off`  \n  context: http, server, upstream  \n  \u003e Increases publishing capacity by 2-3x for Redis nostore mode at the expense of inaccurate subscriber counts in the publisher response.    \n\n- **nchan_redis_optimize_target** `[ cpu | bandwidth ]`  \n  arguments: 1  \n  default: `bandwidth`  \n  context: upstream  \n  \u003e This tweaks whether [effect replication](https://redis.io/commands/eval#replicating-commands-instead-of-scripts) is enabled. This setting is obsolete, as effect replication is now always enabled to support other features    \n\n- **nchan_redis_pass** `\u003cupstream-name\u003e`  \n  arguments: 1  \n  context: http, server, location  \n  \u003e Use an upstream config block for Redis servers.    \n  [more details](#connecting-to-a-redis-server)  \n\n- **nchan_redis_password**  \n  arguments: 1  \n  default: `\u003cnone\u003e`  \n  context: upstream  \n  \u003e Set Redis password for AUTH command. All servers in the upstream block will use this password _unless_ a different password is specified by a server URL.    \n\n- **nchan_redis_ping_interval**  \n  arguments: 1  \n  default: `4m`  \n  context: http, server, upstream, location  \n  \u003e Send a keepalive command to redis to keep the Nchan redis clients from disconnecting. Set to 0 to disable.    \n\n- **nchan_redis_reconnect_delay** `\u003ctime\u003e`  \n  arguments: 1  \n  default: `500ms`  \n  context: upstream  \n  \u003e After a connection failure, wait this long before trying to reconnect to Redis.    \n\n- **nchan_redis_reconnect_delay_backoff** `\u003cfloating point\u003e \u003e= 0 (0 to disable)`  \n  arguments: 1  \n  default: `0.5 (increase delay by 50% each try)`  \n  context: upstream  \n  \u003e Add an exponentially increasing delay to Redis connection retries. `Delay[n] = (Delay[n-1] + jitter) * (nchan_redis_reconnect_delay_backoff + 1)`.    \n\n- **nchan_redis_reconnect_delay_jitter** `\u003cfloating point\u003e \u003e= 0 (0 to disable)`  \n  arguments: 1  \n  default: `0.1 (10% of delay value)`  \n  context: upstream  \n  \u003e Introduce random jitter to Redis reconnection time, where the range is `±(reconnect_delay * nchan_redis_reconnect_delay_jitter) / 2`.    \n\n- **nchan_redis_reconnect_delay_max** `\u003ctime\u003e (0 to disable)`  \n  arguments: 1  \n  default: `10s`  \n  context: upstream  \n  \u003e Maximum Redis reconnection delay after backoff and jitter.    \n\n- **nchan_redis_retry_commands**  \n  arguments: 1  \n  default: `on`  \n  context: upstream  \n  \u003e Allow Nchan to retry some Redis commands on keyslot errors and cluster unavailability. Queuing up a lot of commands while the cluster is unavailable may lead to excessive memory use, but it can also defer commands during transient failures.    \n\n- **nchan_redis_retry_commands_max_wait** `\u003ctime\u003e (0 to leave unlimited)`  \n  arguments: 1  \n  default: `500ms`  \n  context: upstream  \n  \u003e When `nchan_redis_retry_commands` is on, the maximum time a command will stayed queued to be retried.    \n\n- **nchan_redis_server** `\u003credis-url\u003e \u003coptional-forced-role\u003e`  \n  arguments: 1 - 2  \n  default: `\u003credis-url\u003e`  \n  context: upstream  \n  \u003e Used in upstream { } blocks to set redis servers. Redis url is in the form 'redis://:password@hostname:6379/0'. Shorthands 'host:port' or 'host' are permitted. A role may optionally be provided as well to force a server to be treated as 'master' or 'slave'.  \n  \u003e       uri:     \n\n- **nchan_redis_ssl** `[ on | off ]`  \n  arguments: 1  \n  default: `off`  \n  context: upstream  \n  \u003e Enables SSL/TLS for all connections to Redis servers in this upstream block. When enabled, no unsecured connections are permitted    \n\n- **nchan_redis_ssl_ciphers**  \n  arguments: 1  \n  default: `\u003csystem default\u003e`  \n  context: upstream  \n  \u003e Acceptable ciphers when using TLS for Redis connections    \n\n- **nchan_redis_ssl_client_certificate**  \n  arguments: 1  \n  context: upstream  \n  \u003e Path to client certificate when using TLS for Redis connections    \n\n- **nchan_redis_ssl_client_certificate_key**  \n  arguments: 1  \n  context: upstream  \n  \u003e Path to client certificate key when using TLS for Redis connections    \n\n- **nchan_redis_ssl_server_name**  \n  arguments: 1  \n  context: upstream  \n  \u003e Server name to verify (CN) when using TLS for Redis connections    \n\n- **nchan_redis_ssl_trusted_certificate**  \n  arguments: 1  \n  context: upstream  \n  \u003e Trusted certificate (CA) when using TLS for Redis connections    \n\n- **nchan_redis_ssl_trusted_certificate_path**  \n  arguments: 1  \n  default: `\u003csystem default\u003e`  \n  context: upstream  \n  \u003e Trusted certificate (CA) when using TLS for Redis connections. Defaults to the system's SSL cert path unless nchan_redis_ssl_trusted_certificate is set    \n\n- **nchan_redis_ssl_verify_certificate** `[ on | off ]`  \n  arguments: 1  \n  default: `on`  \n  context: upstream  \n  \u003e Should the server certificate be verified when using TLS for Redis connections? Useful to disable when testing with a self-signed server certificate.    \n\n- **nchan_redis_storage_mode** `[ distributed | backup | nostore ]`  \n  arguments: 1  \n  default: `distributed`  \n  context: http, server, upstream, location  \n  \u003e The mode of operation of the Redis server. In `distributed` mode, messages are published directly to Redis, and retrieved in real-time. Any number of Nchan servers in distributed mode can share the Redis server (or cluster). Useful for horizontal scalability, but suffers the latency penalty of all message publishing going through Redis first.  \n  \u003e   \n  \u003e In `backup` mode, messages are published locally first, then later forwarded to Redis, and are retrieved only upon channel initialization. Only one Nchan server should use a Redis server (or cluster) in this mode. Useful for data persistence without sacrificing response times to the latency of a round-trip to Redis.  \n  \u003e   \n  \u003e In `nostore` mode, messages are published as in `distributed` mode, but are not stored. Thus Redis is used to broadcast messages to many Nchan instances with no delivery guarantees during connection failure, and only local in-memory storage. This means that there are also no message delivery guarantees for subscribers switching from one Nchan instance to another connected to the same Redis server or cluster. Nostore mode increases Redis publishing capacity by an order of magnitude.    \n\n- **nchan_redis_subscribe_weights** `master=\u003cinteger\u003e slave=\u003cinteger\u003e`  \n  arguments: 1 - 2  \n  default: `master=1 slave=1`  \n  context: upstream  \n  \u003e Determines how subscriptions to Redis PUBSUB channels are distributed between master and slave nodes. The higher the number, the more likely that each node of that type will be chosen for each new channel. The weights for slave nodes are cumulative, so an equal 1:1 master:slave weight ratio with two slaves would have a 1/3 chance of picking a master, and 2/3 chance of picking one of the slaves. The weight must be a non-negative integer.    \n\n- **nchan_redis_upstream_stats** `\u003cupstream_name\u003e`  \n  arguments: 1  \n  default: `(none)`  \n  context: server, location  \n  \u003e Defines a location as redis statistics endpoint. GET requests to this location produce a JSON response with detailed listings of total Redis command times and number of calls, broken down by node and command type. Useful for making graphs about Redis performance. Can be set with nginx variables.    \n\n- **nchan_redis_upstream_stats_disconnected_timeout**  \n  arguments: 1  \n  default: `5m`  \n  context: upstream  \n  \u003e Keep stats for disconnected nodes around for this long. Useful for tracking stats for nodes that have intermittent connectivity issues.    \n\n- **nchan_redis_upstream_stats_enabled** `[ on | off ]`  \n  arguments: 1  \n  default: `\u003con\u003e if at least 1 redis stats location is configured, otherwise \u003coff\u003e`  \n  context: upstream  \n  \u003e Gather Redis node command timings for this upstream    \n\n- **nchan_redis_url** `\u003credis-url\u003e`  \n  arguments: 1  \n  default: `127.0.0.1:6379`  \n  context: http, server, location  \n  \u003e Use of this command is discouraged in favor of upstreams blocks with [`nchan_redis_server`](#nchan_redis_server). The path to a redis server, of the form 'redis://:password@hostname:6379/0'. Shorthand of the form 'host:port' or just 'host' is also accepted.    \n  [more details](#connecting-to-a-redis-server)  \n\n- **nchan_redis_username**  \n  arguments: 1  \n  default: `\u003cnone\u003e`  \n  context: upstream  \n  \u003e Set Redis username for AUTH command (available when using ACLs on the Redis server). All servers in the upstream block will use this username _unless_ a different username is specified by a server URL.    \n\n- **nchan_shared_memory_size** `\u003csize\u003e`  \n  arguments: 1  \n  default: `128M`  \n  context: http  \n  legacy names: push_max_reserved_memory, nchan_max_reserved_memory  \n  \u003e Shared memory slab pre-allocated for Nchan. Used for channel statistics, message storage, and interprocess communication.    \n  [more details](#memory-storage)  \n\n- **nchan_store_messages** `[ on | off ]`  \n  arguments: 1  \n  default: `on`  \n  context: http, server, location, if  \n  legacy name: push_store_messages  \n  \u003e Publisher configuration. \"`off`\" is equivalent to setting `nchan_message_buffer_length 0`, which disables the buffering of old messages. Using this setting is not recommended when publishing very quickly, as it may result in missed messages.    \n\n- **nchan_use_redis** `[ on | off ]`  \n  arguments: 1  \n  default: `off`  \n  context: http, server, location  \n  \u003e Use of this command is discouraged in favor of (`nchan_redis_pass`)[#nchan_redis_pass]. Use Redis for message storage at this location.    \n  [more details](#connecting-to-a-redis-server)  \n\n- **nchan_channel_event_string** `\u003cstring\u003e`  \n  arguments: 1  \n  default: `\"$nchan_channel_event $nchan_channel_id\"`  \n  context: server, location, if  \n  \u003e Contents of channel event message    \n\n- **nchan_channel_events_channel_id**  \n  arguments: 1  \n  context: server, location, if  \n  \u003e Channel id where `nchan_channel_id`'s events should be sent. Events like subscriber enqueue/dequeue, publishing messages, etc. Useful for application debugging. The channel event message is configurable via nchan_channel_event_string. The channel group for events is hardcoded to 'meta'.    \n  [more details](#channel-events)  \n\n- **nchan_stub_status**  \n  arguments: 0  \n  context: location  \n  \u003e Similar to Nginx's stub_status directive, requests to an `nchan_stub_status` location get a response with some vital Nchan statistics. This data does not account for information from other Nchan instances, and monitors only local connections, published messages, etc.    \n  [more details](#nchan_stub_status)  \n\n- **nchan_channel_timeout**  \n  arguments: 1  \n  context: http, server, location  \n  legacy name: push_channel_timeout  \n  \u003e Amount of time an empty channel hangs around. Don't mess with this setting unless you know what you are doing!    \n\n- **nchan_storage_engine** `[ memory | redis ]`  \n  arguments: 1  \n  default: `memory`  \n  context: http, server, location  \n  \u003e Development directive to completely replace default storage engine. Don't use unless you are an Nchan developer.    \n\n## Contribute\nPlease support this project with a donation to keep me warm through the winter. I accept bitcoin at 15dLBzRS4HLRwCCVjx4emYkxXcyAPmGxM3 . Other donation methods can be found at https://nchan.io\n","funding_links":[],"categories":["C","🌐 Web Development - Frontend"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fslact%2Fnchan","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fslact%2Fnchan","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fslact%2Fnchan/lists"}