代码拉取完成,页面将自动刷新
NGiNX HTTP push module - Turn NGiNX into an adept HTTP Push (Comet) server. This module takes care of all the connection juggling, and exposes a simple interface to broadcast messages to clients via plain old HTTP requests. This makes it possible to write live-updating applications without having to wait on idle connections via upstream proxies or making your code all asynchronous and concurrent. ---------------- Configuration Directives & Variables ------------------------ Variables: $push_channel_id A token uniquely identifying a communication channel. Must be present in the context of the push_subscriber and push_publisher directives. Example: set $push_channel_id $arg_id; #channel id is now the url query string parameter "id" #(/foo/bar?id=channel_id_string) Directives: ==Publisher/Subscriber== push_subscriber [ long-poll | interval-poll ] default: long-poll context: server, location Defines a server or location as a subscriber. This location represents a subscriber's interface to a channel's message queue. The queue is traversed automatically via caching information request headers (If-Modified-Since and If-None-Match), beginning with the oldest available message. Requests for upcoming messages are handled in accordance with the setting provided. See the protocol documentation for a detailed description. push_subscriber_concurrency [ last | first | broadcast ] default: broadcast context: http, server, location Controls how multiple subscriber requests to a channel (identified by some common ID) are handled. The values work as follows: - broadcast: any number of concurrent subscriber requests may be held. - last: only the most recent subscriber request is kept, all others get a 409 Conflict response. - first: only the oldest subscriber request is kept, all others get a 409 Conflict response. push_publisher default: none context: server, location Defines a server or location as a message publisher. Requests to a publisher location are treated as messages to be sent to subscribers. See the protocol documentation for a detailed description. == Message storage == push_store_messages [ on | off ] default: on context: http, server, location Whether or not message queuing is enabled. "Off" is equivalent to the setting push_channel_buffer_length 0; push_max_reserved_memory [ size ] default: 32M context: http The size of the memory chunk this module will use for all message queuing and buffering. push_min_message_buffer_length [ number ] default: 1 context: http, server, location The minimum number of messages to store per channel. A channel's message buffer will retain at least this many most recent messages. push_max_message_buffer_length [ number ] default: 10 context: http, server, location The maximum number of messages to store per channel. A channel's message buffer will retain at most this many most recent messages. push_message_buffer_length [ number ] default: none context: http, server, location The exact number of messages to store per channel. Sets both push_max_message_buffer_length and push_min_message_buffer_length to this value. push_delete_oldest_received_message [ on | off ] default: off context: http, server, location When enabled, as soon as the oldest message in a channel's message queue has been received by a subscriber, it is deleted -- provided there are more than push_min_message_buffer_length messages in the channel's message buffer. Recommend avoiding this directive as it violates subscribers' assumptions of GET request idempotence. push_message_timeout [ time ] default: 1h context: http, server, location 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. Applicable only if a push_publisher is present in this or a child context. == Security == push_authorized_channels_only [ on | off ] default: off context: http, server, location Whether or not a subscriber may create a channel by making a request to a push_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. push_channel_group [ string ] default: (none) context: server, location Because settings are bound to locations and not individual channels, it is useful to be able to have channels that can be reached only from some locations and never others. That's where this setting comes in. Think of it as a prefix string for the channel id. push_max_channel_id_length [ number ] default: 512 context: main, server, location Maximum permissible channel id length (number of characters). Longer ids will be truncated. push_max_channel_subscribers [ number ] default: 0 (unlimited) context: main, server, location Maximum concurrent subscribers. Pretty self-explanatory. --------------------------- Example Config ----------------------------------- http { #maximum amount of memory the push module is allowed to use #for buffering and stuff push_max_reserved_memory 12M; #default is 3M # internal publish endpoint (keep it private / protected) location /publish { set $push_channel_id $arg_channel; #/?channel=239aff3 or some-such push_publisher; push_message_timeout 2h; # expire buffered messages after 2 hours push_max_message_buffer_length 10; # store absolutely at most 10 messages push_min_message_recipients 0; # minimum recipients before purge } # public long-polling endpoint location /activity { push_subscriber; # how multiple subscriber requests to the same channel id are handled # - last: only the most recent subscriber request is kept, 409 for others. # - first: only the oldest subscriber request is kept, 409 for others. # - broadcast: any number of subscriber requests may be long-polling. push_subscriber_concurrency broadcast; set $push_channel_id $arg_channel; #/?channel=239aff3 or some-such default_type text/plain; } } ---------------------------- Operation --------------------------------------- The following describes what is likely to be the most commonly desired setup: Assuming the example config given above, Clients will connect to http://example.com/activity?id=... and have the response delayed until a message is POSTed to http://example.com/publish?id=... Messages can be sent to clients that have not yet connected, i.e. they are queued. Upon sending a request to a push_publisher location, the message, contained in the publisher request body, will be sent to the channel identified by $push_channel_id and to all presently connected channel subscribers. If there are no subscribers waiting for a message at the time, the publisher will be sent to with a with a 202 Accepted response. Otherwise, a 201 Created response is sent. Additionally, the body of the publisher response will contain information about the channel (number of current subscribers, message queue length, etc). If you intend to have the publisher be a server-side application, it's a damn good idea to make sure the push_publisher location is not publicly accessible. Traversal through a channel's message buffer by a subscriber requires proper HTTP caching support from the subscriber client. Make sure it correctly sends Last-Modified and Etag headers. (All modern web browsers do this.) ----------------------- Protocol Spec -------------------------------------- This module is unconditionally (fully) compliant with the Basic HTTP Push Relay Protocol, Rev. 2.24, found in the file protocol.txt.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。