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，响应消息会被无误的路由，在客户端中应用适当的处理。