您正在查看的是 Apigee Edge 文档。
转到 Apigee X 文档。 信息
2014 年 1 月 29 日（星期三），我们发布了新的本地版本的 Apigee Edge。
如果您有任何疑问，请转到 Apigee 客户支持。
此版本包含以下 Cloud 版本中的功能和 bug 修复：
新功能和增强功能
- OAuth 2.0 更新令牌的自定义属性
通过新的“设置 OAuth v2.0 信息”政策，您可以更新 OAuth 2.0 令牌的自定义属性。
http://apigee.com/docs/api-services/content/set-oauth-tokens-attributes-using-setoauthv2info
-
OAuth 1.0a 政策更新
此版本包含对 OAuth 1.0a 政策的以下更新：- 与 OAuth 2.0 令牌一样，您现在可以为 OAuth 1.0a 令牌设置自定义属性。
- 新的 GenerateVerifier 操作可让您生成并返回 OAuth 1.0a 验证程序（类似于 OAuth 2.0 中的授权代码）。
- 流变量中的 SSL 信息
Apigee Edge 现在允许您在流变量中传播和访问 SSL 信息。通过在 ProxyEndpoint 上设置新的“propagate.additional.ssl.headers”属性，您可以访问与 Apache 网络服务器上相同的 SSL 信息。
http://apigee.com/docs/api-services/api/variables-reference
- 将 JMS 标头用作 HTTP 标头
现在，所有 JMS 标头都会作为 HTTP 标头传播，以便进行下游处理。
- Node.js 模块更新
Apigee 的内置 Node.js 模块已更新，包含以下模块：argo 0.4.9、async 0.2.9、express 3.4.8、underscore 1.5.2、usergrid 0.10.7、volos-cache-memory 0.0.quota-oauth.oauth-apigee.apigee.0-apigee.0-apigee.0
-
管理界面中的自定义角色 - Beta 版
除了现有的用户角色“商家用户”“运维管理员”“组织管理员”和“用户”之外，此版本还包含一项 Beta 版功能，可让您在管理界面中创建自定义角色。您可以使用自定义角色来控制对各种 Edge 功能的访问权限。 - 高级 API 服务（以前称为“应用服务”）安装程序
Apigee Edge Advanced API Services（以前称为“应用服务”）现已可在本地使用。利用现有的 Edge 安装程序，您可以在自己的本地环境中部署和配置高级 API 服务。
- 开发者服务变现（以前称为变现服务）安装程序
变现功能是边缘开发者服务的一部分。Edge 本地安装程序现在包含增强的集成式变现安装程序。创收功能需要额外的付费许可。
- 单个主机上包含多个消息处理器 - 静默安装
此增强功能支持安装在单个主机上的多个消息处理器的部署拓扑，这需要将每个消息处理器绑定到特定 IP 地址。您现在可以在静默安装配置文件中添加BIND_ON_ALL_INTERFACES=n属性设置，此设置会使消息处理器监听同一文件中HOSTIP属性指定的特定 IP 地址。如需详细了解此属性以及如何配置静默安装，请参阅 Apigee 本地部署套件安装与配置指南。
-
JMS 更新
此版本包含对 Apigee 的 JMS 支持的各种更新，包括：- 所有 JMS 标头现在都会作为 HTTP 标头进行传播，以便进行下游处理。
- 您现在可以为 JMS 代理使用的 ResponseQueue 中放置的消息指定 ExpiryTime 和 DeliveryMode。与标准 JMS 标头匹配的所有 HTTP 标头都“按原样”设置，其他 HTTP 标头在 JMS 代理使用的响应消息中设置为 JMS 属性。
已修复 Bug
| 主题 | 说明 |
|---|---|
| 自定义角色权限 | 使用自定义角色设置的权限现在可按预期运行。 |
| API 延迟时间分析 | 在 API 代理流程中，如果调用目标系统导致超时（例如 HTTP 读取超时），API 分析中包含的目标延迟时间。 |
| 政策的“type”属性 | 现在，“type”属性在所有 Apigee 政策中都能正常运行。 |
| OAuth 2.0 使令牌失效 | Apigee OAuth 2.0 政策的令牌失效功能现在符合 OAuth 规范。设置“token”参数时，您不再需要提供“类型”。 |
| 使用键值对映射的 RBAC | 基于角色的访问权限控制现在适用于在环境级别创建的键值对映射。 |
| OAuth 1.0a 政策响应格式 | 现在，使用 OAuth 1.0a 政策向 API 发出请求时，系统会以 Accept 标头的格式返回响应。 |
已知问题
| 主题 | 说明 |
|---|---|
| HTTP 1.0 请求、 HTTP 1.1 响应 |
此问题涉及到这样一种情景：客户端使用 HTTP 1.0 发送请求，标头中包含
content-length 属性，但后端服务配置为使用 HTTP 1.1 并针对分块编码返回 transfer-encoding 属性。
为了成功处理这种情况，您可以使用 assignMessage 政策从 HTTP 1.1 响应中移除
transfer-encoding 属性。在以下政策（将附加到 API 代理响应流）中，transfer-encoding 属性从 HTTP 标头中移除，以允许客户端接收未分块的响应。
<assignMessage name="RemoveChunkedEncoding">
<assignTo createNew="false" type="response"></AssignmentTo>
<移除>
<标头>
<Header name="Transfer-Encoding"/>
<Header name="transfer-encoding"/>
</Headers>
</Remove>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</SpecifyMessage>
|