Bayeux協議
（Bayeux真的不知道怎么翻。。。）

Bayeux 協議-- Bayeux 1.0草案1

本備忘錄狀態

This document specifies a protocol for the Internet community, and requests discussion and suggestions for improvement. This memo is written in the style and spirit of an IETF RFC but is not, as of yet, an official IETF RFC. Distribution of this memo is unlimited. This memo is written in UK English.

這份文檔為互聯網社區詳細描述了一個協議，請求討論并提出改進建議。此備忘錄以 IETF RFC 風格寫作，但是它不是、也還沒有成為官方IETF RFC。此備忘錄使用英式英文，對分發無限制。

版權聲明

版權所有Dojo基金會 (2007). 保留所有權利

摘要

Bayeux is a protocol for transporting asynchronous messages (primarily over HTTP), with low latency between a web server.

Bayeux是在和web服務器間提供低時延、傳輸異步消息的協議（主要基于HTTP）。

目錄

1. 介紹

1.1. 目的

The primary purpose of Bayeux is to support responsive 2 way interactions between web clients using Ajax and the web server.

Bayexu協議的主要目的，是在使用Ajax的web客戶端和web服務器之間，提供2種交互應答方式。

Bayeux is a protocol for transporting asynchronous messages (primarily over HTTP), with low latency between a web server and a web browser. The messages are routed via named channels and can be delivered: server to client, client to server and client to client (via the server). By default, publish subscribe routing semantics are applied to the channels, but other routing models are also supported.

Bayeux是在web服務器和web瀏覽器間提供低時延、傳輸異步消息的協議（主要基于HTTP）。消息通過命名通道被路由，并被分發：服務端至客戶端，客戶端至服務端和客戶端至客戶端（通過服務器中轉）。默認時，發布訂閱路由語義應用于通道，但是其他路由模型也被支持。

Delivery of asynchronous messages from the server to a web client is often described as "server-push". The combination of server push techniques with an Ajax web application has been called "comet". Cometd is a project by the Dojo Foundation to provide multiple implementation of the Bayeux project in several programming languages.

服務器至web客戶端的異步消息分發常被稱之為“server-push”。web應用中混合Ajax和server push的技術被稱為“comet”。 Cometd是Dojo基金會的一個項目，它提供Bayeux項目在不同編程語言中的多個實現。

Bayeux seeks to reduce the complexity of developing Comet-driven applications by allowing implementers to more easily interoperate, solve common message distribution and routing problems, and provide mechanisms for incremental improvement and extension.

Bayeux致力于減少開發 Comet驅動應用的復雜性，允許實現者更容易的交互，解決通用消息分發和路由問題，同時也提供可持續改進和擴展的機制。

1.2. 需求

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."

這份文檔中，關鍵詞“必須”、“禁止”、“需要的”、“必須”、“必須不”、“應該”、“不應該”、“推薦的”、“可能”、“可選的”要按照 RFC2119中所描述的來理解。如果一個本協議的實現，沒有滿足一個或多個“必須”或“需要的”級別的需求，那它就是不兼容的。如果一個本協議的實現，滿足了所有“必須”或“需要的”級別的需求和所有“應該”級別的需求，那它就是“完全兼容”；一個滿足“必須”級別的需求但并非滿足所有“應該”級別的需求的協議實現，就是“部分兼容”。

1.3. 術語

This specification uses a number of terms to refer to the roles played by participants in, and objects of, Bayeux communication:

本規范使用一系列術語來引用Bayeux通信中所參與的角色以及對象。

client

A program that initiates communications. A HTTP client is a client that initiates TCP/IP connections for the purpose of sending HTTP requests. A Bayeux client initiates the Bayeux message exchange and will typically execute within a HTTP client, but it is likely to have Bayeux clients that execute within HTTP servers. Implementations may distinguish between Bayeux clients running within a HTTP client and Bayeux clients running within the HTTP server. Specifically server-side Bayeux clients MAY be privileged clients with access to private information about other clients (e.g. client IDs) and subscriptions.

?

客戶端

初始化通信的程序。初始化TCP/IP連接以發送HTTP請求的HTTP客戶端就是一個客戶端。一個Bayeux客戶端初始化Bayeux消息交換，并且通常會在HTTP客戶端中執行，但是也可能在HTTP服務端中執行。運行于HTTP客戶端的Bayeux客戶端和運行于HTTP服務端中的Bayxue客戶端，實現會有區別。具體來說，服務器端的Bayeux客戶端可能更優先的訪問其他客戶端的私有信息（比如它們的client ID）和訂閱。

服務端

An application program that accepts communications from clients. A HTTP server accepts TCP/IP connections in order to service HTTP requests by sending back HTTP responses. A Bayeux server accepts and responds to the message exchanges initiated by a Bayeux client.

?

服務端
接受來自客戶端通信的應用程序。一個HTTP服務器接受TCP/IP連接，通過返回HTTP響應來服務HTTP請求。一個Bayeux服務端接受和響應由Bayeux客戶端發起的消息交換。

request
An HTTP request message as defined by section 5 of RFC 2616
請求
RFC2616 第5章節所定義的HTTP請求消息

response
?A HTTP response message as defined by section 6 of RFC 2616
響應
RFC2616 第6章節所定義的HTTP響應消息

message
A message is a JSON object exchanged between client and server for the purposed of implementing the Bayeux protocol as defined by sections 3, 4 and 5.
消息
一個消息是客戶端和服務端交互的一個JSON對象，目的就是為了實現3、4、5章節中所定義的Bayeux協議。

event
Application specific data that is sent over the Bayeux protocol
事件
通過Bayeux協議所發送的應用相關的數據

envelope
The transport specific message formate that wraps a standard Bayeux message.
信封
用來封裝標準Bayeux消息所傳輸的特定消息格式

1.4. 總體運作

1.4.1. HTTP

The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and optional body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content.

HTTP是個請求/響應協議。客戶端發送請求到服務端是基于一個到服務端的連接，所使用格式為請求方法，URI，協議版本，緊接著是包含請求描述符的一個類似MIME的消息，客戶端信息，和可選的內容體。服務端用一個狀態行來響應，包括消息的協議版本和一個成功或錯誤碼，緊接著是包含服務端信息的類似MIME的消息，實體元信息，和可能的實體內容體。

The server may not initiate a connection with a client nor send an unrequested response to the client, thus asynchronous events cannot be delivered from server to client unless a previously issued request exists. In order to allow two way asynchronous communication, Bayeux supports the use of multiple HTTP connections between a client and server, so that previously issued requests are available to transport server to client messages.

服務器不會初始化一個到客戶端的連接，也不會發送一個未請求的響應到客戶端，因此異步事件不能從服務端分發到客戶端，除非一個之前相關的連接已存在。為允許兩路異步通信，Bayeux支持一個客戶端和服務端間多HTTP連接的使用，因此之前相關的請求可用來傳輸服務端至客戶端的消息。

The recommendation of section 8.1.4 of RFC 2616 is that a single user client SHOULD NOT maintain more than 2 connection with any server, thus the Bayeux protocol MUST NOT require any more than two HTTP requests to be simultaneously handled by a server in order to handle all application (Bayeux based or otherwise) running within a client.

RFC2616中8.1.4章節所建議的是一個單獨的客戶端不應該維護和任何服務端多于2個以上的連接，因此，Bayeux協議禁止為了在一個客戶端中運行處理所有應用（基于Bayeux或其他），而有2個以上HTTP請求來被一個服務端同時處理，。

1.4.2. 非HTTP傳輸

While HTTP is the predominant transport protocol used on the internet, it is not intended that it will be the only transport for Bayeux. Other transports that support a request/response paradigm may be used. However this document assumes HTTP for reasons of clarity. When non-HTTP connection-level transport mechanisms are employed, conforming Bayeux servers and clients MUST still conform to the semantics of the JSON messages outlined in this document.

HTTP是在因特網上使用的占據統治地位的傳輸協議，并非是傳輸Bayeux的唯一方式。其他支持請求/響應模式的傳輸方式也可以被使用。為了清晰起見，本文假設使用HTTP。使用非HTTP連接級別傳輸機制時，符合Bayeux的服務端和客戶端仍必須符合文本所描述的JSON消息語義。

Several of the "transport types" described in this document are distinguished primarily by how they wrap messages for delivery over HTTP and the sequence and content of the HTTP connections initiated by clients. While this may seem like a set of implementation concerns to observant readers, the difficulties of creating interoperable implementations without specifying these semantics fully is a primary motivation for the development of this specification. Were the deployed universe of servers and clients more flexible, it may not have been necessary to develop Bayeux.

本文所描述的多種傳輸方式，其區分主要在于如何包裝在HTTP上投遞的消息，順序和客戶端發起連接的HTTP內容。雖然這可能看起來像是一系列深層次讀者才關切的實現，但創建可交互實現而不完全指定語義的難度是開發此規范的一個主要動機。要是世界范圍的服務器和客戶端能更靈活的部署，就沒有必要開發Bayeux了。

