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. 目的

1.2. 需求

1.3. 術語

1.4. 整體運做

1.4.1. HTTP

1.4.2. 非 HTTP 傳輸

1.4.3. Javascript

1.4.4. 客戶端至服務端事件分發

1.4.5. 服務端至客戶端事件分發

1.4.5.i 輪詢傳輸

1.4.5.ii 流傳輸

1.4.6. 雙鏈接運做

1.4.7. 鏈接協商

1.4.8. 不鏈接運做

1.5 狀態表

1.5.1 客戶端狀態

2. 協議涵義

2.1. 基本組件

2.2.通道

2.2.1 通道通配符

2.2.2 Meta通道

2.2.3 Service通道

2.3. 版本

2.4. 客戶端ID

2.5 消息

3. 消息字段定義

3.1. channel

3.2. version

3.3. minimumVersion

3.4. supportedConnectionTypes

3.5. clientId

3.6. advice

3.6.1. reconnect advice

3.6.2. interval advice

3.6.3. multiple-clients advice

3.6.4. hosts advice

3.7. connectionType

3.8. id

3.9. timestamp

3.10. data

3.11. connectionId

3.12. successful

3.13. subscription

3.14. error

3.15. ext

3.16. json-comment-filtered

4. Meta 消息定義

4.1. 握手

4.1.1. 握手請求

4.1.2. 握手響應

4.2. 鏈接

4.2.1. 鏈接請求

4.2.2. 鏈接響應

4.4. 斷開

4.4.1. 斷開請求

4.4.2. 斷開響應

4.5. 訂閱

4.5.1. 訂閱請求

4.5.2. 訂閱響應

4.6. 取消訂閱

4.6.1. 取消訂閱請求

4.6.2. 取消訂閱響應

5. 事件消息定義

5.1. 發佈事件消息

5.1.1. 發佈請求

5.1.2. 發佈響應

5.2. 分發事件消息

6. 傳輸

6.1. long-polling

6.1.1 long-polling 請求消息

6.1.2 long-polling 響應消息

6.2. callback-polling

6.2.1 callback-polling 請求消息

6.2.2 callback-polling 響應消息

7. 安全

7.1.鑑權

7.2. Ajax 劫持

8. 多frame 運做

8.1 服務端多frame偵測

8.2 客戶端多frame偵測

9. service 通道的請求響應運做

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對象，目的就是爲了實現三、四、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，響應消息會被無誤的路由，在客戶端中應用適當的處理。