Regardless, care has been taken in the development of this specification to ensure that future clients and servers which implement differing connection-level strategies and encodings may still evolve and continue to be conforming Bayeux implementations so long as they implement the JSON-based public/subscribe semantics outlined herein.

TODO？

The rest of this document speaks as though HTTP will be used for message transport.

本文剩余部分會使用HTTP來講述消息傳輸。

1.4.3. Javascript

The majority of Bayeux clients will be implemented in JavaScript and will be running within the security framework of a client browser. For applications that need to communicate with multiple servers, the client implementation MUST adhere to the single origin policy for security.

多數Bayeux客戶端會用JavaScript實現，并運行于一個客戶端瀏覽器的安全框架內。為滿足和多服務端的通信需要，基于安全考慮，客戶端實現必須固守單源策略。

1.4.4. 客戶端至服務端的時間傳送Client to Server event delivery

A Bayeux event is sent from the client to the server via a HTTP request initiated by a user agent and transmitted to an origin server via a chain of zero or more intermediaries (proxy, gateway or tunnel):

一個Bayeux事件從客戶端發送至服務端，是由一個用戶代理發起的HTTP請求，經過若干環節的中介（代理，網關，或通道）被傳送到原始服務器端。

BC ---------- U ---------- P ------------ O ---------- BS
| --M0(E)--> | | | |
| | ---HTTP request(M0(E))--> | |
| | | | --M0(E)--> |
| | | | <---M1---- |
| | <---HTTP response(M1)---- | |
| <---M1--- | | | |
| | | | |

The figure above represents a Bayeux event E encapsulated in a Bayeux message M0 being sent from a Bayeux client BC to a Bayeux server BS via a HTTP request transmitted from a User Agent U to to an Origin server O via a proxy P. The HTTP response contains another Bayeux message M1 that will at least contain the protocol response to M0, but may contain other Bayeux events initiated on the server or on other clients.

如上圖所示，Bayeux事件E被封裝成Bayeux消息M0，從Bayeux客戶端BC發往Bayeux服務端BS，是通過從用戶代理U經由代理P到原始服務器O的HTTP請求傳輸的。HTTP響應所包含的另一個Bayeux消息M1，不僅包含M0的協議響應，也可能包含服務端或其他客戶端發起的其他Bayeux事件。

1.4.5. 服務端至客戶端的事件傳送Server to Client event delivery

A Bayeux event is sent from the server to the client via a HTTP response to a HTTP request sent in anticipation by a user agent and transmitted to an origin server via a chain of zero or more intermediaries (proxy, gateway or tunnel):

一個Bayeux事件從服務端發送至客戶端， 是由一個用戶代理預先發起HTTP請求的HTTP響應，經過若干環節的中介（代理，網關，或通道），被傳送到原始服務器端。

BC ---------- U ---------- P ------------ O ---------- BS
| ---M0---> | | | |
| | --- HTTP request(M0) ---> | |
| | | | ----M0---> |
~ ~ ~ ~ ~ wait
| | | | <--M1(E)-- |
| | <--HTTP response(M1(E))-- | |
| <--M1(E)-- | | | |
~ ~ ~ ~ ~

The figure above represents a Bayeux message M0 being sent from a Bayeux client BC to a Bayeux server BS via a HTTP request transmitted from a User Agent U to to an Origin server O via a proxy P. The message M0 is sent in anticipation of a Bayeux event to be delivered from server to client and the Bayeux server waits for such an event before sending a response. A Bayeux event E is shown being delivered via Bayeux message M1 in the HTTP response. M1 may contain zero, one or more Bayeux events destined for the Bayeux client.

如上圖所示，來自Bayeux客戶端BC的Bayeux消息M0，到達Bayeux服務端BS，是通過從用戶代理U經由代理P到原始服務器O的HTTP請求傳輸的。消息M0被發送，并期望一個Bayeux事件要從服務端被傳送到客戶端，Bayeux服務端在發送響應前會等待這樣的事件。Bayeux事件E在HTTP響應中由Bayeux消息M1發送。M1可能包含0個，1個或多個到Bayeux客戶端的Bayeux事件。

The transport used may terminate the HTTP response after delivery of M1 or use techniques to leave the response open and stream additional messages to the client.

所使用的傳輸方式在M1發送后可能中斷HTTP響應，或者使用技術保持響應打開并傳遞到客戶端的其他消息。

1.4.5.i 輪詢傳輸Polling transports

Polling transports will always terminate the HTTP response after sending all available Bayeux messages.

輪詢傳輸方式總會在發送所有可用Bayeux消息后中斷HTTP響應。

BC ---------- U ---------- P ------------ O ---------- BS
| ---M0---> | | | |
| | --- HTTP request(M0) ---> | |
| | | | ----M0---> |
~ ~ ~ ~ ~ wait
| | | | <--M1(E)-- |
| | <--HTTP response(M1(E))-- | |
| <--M1(E)-- | | | |
| ---M2---> | | | |
| | --- HTTP request(M2) ---> | |
| | | | ----M2---> |
~ ~ ~ ~ ~ wait

On receipt of the HTTP response containing M1, the Bayeux client issues a new Bayeux message M2 either immediately or after an interval in anticipation of more events to be delivered from server to client. Bayeux implementations are required to support a specific style of polling transport called "long polling" (see sec 6.1).

當收到包含M1的HTTP響應時，Bayeux客戶端立即發出一個新的Bayeux消息，或者在一個從服務端到客戶端被發送的更多事件的期望間隔后發出。Bayeux實現要求支持一個被稱為“長輪詢”的特定風格的輪詢傳輸。

1.4.5.ii 流傳輸Streaming transports

Some Bayeux transports use a streaming technique (also called a forever response) that allows multiple messages to be sent over the same HTTP response:

有些Bayeux傳輸方式使用流技術（也稱為永久響應），流技術允許多個消息通過同一個HTTP響應發送。

BC ---------- U ---------- P ------------ O ---------- BS
| ---M0---> | | | |
| | --- HTTP request(M0) ---> | |
| | | | ----M0---> |
~ ~ ~ ~ ~ wait
| | | | <--M1(E0)- |
| | <--HTTP response(M1(E0))- | |
| <--M1(E0)- | | | |
~ ~ ~ ~ ~ wait
| | | | <--M1(E1)- |
| | <----(M1(E1))------------ | |
| <--M1(E1)- | | | |
~ ~ ~ ~ ~ wait

Streaming techniques avoid the latency and extra messaging of anticipatory requests, but are subject to the implementation of user agents and proxies as they requires incomplete HTTP responses to be delivered to the Bayeux client.

流技術避免延時和額外的信息預先請求，但是對用戶代理和代理的實現有影響，因為他們需要不完整的HTTP響應以發送到Bayeux客戶端。

1.4.6. 雙連接運作Two connection operation

In order to achieve bi-directional communications, a Bayeux client will use two HTTP connections to a Bayeux server so that both server to client and client to server messaging may occur asynchronously:

為了實現雙向通信，Bayeux客戶端會使用兩個HTTP連接連接到Bayeux服務端，因此服務端到客戶端和客戶端到服務端的消息傳遞可能異步產生:

BC ---------- U ---------- P ------------ O ---------- BS
| ---M0---> | | | |
| | ------ req0(M0) --------> | |
| | | | ----M0---> |
~ ~ ~ ~ ~ wait
| --M1(E1)-> | | | |
| | ----- req1(M1(E1))------> | |
| | | | --M1(E1)-> |
| | | | <---M2---- |
| | <---- resp1(M2)---------- | |
| <---M2--- | | | |
~ ~ ~ ~ ~ wait
| | | | <-M3(E2)-- |
| | <-----resp2(M3(E2))------ | |
| <-M3(E2)-- | | | |
| ---M4---> | | | |
| | ------req3(M4)----------> | |
| | | | ----M4---> |
~ ~ ~ ~ ~ wait

HTTP requests req0 and req1 are sent on different TCP/IP connections, so that the response to req1 may be sent before the response to req0. Implementations MUST control HTTP pipelining so that req1 does not get queued behind req0 and thus enforce an ordering of responses.

HTTP請求req0和req1在不同的TCP/IP連接上發送，因此req1的響應可能在req0的響應前被發送。實現必須控制HTTP流水線處理，因此req1不能在req0前被排隊，因而能強制響應的順序。

1.4.7. 連接協商Connection Negotiation

Bayeux connections are negotiated between client and server with handshake messages that allow the connection type, authentication and other parameters to be agreed upon between the client and the server.?

Bayeux連接通過握手消息在服務端和客戶端之間協商允許的連接類型，認證和其他在客戶端和服務端約定的參數。

BC ----------------------------------------- BS
| ------------------ handshake request ---> |
| <---- handshake response ---------------- |
| -------------------- connect request ---> |
~ ~ wait
| <------ connect response ---------------- |

Connection negotiation may be iterative and several handshake messages may be exchanged before a successful connection is obtained. Servers may also request connection renegotiation by sending an unsuccessful connect response with advice to reconnect with a handshake message.

獲得一個成功的連接前，連接協商可能反復交換多個握手消息。服務端也可能要求連接重新協商，這要發送一個不成功的連接響應，并在握手消息中建議重連。

BC ----------------------------------------- BS
| ------------------ handshake request ---> |
| <-- unsuccessful handshake response ----- |
| ------------------ handshake request ---> |
| <-- successful handshake response ------- |
| -------------------- connect request ---> |
~ ~ wait
| <------ connect response ---------------- |
| -------------------- connect request ---> |
| <---- unsucessful connect response ------ |
| ------------------ handshake request ---> |
| <-- successful handshake response ------- |
| -------------------- connect request ---> |
~ ~ wait
| <------ connect response ---------------- |

1.4.8. 未連接運作Unconnected operation

OPTIONALLY, messages can be sent without a prior handshake (see 5.1 Publish event messages).

可選的，沒有預先的握手，消息也能被發送。

| ------------------- message request ----> |
| <---- message response ------------------ |

This pattern is often useful when implementing non-browser clients for Bayeux servers. These clients often simply wish to address messages to other clients which the Bayeux server may be servicing, but do not wish to listen for events themselves.

這種方式為Bayeux服務端實現非瀏覽器的客戶端時通常會有用。這些客戶端通常僅僅想發送消息到其他的有Bayeux服務端服務的客戶端，而不想注意自身的事件。

1.5 狀態表State Tables

1.5.1 客戶端狀態Client State

-------------++------------+-------------+----------- +------------
State/Event || handshake | Timeout | Successful | Disconnect
|| request | | connect | request
|| sent | | response | sent
-------------++------------+-------------+----------- +------------
UNCONNECTED || CONNECTING | UNCONNECTED | |
CONNECTING || | UNCONNECTED | CONNECTED | UNCONNECTED
CONNECTED || | UNCONNECTED | | UNCONNECTED
-------------++------------+-------------+------------+------------

2. 協議涵義Protocol values

2.1. 基本組件Common Elements

The characters used for Bayeux names and identifiers are defined by the BNF definitions:

用作Bayeux名稱和標識符的字符用BNF定義：

alpha = lowalpha | upalpha

lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"

upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"

digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"

alphanum = alpha | digit

mark = "-" | "_" | "!" | "~" | "(" | ")" | "$" | "@"

string = *( alphanum | mark | " " | "/" | "*" | "." )

token = ( alphanum | mark ) *( alphanum | mark )

integer = digit *( digit )

2.2. 通道Channel

Channels are identified by names that are styled as the absolute path component of a URI without parameters as defined by RFC2396.

TODO?

channel_name = "/" channel_segments
channel_segments = channel_segment *( "/" channel_segment )
channel_segment = token

The channel name consists of an initial "/" followed by an optional sequence of path segments separated by a single slash "/" character. Within a path segment, the character "/" is reserved.

Channel names commencing with "/meta/" are reserved protocol use. Example non-meta channel names are:

通道名稱以“/”開頭，剩下為“/”分割的可選的路徑段序列。一個路徑段內，字符“/”被保留。“/meta/”開頭的通道名稱保留為協議使用。非元通道名稱示例如下：

/foo/foo/bar/foo-bar/(foobar)

2.2.1 通道通配符Channel Globbing

A set of channels may be specified with a channel globbing pattern:

channel_pattern = *( "/" channel_segment ) "/" wild_card
wild_card = "*" | "**"

The channel patterns support only trailing wildcards of either "*" to match a single segment or "**" to match multiple segments. Example channel patterns are:

/foo/* Matches /foo/bar and /foo/boo. Does not match /foo, /foobar or /foo/bar/boo. /foo/** Matches /foo/bar, /foo/boo and /foo/bar/boo. Does not match /foo, /foobar or /foobar/boo
一組通道可以用通道通配符指定：
channel_pattern = *( "/" channel_segment ) "/" wild_card
wild_card = "*" | "**"
通道模式僅支持“*”支持單個段或“**”支持多個段的末尾通配符。示例為：
/foo/* Matches /foo/bar and /foo/boo. Does not match /foo, /foobar or /foo/bar/boo. /foo/** Matches /foo/bar, /foo/boo and /foo/bar/boo. Does not match /foo, /foobar or /foobar/boo

2.2.2 Meta通道Meta Channel

The channels within the "/meta/" segment are the channels used by the Bayeux protocol itself. Local server-side Bayeux clients MAY, and remote Bayeux clients SHOULD NOT, subscribe to meta channels. Messages published to meta channels MUST NOT be distributed to remote clients by Bayeux servers. A server side handler of a meta channel MAY publish response messages that are delivered only to the client that sent the original request message. If a message published to a meta channel contains an id field, then any response messages delivered to the client MUST contain an id field with the same value.

包含“/meta/”段的通道被Bayeux協議自身使用。本地服務器端Bayeux客戶端可以，而遠端Bayeux客戶端不應該訂閱meta通道。發布到meta通道的消息不可由Bayeux服務端分發到遠端客戶端。一個meta通道的服務端處理者可以發布消息，這些消息只能被發送到發送原始請求消息的客戶端。如果發布到meta通道的消息包含id字段，發送到這個客戶端的任何響應消息必須包含id字段，并且值相同。

2.2.3 Service通道Service Channel

The channels within the "/service/" channel segement are special channels designed to assist request/response style messaging. Messages published to service channels are not distributed to any remote Bayeux clients. Handlers of service channels MAY deliver response messages to the client that published the request message. Servers SHOULD NOT record any subscriptions they receive for service channels. If a message published to a meta channel contains an id field, then any response messages SHOULD contain an id field with the same value or a value derived from the request id. Request response operations are described in detail in section 9.

包含“/service/”段的通道是特殊的通道，被設計用來協助請求/響應風格的消息傳送。發布到service通道的消息不被分發到任何遠端Bayeux客戶端。service通道的處理者可以發送響應消息給發布請求消息的客戶端。服務端不應該記錄任何所接收到的對service通道的訂閱。如果發布到meta通道的消息包含id字段，任何響應消息應該也包含id字段，并且值相同或者值為從請求id的派生值。請求響應操作在第9章節詳細描述。

2.3. 版本Version

A protocol version is a integer followed by an optional "." separated sequence of alphanumeric elements:

version = integer *( "." version_element )
version_element = alphanum *( alphanum | "-" | "_" )

Versions are compared element by element, applying normal alphanumeric comparison to each element.

協議版本是一個整數，后面是一個可選的“.”分割的字母數字部分序列：

version = integer *( "." version_element )
version_element = alphanum *( alphanum | "-" | "_" )

版本可以逐部分來比較，每部分使用通常的字母數字比較方式。

2.4. 客戶端IDClient ID

A client ID is an random, non predictable sequence of alpha numeric characters:

clientId = alphanum *( alphanum )

Client IDs are generated by the server and SHOULD be created with a strong random algorithm that contains at least 128 truly random bits. Servers MUST ensure that client IDs are unique and SHOULD attempt to avoid reuse of client IDs. Client IDs are encoded for delivery as JSON strings.

客戶端ID是一個隨機數，不可預計的字母數字字符序列：

clientId = alphanum *( alphanum )

客戶端ID由服務端生成，應該用強大的隨機數算法創建，至少要包含128位精確的隨機位。服務端必須確保客戶端ID唯一并應該盡量重用客戶端ID。客戶端ID被編碼成JSON字符串傳送。

2.5 消息Messages

Bayeux messages are JSON encoded objects that contain an unordered sequence of name value pairs representing fields and values. Values may be a simple strings, numbers, boolean values, or complex JSON encoded objects. A Bayeux message MUST contain one and only one channel field which determines the type of the message and the allowable fields.

All Bayeux messages SHOULD be encapsulated in a JSON array so that multiple messages may be transported together. A Bayeux client or server MUST accept either array of messages and MAY accept a single message. The JSON message or array of messages is itself often encapsulated in transport specific formatting and encodings. Below is an example Bayeux message in a JSON array representing an event sent from a client to a server:

[
{
"channel": "/some/name",
"clientId": "83js73jsh29sjd92",
"data": { "myapp" : "specific data", value: 100 }
}
]
Bayeux消息用JSON對象編碼，JSON對象包含表示字段和值的沒有順序的明值對序列。值可以是簡單字符串，數字，布爾值，或者復雜的JSON編碼的對象。一個Bayeux消息必須有且僅有一個channel字段，它決定了消息類型和可以容許的字段。
所有的Bayeux應該封裝到一個JSON數組中，因此多個消息可以一起傳輸。一個Bayeux客戶端或服務端必須接受消息數組，也可以接受單個消息。JSON消息或消息數組自身常被封裝成傳輸方式特定的格式和編碼。下面是一個Bayeux消息的例子，使用JSON數組表示從一個客戶端到一個服務端發送的事件。

3. 消息字段定義Message Field Definitions

3.1. 通道channel

The channel message field MUST be included in every Bayeux message to specify the source or destination of the message. In a request, the channel specifies the destination of the message, and in a response it specifies the source of the message.

通道消息字段必須包含在每個Bayeux消息中，以指定消息的源或目的。在一個請求中，通道指定了消息的目的地，而在一個響應中它制定了消息的源。

3.2. 版本version

The version message field MUST be included in messages to/from the "/meta/handshake" channel to indicate the protocol version expected by the client/server.

版本消息字段必須包含在到或者來自“/meta/handshake”通道的消息中，表明客戶端/服務端期望的協議版本。

3.3. 最小版本minimumVersion

The minimumVersion message field MAY be included in messages to/from the "/meta/handshake" channel to indicate the oldest protocol version that can be handled by the client/server.

最小版本消息字段可以包含在到或者來自“/meta/handshake”通道的消息中，表明客戶端/服務端所能處理的最低協議版本。

3.4. 支持連接類型supportedConnectionTypes

The supportedConnectionTypes field is included in messages to/from the "/meta/handshake" channel to allow clients and servers to reveal the transports that are supported. The value is an array of strings, with each string representing a transport name. Defined connection types include:

支持連接類型字段包含在到或者來自“/meta/handshake”通道的消息中，允許客戶端和服務端暴露支持的傳輸方式。值為字符串數組，每個字符串代表一種傳輸方式名稱。定義的連接類型包括：

long-polling
messages are sent to the server as the 'message' parameter of a application/x-www-form-urlencoded encoded POST request. Messages are sent to the client as unencapsulated body content of a POST response. This transport is defined in section [XXX] of this memo.
長輪詢
消息通過application/x-www-form-urlencoded編碼的POST請求的message參數發送到服務端。消息通過未封裝的POST響應體發送客戶端。這種傳輸方式定義在本備忘錄的XXX章節中。

callback-polling
messages are sent to the server as the 'message' parameter of a url encoded GET request. Responses are sent wrapped in a JavaScript callback in order to facilitate delivery. As specified by the JSON-P pseudo-protocol, the name of the callback to be triggered is passed to the server via the 'jsonp' GET parameter. In the absence of such a parameter, the name of the callback defaults to 'jsonpcallback'.
回調輪詢
消息通過通過url編碼的GET請求的message參數發送到服務端。為容易發送，響應被封裝到JavaScript回調函數中發送。按照JSON-P偽協議規范，被觸發的回調函數名稱作為jsonp GET參數傳送到服務端。如果此參數不存在，回調函數名字默認為jsonpcallback。

iframe
OPTIONAL transport using the document content of a hidden iframe element.
iframe
可選的 用一個隱藏iframe元素的文檔內容傳輸

flash
OPTIONAL transport using the capabilities of a browser flash plugin.

flash

可選的 用瀏覽器的flash插件功能傳輸

All server and client implementations MUST support the "long-polling" connection type and SHOULD support "callback-polling". All other connection types are OPTIONAL.

所有服務端和客戶端實現必須支持“長輪詢”連接類型，并且應該支持“回調輪詢”。其他連接類型都是可選的。

3.5. clientId

The clientId message field uniquely identifies a client to a Bayeux server. The clientId message field MUST be included in every message sent to the server except for a messages sent to the "/meta/handshake" channel and a publish message (see 5.1 Publish event messages). The clientId field MUST be returned in every message response except for a failed handshake request and is OPTIONAL in a message delivery message.

clientId消息字段唯一標識到一個Bayeux服務端的一個客戶端。clientId消息字段必須包含在每個發往服務端的哦消息中，除了發往/meta/channel通道的消息和publish消息（參考 5.1 發布事件消息）。除了失敗的握手請求響應，clientId字段必須在每個響應消息中中返回，clientId在消息到消息中是可選的。

3.6. 建議advice

The advice field provides a way for servers to inform clients of their preferred mode of client operation so that in conjunction with server-enforced limits, Bayeux implementations can prevent resource exhaustion and inelegant failure modes.

advice字段為服務端提供了一種通知客戶端他們首選的客戶端操作模式，因此，結合強加的服務端限制，Bayeux實現能避免資源耗盡和不雅的失敗情形。

The advice field is a JSON map containing general and transport specific values that indicate modes of operation, timeouts and other potential transport specific parameters. Fields may occur either in the top level of an advice or within a transport specific section.

advice字段是一個JSON對象，包含了通用值和傳輸方式特定的值，有操作模式，超時，和其他潛在的特定傳輸方式參數。字段既可以在advice頂層也可以在傳輸方式特定段內。

Unless otherwise specified in sections 5 and 6, any Bayeux response message may contain an advice field. Advice received always superceeds any previous received advice.

An example advice field is

"advice": {
"reconnect": "retry",
"interval": 1000,
"callback-polling" : {
"reconnect": "handshake"
}
}
除非是章節5和6指定的，其他任何Bayeux響應消息都可以包含一個advice字段。收到的advice總是替代之前接受的任何advice。
advice字段示例如下：
"advice": {
?? ? "reconnect": "retry",
?? ? "interval": 1000,
?? ? "callback-polling" : {
?? ??? ? "reconnect": "handshake"
?? ? }
}

3.6.1. 重連advice reconnect advice

The reconnect advice field is a string that indicates how the client should act in the case of a failure to connect. Defined reconnect values are:

重連advice字段是一個字符串，表明了客戶端在連接失敗的情況下應該如何操作。重連值定義有：

retry
a client MAY attempt to reconnect with a /meta/connect after the interval (as defined by "interval" advice or client-default backoff), and with the same credentials.
重試
客戶端可以在一定間隔（按照interval advice定義或客戶端默認延時）后用同樣的證書重連到/meta/connect。

handshake
the server has terminated any prior connection status and the client MUST reconnect with a /meta/handshake. A client MUST NOT automatically retry if handshake advice has been received.
握手
服務端已經終止所有之前的連接狀態，客戶端必須重連到/meta/handshake。如果客戶端已經收到握手advice則禁止自動重試。

none
hard failure for the connect attempt. Do not attempt to reconnect at all. A client MUST respect reconnect advice of none and MUST NOT automatically retry or handshake. Any client that does not implement all defined values of reconnect MUST NOT automatically retry or handshake.
無
連接完全失敗。不要再試圖連接。客戶端必須重視none重連advice，并禁止自動重試或握手。不實現全部reconnect定義值的客戶端禁止自動重連或握手。

3.6.2. 間隔advice interval advice

An integer representing the minimum period in milliseconds for a client to delay subsequent requests to the /meta/connect channel. A negative period indicates that the message should not be retried.

A client MUST implement interval support, but a client MAY exceed the interval provided by the server. A client SHOULD implement a backoff strategy to increase the interval if requests to the server fail without new advice being received from the server.?

一個提供給客戶端的以秒為單位的整數所表示的最小周期，來推遲后續到/meta/connect通道的請求。

客戶端必須實現間隔支持，但是一個客戶端可以超過服務端提供的間隔。如果到服務端請求失敗而沒有收到新的advice，則客戶端必須實現一種退避策略以增加間隔。

3.6.3. 多客戶端advice multiple-clients advice

This is a boolean field, which if true indicates that the server has detected multiple Bayeux client instances running within the same HTTP client.

多客戶端advice是一個布爾值字段，如果為真則表示服務端已經偵測到多個Bayeux客戶端實例運行在同一個http客戶端中。

3.6.4. 主機advice hosts advice

This is an array of strings field, which if present indicates a list of host names or IP addresses that MAY be used as alternate servers with which the client may connect. If a client receives advice to re-handshake and the current server is not included in a supplied hosts list, then the client SHOULD try the hosts in order until a successful connection is establish. Advice received during handshakes with hosts in the list supercedes any previously received advice.

主機advice是一個數組字符串字段，所表示的是一個主機名或IP地址列表，可作為候選服務器與客戶端連接。如果一個客戶端接收到重新握手的advice，而當前服務器不包含在提供的主機列表中，客戶端就應該按順序嘗試這些主機，知道成功建立一個連接。和列表中的主機握手過程中收到的advice，要替代之前收到的任何advice。

3.7. 連接類型 connectionType

The connectionType message field specifies the type of transport the client requires for communication. The connectionType message field MUST be included in request messages to the "/meta/connect" channel. Connection types are defined in section 4.7.

連接類型消息字段指定了客戶端用來通信所需的傳輸類型。連接類型消息字段必須包含在到/meta/connect通道的請求消息中。連接類型定影在章節4.7。

3.8. id

An id field MAY be included in any Bayeux message with an alpha numeric value:

id = alphanum *( alphanum )

Generation of IDs is implementation specific and may be provided by the application. Messages published to /meta/** and /service/** SHOULD have id fields that are unique within the the connection.

Messages sent in response to messages delivered to /meta/** channels MUST use the same message id as the request message.

Messages sent in response to messages delivered to /service/** channels SHOULD use the same message id as the request message or an id derived from the request message id.

一個字符數字值的id字段可以包含在任何Bayeux消息中：

id = alphanum *( alphanum )

ID的生成是實現相關的，也可有應用提供。發布到/meta/*和/service/*的消息，應該好漢id字段，并在連接內唯一。

發送到 /meta/** 通道的消息的響應消息，必須使用和請求消息同樣的消息id。

發送到 /service/**通道的消息的響應消息，應該使用和請求消息同樣的消息id，或者派生自請求消息id。

3.9. 時間戳 timestamp

The timestamp message field SHOULD be specified in the following ISO 8601 profile: All times SHOULD be sent in GMT time.

YYYY-MM-DDThh:mm:ss.ss
A timestamp message field is OPTIONAL in all Bayeux messages.
時間戳消息字段應該指定為下面的ISO8601格式：所有時間應該用GMT時間發送。
YYYY-MM-DDThh:mm:ss.ss
時間戳消息字段在任何Bayeux消息中都是可選的。

3.10. 數據 data

The data message field is an arbitrary JSON object that contains event information. The data field MUST be included in publish requests, and a Bayeux server MUST include the data field in an event delivery message.

數據消息字段是一個包含時間信息的任意的JSON對象。數據字段必須包含在publish請求中，并且Bayeux服務端也必須在時間發送消息中包含數據字段。

3.11. 連接Id connectionId

The connectionId field was used during development of the Bayeux protocol and its use is now deprecated.

連接Id字段在Bayeux開發階段使用，現在已經不推薦使用。

3.12. 成功的 successful

The successful boolean message field is used to indicate success or failure and MUST be included in responses to the "/meta/handshake", "/meta/connect", "/meta/subscribe","/meta/unsubscribe", "/meta/disconnect", and publish channels.

成功布爾消息字段用來表明成功或失敗，必須包含在到"/meta/handshake", "/meta/connect", "/meta/subscribe","/meta/unsubscribe", "/meta/disconnect", 和publish通道消息的響應中。

3.13. 訂閱 subscription

The subscription message field specific the channels the client wishes to subscribe to or unsubscribe from. The subscription message field MUST be included in requests and responses to/from the "/meta/subscribe" or "/meta/unsubscribe" channels.

訂閱消息字段明確了客戶端想訂閱的和接觸訂閱的通道。訂閱消息字段必須包含在"/meta/subscribe"通道的請求中，或者"/meta/unsubscribe"通道的響應中。

3.14. 錯誤 error

The error message field is OPTIONAL on any Bayeux response. The error message field MAY indicate the type of error that occurred when a request returns with a false successful message. The error message field should be sent as a string in the following format:

error = error_code ":" error_args ":" error_message
| error_code ":" ":" error_message
error_code = digit digit digit
error_args = string *( "," string )
error_message = string

Example error strings are:

401::No client ID
402:xj3sjdsjdsjad:Unknown Client ID
403:xj3sjdsjdsjad,/foo/bar:Subscription denied
404:/foo/bar:Unknown Channel
Need to provide list of codes
錯誤消息字段在任何Bayeux響應中都是可選的。當一個請求返回不成功消息時，錯誤消息字段可以表明發生的錯誤類型。錯誤消息字段應該按照以下格式的字符串被發送：
error = error_code ":" error_args ":" error_message
| error_code ":" ":" error_message
error_code = digit digit digit
error_args = string *( "," string )
error_message = string

Example error strings are:

401::No client ID
402:xj3sjdsjdsjad:Unknown Client ID
403:xj3sjdsjdsjad,/foo/bar:Subscription denied
404:/foo/bar:Unknown Channel
Need to provide list of codes

3.15. 擴展 ext

An ext field MAY be included in any Bayeux message. Its value SHOULD be a JSON map with top level names distinguished by implementation names (eg. "org.dojo.Bayeux.field").

The contents of ext may be arbitrary values that allow extensions to be negotiated and implemented between server and client implementations.

擴展字段可以包含在任何Bayeux消息中，它的值應該是以實現名稱顯著顯示的頂級名稱（如："org.dojo.Bayeux.field"）的JSON map。擴展內容可以是任意值，這些值允許擴展被協商和實現在服務端和客戶端實現之間。

3.16. json-comment-filtered

The json-comment-filtered ext field of the handshake message is deprecated.
握手消息的json-comment-filtered擴展字段已經不推薦使用。

4. Meta消息定義 Meta Message Definitions

4.1. 握手 handshake

4.1.1. 握手請求 handshake Request

A Bayeux client initiates a connection negotiation by sending a message to the "/meta/handshake" channel. For same domain connections, the Handshake requests MUST be sent to the server as the 'message' parameter of an application/x-www-form-urlencoded encoded POST request. For cross domain connections, the Handshake request MUST be sent to the server as a url encoded GET request with the jsonp parameter set for callback-polling.

一個Bayeux客戶端往/meta/handshake發送一個消息來開始一個連接協商。對同域連接，握手請求必須做為application/x-www-form-urlencoded編碼的POST請求的message參數發送到服務端。對跨域連接，握手請求必須作為url編碼的GET請求的為回調輪詢設置的jsonp參數發往服務端。

A handshake request MUST contain the message fields:

channel
value "/meta/handshake"
version
The version of the protocol supported by the client.
supportedConnectionTypes
An array of the connection types supported by the client for the purposes of the connection being negotiated. This list MAY be a subset of the connection types actually supported if the client wishes to negotiate a specific connection type.
一個握手請求必須包含的消息字段：
channel
value "/meta/handshake"
值為 /meta/handshake
version
The version of the protocol supported by the client.
客戶端支持的協議版本
supportedConnectionTypes
An array of the connection types supported by the client for the purposes of the connection being negotiated. This list MAY be a subset of the connection types actually supported if the client wishes to negotiate a specific connection type.
客戶端支持的一個連接類型數組，用做連接協商。如果客戶端想協商為一種特定的連接類型，則支持的連接類型列表可以是實際支持連接類型的子列表。

A handshake request MAY contain the message fields:

一個握手請求可以包含的消息字段：

minimumVersion
ext
id

A client SHOULD NOT send any other message in the request with a handshake message. A server MUST ignore any other message sent in the same request as a handshake message. An example handshake request is:

[
{
"channel": "/meta/handshake",
"version": "1.0",
"minimumVersion": "1.0beta",
"supportedConnectionTypes": ["long-polling", "callback-polling", "iframe"]
}
]
客戶端不應該在握手消息的請求中發送其他消息。服務端必須忽略和握手消息中同一個請求中的其他消息。
握手請求示例如下：
[
{
"channel": "/meta/handshake",
"version": "1.0",
"minimumVersion": "1.0beta",
"supportedConnectionTypes": ["long-polling", "callback-polling", "iframe"]
}
]

4.1.2. 握手響應 handshake Response

A Bayeux server MUST respond to a handshake request with a handshake response message in the body content of the response. For cross domain connections that have the 'jsonp' parameter set, the message body may be encapsulated in a jsonp callback method.

Bayeux服務端必須在響應體內容中包含握手響應消息對握手請求作出響應。對設置jsonp參數的跨域連接，消息體必須封裝在json回調方法中。

Successful handshake response

成功的握手響應

A successful handshake responses MUST contain the message fields:

一個成功的握手影響必須包含以下消息字段：

channel
value "/meta/handshake"
值為 /meta/handshake
?
version
supportedConnectionTypes
The connection types supported by the server for the purposes of the connection being negotiated. This list MAY be a subset of the connection types actually supported if the server wishes to negotiate a specific connection type. This list MUST contain at list one element in common with the supportedConnectionType provided in the handshake request. If there are no connectionTypes in common, the handshake response MUST be unsuccessful.
服務端支持的連接類型，用作連接協商。如果服務端想協商為一種特定的連接類型，則連接支持列表可以是實際支持的子列表。服務端連接支持列表必須至少包含一種，和握手請求中支持連接類型中所提供的相同。如果沒有共有的連接類型，握手響應就必須是不成功的。
?
clientId
A newly generated unique clientId.
一個新產生的唯一的clientId。
?
successful
value true
值為真

A successful handshake response MAY contain the message fields:

一個成功的握手響應可以包含的消息字段：

minimumVersionadvice
ext
id
same value as request message id
和請求消息id相同

authSuccessful
Value true, this field may be included to support prototype client implementations that required the authSuccessful field
值為真，這個字段可以包含，以支持需要authSuccessful字段的原型客戶端實現。
?
An example successful handshake response is: [
{
"channel": "/meta/handshake",
"version": "1.0",
"minimumVersion": "1.0beta",
"supportedConnectionTypes": ["long-polling","callback-polling"],
"clientId": "Un1q31d3nt1f13r",
"successful": true,
"authSuccessful": true,
"advice": { "reconnect": "retry" }
}
]

Unsuccessful handshake response

不成功握手響應

An unsuccessful handshake response MUST contain the message fields:

不成功的握手響應必須包含的消息字段：

channel
value "/meta/handshake"
值為/meta/handshake
successful
value false
值為false
error
a string with the description of the reason for the failure.
失敗原因的描述字符串

An unsuccessful handshake response MAY contain the message fields:

一個不成功的握手響應可以包含的消息字段：

supportedConnectionTypes
The connection types supported by the server for the purposes of the connection being negotiated. This list MAY be a subset of the connection types actually supported if the server wishes to negotiate a specific connection type.
服務端支持的連接類型，用作連接協商。如果服務端想協商為一種特定的連接類型，則連接支持列表可以是實際支持的子列表。
advice
version
minimumVersion
ext
id
same value as request message id
和請求消息id相同

An example unsuccessful handshake response is:

一個不成功的握手響應例子為：

[
{
"channel": "/meta/handshake",
"version": "1.0",
"minimumVersion": "1.0beta",
"supportedConnectionTypes": ["long-polling","callback-polling"],
"successful": false,
"error": "Authentication failed",
"advice": { "reconnect": "none" }
}
]

For complex connection negotiations, multiple handshake messages may be exchanged between the Bayeux client and server. The handshake response will set the "successful" field to false until the handshake processs is complete. The advice and ext fields may be used to communicate additional information needed to complete the handshake process. An unsuccessful handshake response with reconnect advice of "handshake" is used to continue the connection negotiation. An unsuccessful handshake response with reconnect advice of "none" is used to terminate connection negotiations.

對于復雜的連接協商，Bayeux客戶端和服務端之間可能有多個握手消息交互。握手響應會設置successful字段為false，直到握手過程完成。advice和ext字段可以用來傳送完成握手過程所需的額外信息。一個帶有重連advice“handshake”的不成功的握手響應常用來繼續連接協商。一個帶有重連advice“none”的不成功的握手響應，常用來終止連接協商。

4.2. 連接 connect

4.2.1. 連接請求 connect Request

After a Bayeux client has discovered the server's capabilities with a handshake exchange, a connection is established by sending a message to the "/meta/connect" channel. This message may be transported over any of the transports indicated as supported by the server in the handshake response.

經過握手交互一個Bayeux客戶端發現了服務端的能力后，依靠發送給“/meta/connect”通道一個消息來建立一個連接。這個消息可以使用握手響應中服務端表明所支持的任何傳輸方式來傳輸。

A connect request MUST contain the message fields:

一個連接請求必須包含的消息字段：

?

channel
value "/meta/connect"
值為“/meta/connect”
clientId
The client ID returned in the handshake response
握手響應中返回的客戶端ID
connectionType
The connection type used by the client for the purposes of this connection.
客戶端連接所使用的連接類型。

A connect request MAY contain the message fields:

一個連接請求可能包含的消息字段：

ext
id

A client MAY send other messages in the same HTTP request with a connection message. A server MUST handle any other message sent in the same request as a connect message after the handling of the connect message is complete.

一個客戶端可以在和一個連接消息同樣的HTTP請求中發送其他消息。服務端必須在連接消息處理完成后，處理和連接消息同樣請求中發送的其他任何消息。

An example connect request is:

一個連接請求的例子為：

[
{
"channel": "/meta/connect",
"clientId": "Un1q31d3nt1f13r",
"connectionType": "long-polling"
}
]

A transport MUST maintain one and only one outstanding connect message. When a HTTP response that contains a /meta/connect response terminates, the client MUST wait at least the interval specified in the last received advice before following the advice to reestablish the connection

一個傳輸通道必須維持一個且僅有一個未決連接信息。當一個HTTP響應包含了一個/meta/connect響應終止時，客戶端必須至少等待上一個收到的advice指定的間隔后，才能繼續建議連接。

4.2.2. 連接響應 connect Response

A Bayeux server MUST respond to a connect request with a connect response message over the same transport as used for the request.

Bayeux服務端必須基于和請求相同的傳輸方式，用請求響應消息對連接請求做出響應。

A Bayeux server MAY wait to respond until there are event messages available in the subscribed channels for the client that need to be delivered to the client.?

Bayeux服務器可以一直等待，直到客戶端訂閱的通道上有事件消息需要發送到客戶端時，再做出響應。

A connect responses MUST contain the message fields:

一個連接響應必須包含的消息字段：

channel
value "/meta/connect"
值為/meta/connect
successful
boolean indicating the success or failure of the connection
指示連接失敗或成功的布爾值
clientId
The negotiated client ID
協商的客戶端ID

A connect response MAY contain the message fields:

一個連接響應可能包含的消息字段：

error
advice
ext
id
same value as request message id
和請求消息id相同
timestamp

An example connect response is:

連接響應的一個例子：

[
{
"channel": "/meta/connect",
"successful": true,
"error": "",
"clientId": "Un1q31d3nt1f13r",
"timestamp": "12:00:00 1970",
"advice": { "reconnect": "retry" }
}
]

The client MUST maintain only a single outstanding connect message. If the server does not have a current outstanding connect and a connect is not received within a configured timeout, then the server SHOULD act as if a disconnect message has been received.

客戶端必須維護唯一的未決連接消息。如果服務端沒有一個當前未決的連接，并且在配置的超時時間內，沒有收到一個連接，服務端應該認為收到了一個斷開消息。

4.4. 斷開 disconnect

4.4.1. 斷開請求 disconnect Request

When a connected client wishes to cease operation it should send a request to the "/meta/disconnect" channel for the server to remove any client-related state. The server SHOULD release any waiting meta message handlers. Bayeux client applications should send a disconnect request when the user shuts down a browser window or leaves the current page. A Bayeux server SHOULD not rely solely on the client sending a disconnect message to remove client-related state information because a disconnect message might not be sent from the client or the disconnect request might not reach the server.?

一個已連接客戶端想終止操作的時候，它應該給/meta/disconnect通道發送一個請求，讓服務端移除任何客戶端相關的狀態。服務端應該釋放任何等待中的元消息處理。當用戶關閉瀏覽器窗口或者離開當前頁面時，Bayeux客戶端應用應該發送一個斷開請求。Bayeux服務端不應該只依賴于客戶端發送斷開消息才移除客戶端相關的狀態信息，因為斷開消息可能不從客戶端發送或者斷開請求不會到達服務端。

A disconnect request MUST contain the message fields:
一個斷開請求必須包含的消息字段：
channel
value "/meta/disconnect"
值為/meta/disconnect
clientId
The client ID returned in the handshake response
握手響應中返回的客戶端ID

A disconnect request MAY contain the message fields:

一個斷開請求可能包含的消息字段：

ext
id
An example disconnect request is:
斷開請求的一個例子：
[
{
"channel": "/meta/disconnect",
"clientId": "Un1q31d3nt1f13r"
}
]

4.4.2. 斷開響應 disconnect Response

A Bayeux server MUST respond to a disconnect request with a disconnect response.

Bayeux服務端必須用一個斷開響應對一個斷開請求作出響應。

A disconnect response MUST contain the message fields:

一個斷開響應必須包含的消息字段：

channel
value "/meta/disconnect"
值為/meta/disconnect
clientId
The client ID returned in the handshake response
握手響應中返回的客戶端ID
successful
boolean value indicated the success or failure of the disconnect request
表明斷開請求成功或失敗的布爾值

A disconnect response MAY contain the message fields:

一個斷開響應可能包含的消息字段：

error
ext
id
same value as request message id
和請求消息id相同

An example disconnect response is:
一個斷開響應的例子：
[
{
"channel": "/meta/disconnect",
"clientId": "Un1q31d3nt1f13r",
"successful": true
}
]

4.5. 訂閱 subscribe

4.5.1. 訂閱請求 subscribe Request

A connected Bayeux client may send subscribe messages to register interest in a channel and to request that messages published to the subscribe channel are delivered to the client.

一個已連接Bayeux客戶端可以發送訂閱消息，登記關心的一個通道，并請求發布到這個訂閱通道的消息被發送到這個客戶端。

A subscribe request MUST contain the message fields:

一個訂閱請求必須包含的消息字段：

channel
value "/meta/subscribe"
值為“/meta/subscribe”
clientId
The client ID returned in the handshake response
握手響應中返回的客戶端ID
subscription
a channel name or a channel pattern or an array of channel names and channel patterns.
一個通道名稱或者一個通道模式或者一個通道名稱和通道模式的數組

A subscribe request MAY contain the message fields:

一個訂閱請求可能包含的消息字段：

ext
id

An example subscribe request is:

一個訂閱請求的例子：

[
{
"channel": "/meta/subscribe",
"clientId": "Un1q31d3nt1f13r",
"subscription": "/foo/**"
}
]

4.5.2. 訂閱響應 subscribe Response

A Bayeux server MUST respond to a subscribe request with a subscribe response message.

Bayeux服務端必須用訂閱響應消息對訂閱請求作出響應。

A Bayeux server MAY send event messages for the client in the same HTTP response as the subscribe response, including events for the channels just subscribed to.

Bayeux服務端可以在和訂閱響應同樣的HTTP響應中給客戶端發送事件消息，包括所訂閱通道的事件。

A subscribe responses MUST contain the message fields:

一個訂閱響應必須包含的消息字段：

channel
value "/meta/subscribe"
值為"/meta/subscribe"
successful
boolean indicating the success or failure of the subscribe
表明訂閱成功或失敗的布爾值
clientId
The negotiated client ID
協商的客戶端ID
subscription
a channel name or a channel pattern or an array of channel names and channel patterns.
一個通道名稱或者一個通道模式或者一個通道名稱和通道模式的數組

A subscribe response MAY contain the message fields:
一個訂閱響應可能包含的消息字段：
error
advice
ext
id
same value as request message id
和請求消息id相同
timestamp
An example successful subscribe response is:
一個成功的訂閱響應例子：
[
{
"channel": "/meta/subscribe",
"clientId": "Un1q31d3nt1f13r",
"subscription": "/foo/**",
"successful": true,
"error": ""
}
]
An example failed subscribe response is:
一個失敗的訂閱響應例子：
[
{
"channel": "/meta/subscribe",
"clientId": "Un1q31d3nt1f13r",
"subscription": "/bar/baz",
"successful": false,
"error": "403:/bar/baz:Permission Denied"
}
]

4.6. 取消訂閱 unsubscribe

4.6.1. 取消訂閱請求 unsubscribe Request

A connected Bayeux client may send unsubscribe messages to cancel interest in a channel and to stop published message delivery from the server to the unsubscribe channel.

一個已連接Bayeux客戶端可以發送取消訂閱消息，取消關心的一個通道，并停止從服務端投遞到取消訂閱通道的發布消息。

A unsubscribe request MUST contain the message fields:

一個取消訂閱請求必須包含的消息字段：

channel
value "/meta/unsubscribe"
值為"/meta/unsubscribe"
clientId
The client ID returned in the handshake response
握手響應中返回的客戶端ID
subscription
a channel name or a channel pattern or an array of channel names and channel patterns.
一個通道名稱或者一個通道模式或者一個通道名稱和通道模式的數組

A unsubscribe request MAY contain the message fields:

一個取消訂閱請求可能包含的消息字段：

ext
id
An example unsubscribe request is:
一個取消訂閱請求的例子：
[
{
"channel": "/meta/unsubscribe",
"clientId": "Un1q31d3nt1f13r",
"subscription": "/foo/**"
}
]

4.6.2. 取消訂閱響應 unsubscribe Response

A Bayeux server MUST respond to a unsubscribe request with a unsubscribe response message.

Bayeux服務端必須用取消訂閱響應消息對取消訂閱請求做出響應。

A Bayeux server MAY send event messages for the client in the same HTTP response as the unsubscribe response, including events for the channels just unsubscribed to as long as the event was processed before the unsubscribe request.

Bayeux服務端可以在和取消訂閱響應同樣的HTTP響應中給客戶端發送事件消息，包括取消訂閱通道的事件，只要事件在取消請求前處理。

A unsubscribe responses MUST contain the message fields:
一個取消訂閱響應必須包含的消息字段：
channel
value "/meta/unsubscribe"
值為"/meta/unsubscribe"
successful
boolean indicating the success or failure of the unsubscribe operation
表明取消訂閱操作成功或失敗的布爾值
clientId
The negotiated client ID
subscription
a channel name or a channel pattern or an array of channel names and channel patterns.
一個通道名稱或者一個通道模式或者一個通道名稱和通道模式的數組

A unsubscribe response MAY contain the message fields:
一個取消訂閱響應可能包含的消息字段：
error
advice
ext
id
same value as request message id
和請求消息id相同
timestamp
An example unsubscribe response is:
一個取消訂閱響應的例子：
[
{
"channel": "/meta/unsubscribe",
"clientId": "Un1q31d3nt1f13r",
"subscription": "/foo/**",
"successful": true,
"error": ""
}
]

5. 事件消息定義 Event Message Definitions

Application events are published in event messages sent from a Bayeux client to a Bayeux server and are delivered in event messages sent from a Bayeux server to a Bayeux client.
應用事件通過Bayeux客戶端發送到Bayeux服務端的事件消息發布，并通過Bayeux服務端發送到Bayeux客戶端的事件消息傳送。

5.1. 發布事件消息 Publish event messages

5.1.1. 發布請求 publish Request

A Bayeux client can publish events on a channel by sending event messages. An event message MAY be sent in new HTTP request or it MAY be sent in the same HTTP request as any message other than a handshake meta message.

Bayeux客戶端能在通道上發送事件消息發布事件。一個事件消息可以在新的HTTP請求中發送，或者可以和除了握手元消息之外的任何消息相同的HTTP請求中發送。

A publish message may be sent from an unconnected client (that has not performed handshaking and thus does not have a client ID). It is OPTIONAL for a server to accept unconnected publish requests and they should apply server specific authentication and authorization before doing so.?

一個發布消息可以從一個未連接的客戶端發送（還沒有握手因此沒有客戶端ID）。服務端接受未連接的發布請求是可選的，因此他們應該在這么做之前應用服務端特定的認證和授權。

A publish event message MUST contain the message fields:
一個發布事件消息必須包含的消息字段：
channel
data
The message as an arbitrary JSON object
消息可以是任何的JSON對象

A publish event message MAY contain the message fields:
一個發布事件消息可能包含的消息字段：
clientId
The negotiated client ID
協商的客戶端ID
id
A unique ID for the message generated by the client
客戶端生成的唯一消息ID
ext

An example event message is:
一個事件消息的例子：
[
{
"channel": "/some/channel",
"clientId": "Un1q31d3nt1f13r",
"data": "some application string or JSON object",
"id": "some unique message id"
}
]

5.1.2. 發布響應 publish Response

A Bayeux server MAY respond to a publish event message with a publish event acknowlegement.

服務端可以用發布事件確認對發布事件消息做出響應。

A publish event message MUST contain the message fields:
一個發布事件消息必須包含的消息字段：
channel
successful
boolean indicating the success or otherwise of the publish
表明發布成功或其它的布爾值

A publish event response MAY contain the message fields:
一個發布事件響應可能包含的消息字段：
id
error
ext
An example event reponse message is:
一個事件響應消息的例子：
[
{
"channel": "/some/channel",
"successful": true,
"id": "some unique message id"
}
]

5.2. 傳送事件消息 Deliver Event messages

Event messages are delivered to clients if the client is subscribed to the channel of the event message. Event messages may be sent to the client in the same HTTP response as any other message other than a meta handshake response. If a Bayeux server has multiple HTTP requests from the same client, the server SHOULD deliver all available messages in the HTTP response that will be sent immediately in preference to waking a waiting connect meta message handler. Event message delivery is not acknowledged by the client.

如果客戶端訂閱到事件消息的通道，事件消息就可以被傳送到客戶端。事件消息可以在除了元握手響應之外的任何消息相同的HTTP響應中被發往客戶端。如果Bayeux服務端有來自同一客戶端的多個HTTP請求，服務端應該在HTTP響應中傳送所有可用消息，TODO

事件消息傳送不必被客戶端確認。

A deliver event message MUST contain the message fields:

一個傳送事件消息必須包含的消息字段：

channel
data
The message as an arbitrary JSON object
消息可以是任何的JSON對象

A deliver event response MAY contain the message fields:
一個傳送事件響應可能包含的消息字段：
id
Unique message ID from the publisher
來自發布者的唯一消息ID
clientId
The client ID of the publisher
發布者的客戶端ID
ext
advice

An example event deliver message is:
一個事件傳送消息的例子：
[
{
"channel": "/some/channel",
"data": "some application string or JSON object",
"id": "some unique message id"
}
]

6. 傳輸 Transports

6.1. 長輪詢 long-polling

"Long-polling" is a polling transport that attempts to minimize both latency in server-client message delivery, and the processing/network resources required for the connection. In "traditional" polling, servers send and close responses to requests immediately, even when there are no events to deliver, and worst-case latency is the polling delay between each client request. Long-polling server implementations attempt to hold open each request until there are events to deliver; the goal is to always have a pending request available to use for delivering events as they occur, thereby minimizing the latency in message delivery. Increased server load and resource starvation are addressed by using the reconnect and interval advice fields to throttle clients, which in the worst-case degenerate to traditional polling behaviour.
長輪詢是一種輪詢方式，這種方式試圖最小化服務端-客戶端消息傳送延遲和連接的處理/網絡資源消耗。傳統的輪詢中，服務端發送并立即關閉到請求的響應，尤其是沒有事件傳送時，并且最糟糕情況下的延時就是每個客戶端請求之間輪詢的耽擱。長輪詢服務端實現試圖保持打開每一個請求，直到有事件要傳送；目的就是總有一個可用的未決請求在有事件發生時傳送事件，因此最小化了消息傳送的延時。靠使用重連和間隔建議字段應對增加的服務端負載和資源競爭，進而節制客戶端，最糟糕的情況就是退化到傳統的輪詢方式。

6.1.1 長輪詢請求消息 long-polling request messages

Messages are sent to the server as the body of a POST, encoded either as "application/x-www-form-urlencoded" or as "text/json". If sent as form encoded, the Bayeux messages are sent as the "message" parameter in one of the following forms as:

消息做為POST請求體發往服務端，可以被編碼為 "application/x-www-form-urlencoded" 或 "text/json"。如果做為表單編碼發送，Bayeux消息做為下列形式之一的"message"參數發送：

• Single valued and contain a single Bayeux message
• 單個值并包含單個Bayeux消息
  
• Single valued and contain an array of Bayeux message
• 單個值并包含一個Bayeux消息數組
• Multi valued and contain a several individual Bayeux message
• 多值并包含多個獨立的Bayeux消息
  
• Multi valued and contain a several arrays of Bayeux message
• 多值并包含多個Bayeux消息數組
  
• Multi valued and contain a mix of individual Bayeux messages and arrays of Bayeux message
• 多值并混合包含了獨立的Bayeux消息和Bayeux消息數組
  

6.1.2 長輪詢響應消息 long-polling response messages

Messages are sent to the client as unencapsulated body content of a POST response with content type "text/json" or "text/json-comment-filtered".

消息做為未封裝的POST響應體發往客戶端，POST響應的內容類型為"text/json" 或 "text/json-comment-filtered"。

6.2. 回調輪詢 callback-polling

6.2.1 回調輪詢請求消息 callback-polling request messages

Messages are sent to the server either using POST requests as per long-polling transport or as the 'message' URL parameter of a GET request.

發送到服務端的消息，既可以使用每個長輪詢傳輸的POST請求，也可以做為GET請求的message參數。

6.2.2 回調輪詢響應消息 callback-polling response messages

Messages are sent to the client as JavaScript function call returned for script source GET requests. The function called will be determined by the 'jsonp' field of any associated request messages, or 'jsonpcallback' if not specified. The called function will be passed a JSON array of Bayeux messages.

發送到客戶端的消息，當作JavaScript函數調用為腳本源GET請求而返回。被調用的函數由相關請求消息的jsonp字段決定，如果不指定（jsonp參數）函數就是jsonpcallback。調用的函數被傳入一個Bayeux消息的JSON數組。

7. 安全 Security

7.1. 認證 Authentication

Bayeux may be used with:
Bayeux可以使用

• No authentication
• 無認證
  
• Container supplied authentication (eg BASIC auth or cookie managed session based authentication)
• 容器提供的認證（如BASIC認證或基于session的cookie管理的認證）
  
• Bayeux extension authentication that exchanges authentication credentials and tokens within Bayeux messages ext fields
• 在Bayeux消息擴展字段中交換認證證書和令牌的Bayeux擴展認證

For Bayeux authentication, no algorithm is specified for generating or validating security credentials or token. This version of the protocol only defines that the ext field may be used to exchange authentication challenges, credentials, and tokens and that the advice field may be used to control multiple iterations of the exchange.

Bayeux認證并沒有指定算法，來產生或驗證安全證書或令牌。協議的這個版本只定義了擴展字段可被用來交換認證口令，證書，和令牌，而advice字段可以用來控制交換的多次迭代。

The connection negotiation mechanism may be used to negotiate authentication or request re-authentication.

連接協商機制可以被用來協商認證或請求重新認證。

7.2. Ajax劫持 Ajax Hijacking

The Ajax hijacking vulnerability is when an attacking web site uses a script tag to execute JSON content obtained from an Ajax server. The Bayeux protocol is not vulnerable to this style of attack as cookies are not used for authentication and a valid client ID is needed before private client data is returned. The use of POST by some transports further protects against this style of attack.

Ajax劫持漏洞是當攻擊網站使用script標記來是執行從Ajax服務端獲取的JSON內容。Bayeue協議不易受這種攻擊，因為不使用cookie來認證，并且在私有客戶端數據返回前需要一個有效的客戶端ID。某些使用POST的傳輸方式更進一步避免這種類型的攻擊。

8. 多框架運作 Multi frame operation

Current HTTP client implementations are RECOMMENDED to allow only two connections between a client and a server. This presents a problem when multiple instances of the Bayeux client are operating in multiple tabs or windows of the same browser instance. The two connection limit can be consumed by outstanding connect meta messages from each tab or window and thus prevent other messages from being delivered in a timely fashion.

當前的HTTP客戶端實現只允許在一個客戶端和一個服務端之間兩個連接。這在多Bayeux客戶端實例在同一個瀏覽器實例的多個標簽或窗口中操作時，表現出一個問題。兩個連接的限制被來自每個標簽或窗口的未決的連接元消息所耗盡，從而防止其他消息被及時傳遞。

8.1 服務端多框架偵測 Server Multi frame detection

It is RECOMMENDED that Bayeux server implementations use the cookie "Bayeux_HTTP_ID" to identify a HTTP client and to thus detect multiple Bayeux clients running within the same HTTP client. Once detected, the server SHOULD not wait for messages in connect and SHOULD use the advice interval mechanism to establish traditional polling.

推薦Bayeux服務端實現用cookie"Bayeux_HTTP_ID"來標識一個HTTP客戶端，以此來偵測同一個HTTP客戶端內的多個Bayeux客戶端。一旦偵測到，服務端不應該等待連接的消息，應該使用建議間隔機制來建立傳統的輪詢。

8.2 客戶端多框架處理 Client Multi frame handling

It is RECOMMENDED that Bayeux client implementations use client side persistence or cookies to detect multiple intances of Bayeux clients running within the same HTTP client. Once detected, the user MAY be offered the option to disconnect all but one of the clients. It MAY be possible for client implementations to use client side persistence to share a Bayeux client instance.

推薦Bayeux客戶端實現使用客戶側的存儲或cookie來偵測同一個HTTP客戶端內的多Bayeux客戶端實例。一旦發現，用戶可以選擇斷開所有客戶端而只保留一個。客戶端實現也可能用客戶端側的持久化來共享一個Bayeux客戶端實例。

9. service通道的請求/響應操作

Request / Response operation with service channels

The publish/subscribe paradigm that is directly supported by the Bayeux protocol is difficult to use to efficiently implement the request/response paradigm between a client and a server. The /service/** channel space has been designated as a special channel space to allow efficient transport of application request and responses over Bayeux channels. Messages published to service channels are not distributed to other Bayeux clients so these channels can be used for private requests between a Bayeux client and a server side handlers.

A trivial example would be an echo service, that sent any message received from a client back to that client unaltered. Bayeux clients would subscribe the the /service/echo channel, but the Bayeux server would not need to record this subscription. When a client publishes a message to the /service/echo channel, it will be delivered only to server-side subscribers (in an implementation depedent fashion). The server side handler for the echo service would handle each message received by publishing a response directly to the client regardless of any subscription. As the client has subscribed to /service/echo, the response message will be routed correctly within the client to the appropriate application handler.

發布訂閱模式被Bayeux協議直接支持，但在客戶端和服務端之間有效的實現請求響應模式就比較困難。/service/**通道空間被指定為一個特殊的通道空間，以允許基于Bayeux通道的應用請求響應的有效傳輸。發布到service通道的消息不被分發到其他Bayeux客戶端，因此，這些通道可用作Bayeux客戶端和服務端處理間的私有請求。
舉一個回顯服務例子，發送的任何消息原封不動的返回到那個客戶端。Bayeux客戶端可以訂閱/service/echo通道，但是Bayeux服務端不必記錄這個訂閱。當客戶端發布一個到/service/echo通道的消息時，僅僅會被投送到服務端的訂閱者（使用實現相關的方式）。echo服務的服務端處理會直接發布接收消息的響應到客戶端，而不關心任何訂閱。因為客戶端已經訂閱到/service/echo，響應消息會被無誤的路由，在客戶端中應用適當的處理。