Internet Engineering Task Force (IETF) B. Niven-Jenkins, Ed.
Request for Comments: 7975 Nokia
Category: Standards Track R. van Brandenburg, Ed.
ISSN: 2070-1721 TNO
October 2016
Internet Engineering Task Force (IETF) B. Niven-Jenkins, Ed.
Request for Comments: 7975 Nokia
Category: Standards Track R. van Brandenburg, Ed.
ISSN: 2070-1721 TNO
October 2016
Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection
内容交付网络（CDN）互连的请求路由重定向接口
Abstract
摘要
The Request Routing interface comprises (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface.
请求路由接口包括（1）下游内容交付网络（CDN）对封装外形和能力的异步广告，该下游内容交付网络（CDN）允许上游CDN决定是否将特定用户请求重定向到该下游CDN；和（2）上游CDN请求下游CDN是否准备接受用户请求和下游CDN响应如何实际重定向用户请求的同步操作。本文档描述了后一部分的接口，即CDNI请求路由重定向接口。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7975.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7975.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Interface Function and Operation Overview . . . . . . . . . . 4
4. HTTP-Based Interface for the Redirection Interface . . . . . 6
4.1. Information Passed in RI Requests and Responses . . . . . 8
4.2. JSON Encoding of RI Requests and Responses . . . . . . . 9
4.3. MIME Media Types Used by the RI Interface . . . . . . . . 11
4.4. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. DNS Redirection Requests . . . . . . . . . . . . . . 12
4.4.2. DNS Redirection Responses . . . . . . . . . . . . . . 14
4.5. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 17
4.5.1. HTTP Redirection Requests . . . . . . . . . . . . . . 17
4.5.2. HTTP Redirection Responses . . . . . . . . . . . . . 19
4.6. Cacheability and Scope of Responses . . . . . . . . . . . 22
4.7. Error Responses . . . . . . . . . . . . . . . . . . . . . 24
4.8. Loop Detection and Prevention . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
5.1. Authentication, Authorization, Confidentiality, and
Integrity Protection . . . . . . . . . . . . . . . . . . 29
5.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6.1. CDNI Payload Type Parameter Registrations . . . . . . . . 31
6.1.1. CDNI RI Redirection Request Payload Type . . . . . . 31
6.1.2. CDNI RI Redirection Response Payload Type . . . . . . 31
6.2. RI Error Response Registry . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Normative References . . . . . . . . . . . . . . . . . . 32
7.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Interface Function and Operation Overview . . . . . . . . . . 4
4. HTTP-Based Interface for the Redirection Interface . . . . . 6
4.1. Information Passed in RI Requests and Responses . . . . . 8
4.2. JSON Encoding of RI Requests and Responses . . . . . . . 9
4.3. MIME Media Types Used by the RI Interface . . . . . . . . 11
4.4. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. DNS Redirection Requests . . . . . . . . . . . . . . 12
4.4.2. DNS Redirection Responses . . . . . . . . . . . . . . 14
4.5. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 17
4.5.1. HTTP Redirection Requests . . . . . . . . . . . . . . 17
4.5.2. HTTP Redirection Responses . . . . . . . . . . . . . 19
4.6. Cacheability and Scope of Responses . . . . . . . . . . . 22
4.7. Error Responses . . . . . . . . . . . . . . . . . . . . . 24
4.8. Loop Detection and Prevention . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
5.1. Authentication, Authorization, Confidentiality, and
Integrity Protection . . . . . . . . . . . . . . . . . . 29
5.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6.1. CDNI Payload Type Parameter Registrations . . . . . . . . 31
6.1.1. CDNI RI Redirection Request Payload Type . . . . . . 31
6.1.2. CDNI RI Redirection Response Payload Type . . . . . . 31
6.2. RI Error Response Registry . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Normative References . . . . . . . . . . . . . . . . . . 32
7.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
A Content Delivery Network (CDN) is a system built on an existing IP network that is used for large-scale content delivery, via prefetching or dynamically caching content on its distributed surrogates (caching servers). [RFC6707] describes the problem area of interconnecting CDNs.
内容交付网络（CDN）是建立在现有IP网络上的系统，通过预取或在其分布式代理（缓存服务器）上动态缓存内容，用于大规模内容交付。[RFC6707]描述了互连CDN的问题区域。
The CDNI Request Routing interface outlined in [RFC7336] is comprised of:
[RFC7336]中概述的CDNI请求路由接口包括：
1. The asynchronous advertisement of footprint and capabilities by a downstream CDN (dCDN) that allows an upstream CDN (uCDN) to decide whether to redirect particular user requests to that dCDN.
1. 下游CDN（dCDN）对封装外形和功能的异步公布，允许上游CDN（uCDN）决定是否将特定用户请求重定向到该dCDN。
2. The synchronous operation of a uCDN requesting whether a dCDN is prepared to accept a user request and of a dCDN responding with how to actually redirect the user request.
2. uCDN请求dCDN是否准备接受用户请求的同步操作，以及dCDN响应如何实际重定向用户请求的同步操作。
This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface (RI).
本文档描述了后一部分的接口，即CDNI请求路由重定向接口（RI）。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document reuses the terminology defined in [RFC6707].
本文件重复使用了[RFC6707]中定义的术语。
The following additional terms are introduced by this document:
本文件引入了以下附加条款：
Application-Level Redirection: The act of using an application-specific redirection mechanism for the request routing process of a CDN. The Redirection Target (RT) is the result of a CDN's routing decision at the time it receives a content request via an application-specific protocol response. Examples of an application-level redirection are HTTP 302 Redirection and Real Time Messaging Protocol (RTMP) [RTMP] 302 Redirection.
应用程序级重定向：对CDN的请求路由过程使用特定于应用程序的重定向机制的行为。重定向目标（RT）是CDN通过特定于应用程序的协议响应接收内容请求时的路由决定的结果。应用程序级重定向的示例包括HTTP 302重定向和实时消息传递协议（RTMP）[RTMP]302重定向。
DNS Redirection: The act of using DNS name resolution for the request routing process of a CDN. In DNS Redirection, the DNS name server of the CDN makes the routing decision based on a local policy and selects one or more Redirection Targets (RTs) and redirects the User Agent (UA) to the RT(s) by returning the details of the RT(s) in response to the DNS query request from the User Agent's DNS resolver.
DNS重定向：对CDN的请求路由过程使用DNS名称解析的行为。在DNS重定向中，CDN的DNS名称服务器基于本地策略做出路由决策，并选择一个或多个重定向目标（RT），并通过响应来自用户代理的DNS解析程序的DNS查询请求而返回RT的细节来将用户代理（UA）重定向到RT。
HTTP Redirection: The act of using an HTTP redirection response for the request routing process of a CDN. The Redirection Target (RT) is the result of the routing decision of a CDN at the time it receives a content request via HTTP. HTTP Redirection is a particular case of application-level redirection.
HTTP重定向：对CDN的请求路由过程使用HTTP重定向响应的行为。重定向目标（RT）是CDN通过HTTP接收内容请求时的路由决定的结果。HTTP重定向是应用程序级重定向的一种特殊情况。
Redirection Target (RT): The endpoint to which the User Agent is redirected. In CDNI, an RT may point to a number of different components, some examples include a surrogate in the same CDN as the request router, a request router in a dCDN, or a surrogate in a dCDN.
重定向目标（RT）：将用户代理重定向到的端点。在CDNI中，RT可以指向许多不同的组件，一些示例包括与请求路由器位于同一CDN中的代理、dCDN中的请求路由器或dCDN中的代理。
The main function of the CDNI Redirection interface (RI) is to allow the request routing systems in interconnected CDNs to communicate to facilitate the redirection of User Agent requests between interconnected CDNs.
CDNI重定向接口（RI）的主要功能是允许互连CDN中的请求路由系统进行通信，以便于在互连CDN之间重定向用户代理请求。
The detailed requirements for the Redirection interface and their relative priorities are described in Section 5 of [RFC7337].
[RFC7337]第5节描述了重定向接口的详细要求及其相对优先级。
The User Agent will make a request to a request router in the uCDN using one of either DNS or HTTP. The RI is used between the uCDN and one or more dCDNs. The dCDN's RI response may contain a Redirection Target with a type that is compatible with the protocol used between the User Agent and uCDN request router. The dCDN has control over the Redirection Target it provides. Depending on the returned Redirection Target, the User Agent's request may be redirected to:
用户代理将使用DNS或HTTP之一向uCDN中的请求路由器发出请求。RI用于uCDN和一个或多个DCDN之间。dCDN的RI响应可能包含重定向目标，其类型与用户代理和uCDN请求路由器之间使用的协议兼容。dCDN可以控制它提供的重定向目标。根据返回的重定向目标，用户代理的请求可以重定向到：
o The final surrogate, which may be in the dCDN that returned the RI response to the uCDN or another CDN (if the dCDN delegates the delivery to another CDN); or
o 最终代理，可能在将RI响应返回给uCDN或另一个CDN的dCDN中（如果dCDN将传递委托给另一个CDN）；或
o A request router (in the dCDN or another CDN), which may use a different redirection protocol (DNS or HTTP) than the one included in the RI request.
o 一种请求路由器（在dCDN或另一CDN中），它可以使用与RI请求中包含的重定向协议不同的重定向协议（DNS或HTTP）。
The Redirection interface operates between the request routing systems of a pair of interconnected CDNs. To enable communication over the Redirection interface, the uCDN needs to know the URI (endpoint) in the dCDN to send CDNI request routing queries.
重定向接口在一对互连CDN的请求路由系统之间运行。要启用重定向接口上的通信，uCDN需要知道dCDN中的URI（端点）以发送CDNI请求路由查询。
The Redirection interface URI may be statically preconfigured, dynamically discovered via the CDNI Control interface, or discovered via other means. However, such discovery mechanisms are not specified in this document, as they are considered out of the scope of the Redirection interface specification.
重定向接口URI可以是静态预配置的、通过CDNI控制接口动态发现的或通过其他方式发现的。但是，本文档中未指定此类发现机制，因为它们被认为超出了重定向接口规范的范围。
The Redirection interface is only relevant in the case of Recursive Request Redirection, as Iterative Request Redirection does not invoke any interaction over the Redirection interface between interconnected CDNs. Therefore, the scope of this document is limited to Recursive Request Redirection.
重定向接口仅在递归请求重定向的情况下相关，因为迭代请求重定向不会通过互连CDN之间的重定向接口调用任何交互。因此，本文档的范围仅限于递归请求重定向。
In the case of Recursive Request Redirection, in order to perform redirection of a request received from a User Agent, the uCDN queries the dCDN so that the dCDN can select and provide a Redirection Target. In cases where a uCDN has a choice of dCDNs, it is up to the uCDN to decide (for example, via configured policies) which dCDN(s) to query and in which order to query them. A number of strategies are possible, including selecting a preferred dCDN based on local policy, possibly falling back to querying an alternative dCDN(s) if the first dCDN does not return a Redirection Target or otherwise rejects the uCDN's RI request. A more complex strategy could be to query multiple dCDNs in parallel before selecting one and using the Redirection Target provided by that dCDN.
在递归请求重定向的情况下，为了执行从用户代理接收的请求的重定向，uCDN查询dCDN，以便dCDN可以选择并提供重定向目标。如果uCDN可以选择dCDN，则由uCDN决定（例如，通过配置的策略）查询哪个dCDN以及查询它们的顺序。有许多策略是可能的，包括基于本地策略选择首选dCDN，如果第一个dCDN不返回重定向目标或以其他方式拒绝uCDN的RI请求，则可能返回到查询替代dCDN。更复杂的策略可能是在选择一个dCDN并使用该dCDN提供的重定向目标之前并行查询多个dCDN。
The uCDN->User Agent redirection protocols addressed in this document are: DNS redirection and HTTP redirection. Other types of application-level redirection will not be discussed further in this document. However, the Redirection interface is designed to be extensible and could be extended to support additional application-level redirection protocols.
本文档中介绍的uCDN->用户代理重定向协议有：DNS重定向和HTTP重定向。本文档将不再进一步讨论其他类型的应用程序级重定向。但是，重定向接口的设计是可扩展的，可以扩展以支持附加的应用程序级重定向协议。
For both DNS and HTTP redirection, either HTTP or HTTPS could be used to connect to the Redirection Target. When HTTPS is used to connect to the uCDN, if the uCDN uses DNS redirection to identify the RT to the User Agent, then the new target domain name may not match the domain in the URL dereferenced to reach the uCDN; without operational precautions, and in the absence of DNSSEC, this can make a legitimate redirection look like a DNS-based attack to a User Agent and trigger security warnings. When DNS-based redirection with HTTPS is used, this specification assumes that any RT can complete the necessary Transport Layer Security (TLS) handshake with the User Agent. Any operational mechanisms this requires, e.g., private key distribution to surrogates and request routers in dCDNs, are outside the scope of this document.
对于DNS和HTTP重定向，可以使用HTTP或HTTPS连接到重定向目标。当使用HTTPS连接到uCDN时，如果uCDN使用DNS重定向将RT标识到用户代理，则新的目标域名可能与URL中的域不匹配，该URL被取消引用以到达uCDN；如果没有操作预防措施，并且在没有DNSSEC的情况下，这会使合法重定向看起来像是对用户代理的基于DNS的攻击，并触发安全警告。使用基于DNS的HTTPS重定向时，本规范假设任何RT都可以完成与用户代理的必要传输层安全（TLS）握手。这需要的任何操作机制，例如，在dCDNs中向代理和请求路由器分发私钥，都不在本文档的范围内。
This document also defines an RI loop prevention and detection mechanism as part of the Redirection interface.
本文档还定义了RI循环预防和检测机制，作为重定向接口的一部分。
This document defines a simple interface for the Redirection interface based on HTTP [RFC7230], where the attributes of a User Agent's requests are encapsulated along with any other data that can aid the dCDN in processing the requests. The RI response encapsulates the attributes of the RT(s) that the uCDN should return to the User Agent (if it decides to utilize the dCDN for delivery) along with the policy for how the response can be reused. The examples of RI requests and responses below do not contain a complete set of HTTP headers for brevity; only the pertinent HTTP headers are shown.
本文档为基于HTTP[RFC7230]的重定向接口定义了一个简单接口，其中用户代理请求的属性与可帮助dCDN处理请求的任何其他数据一起封装。RI响应封装了RT的属性，uCDN应该将这些属性返回给用户代理（如果它决定使用dCDN进行传递），以及如何重用响应的策略。为了简洁起见，下面的RI请求和响应示例不包含完整的HTTP头集；只显示相关的HTTP头。
The RI between the uCDN and dCDN uses the same HTTP interface to encapsulate the attributes of both DNS and HTTP requests received from User Agents, although the contents of the RI requests/responses contain data specific to either DNS or HTTP redirection.
uCDN和dCDN之间的RI使用相同的HTTP接口来封装从用户代理接收的DNS和HTTP请求的属性，尽管RI请求/响应的内容包含特定于DNS或HTTP重定向的数据。
This approach has been chosen because it enables CDN operators to only have to deploy a single interface for the RI between their CDNs, regardless of the User Agent redirection method. In this way, from an operational point of view, there is only one interface to monitor, manage, develop troubleshooting tools for, etc.
之所以选择这种方法，是因为它使CDN运营商只需为其CDN之间的RI部署一个接口，而不必考虑用户代理重定向方法。这样，从操作角度来看，只有一个界面可用于监视、管理、开发故障排除工具等。
In addition, having a single RI where the attributes of the User Agent's DNS or HTTP request are encapsulated along with the other data required for the dCDN to make a request routing decision, avoids having to both 1) try to encapsulate or proxy DNS/HTTP/RTMP/ etc. requests and 2) find ways to somehow embed the additional CDNI Request Routing Redirection interface properties/data within those end-user DNS/HTTP/RTMP/etc. requests.
此外，具有单个RI，其中用户代理的DNS或HTTP请求的属性与dCDN做出请求路由决策所需的其他数据一起被封装，避免1）尝试封装或代理DNS/HTTP/RTMP/etc.请求，2）设法在这些最终用户DNS/HTTP/RTMP/etc.请求中嵌入额外的CDNI请求路由重定向接口属性/数据。
Finally, the RI is easily extendable to support other User Agent request redirection methods (e.g., RTMP 302 redirection) by defining additional protocol-specific keys for RI requests and responses along with a specification about how to process them.
最后，通过为RI请求和响应定义附加的协议特定密钥以及关于如何处理它们的规范，RI易于扩展以支持其他用户代理请求重定向方法（例如，RTMP 302重定向）。
The generic Recursive Request Redirection message flow between Request Routing systems in a pair of interconnected CDNs is as follows:
一对互连CDN中请求路由系统之间的通用递归请求重定向消息流如下所示：
User Agent CDN B RR CDN A RR
|UA Request (DNS or HTTP) | |
|-------------------------------------------------->| (1)
| | |
| |HTTP POST to CDN B's RI |
| |URI encapsulating UA |
| |request attributes |
| |<------------------------| (2)
| | |
| |HTTP Response with body |
| |containing RT attributes |
| |of the protocol-specific |
| |response to return to UA |
| |------------------------>| (3)
| | |
| Protocol-specific response (redirection)|
|<--------------------------------------------------| (4)
| | |
User Agent CDN B RR CDN A RR
|UA Request (DNS or HTTP) | |
|-------------------------------------------------->| (1)
| | |
| |HTTP POST to CDN B's RI |
| |URI encapsulating UA |
| |request attributes |
| |<------------------------| (2)
| | |
| |HTTP Response with body |
| |containing RT attributes |
| |of the protocol-specific |
| |response to return to UA |
| |------------------------>| (3)
| | |
| Protocol-specific response (redirection)|
|<--------------------------------------------------| (4)
| | |
Figure 1: Generic Recursive Request Redirection Message Flow
图1：通用递归请求重定向消息流
1. The User Agent sends its (DNS or HTTP) request to CDN A. The Request Routing System of CDN A processes the request and, through local policy, recognizes that the request is best served by another CDN, specifically CDN B (or that CDN B may be one of a number of candidate dCDNs it could use).
1. 用户代理将其（DNS或HTTP）请求发送到CDN A。CDN A的请求路由系统处理该请求，并通过本地策略识别该请求最好由另一个CDN，特别是CDN B（或者CDN B可能是它可以使用的多个候选DCDN之一）服务。
2. The Request Routing System of CDN A sends an HTTP POST to CDN B's RI URI containing the attributes of the User Agent's request.
2. CDN A的请求路由系统向CDN B的RI URI发送HTTP POST，其中包含用户代理请求的属性。
3. The Request Routing System of CDN B processes the RI request and, assuming the request is well-formed, responds with an HTTP "200" response with a message body containing the RT(s) to return to the User Agent as well as parameters that indicate the properties of the response (cacheability and scope).
3. CDN B的请求路由系统处理RI请求，并且假设该请求格式正确，则使用HTTP“200”响应进行响应，该响应具有包含返回到用户代理的RT的消息体以及指示响应属性（可缓存性和范围）的参数。
4. The Request Routing System of CDN A sends a protocol-specific response (containing the returned attributes) to the User Agent, so that the User Agent's request will be redirected to the RT(s) returned by CDN B.
4. CDN A的请求路由系统向用户代理发送特定于协议的响应（包含返回的属性），以便用户代理的请求将重定向到CDN B返回的RT。
The information passed in RI requests splits into two basic categories:
RI请求中传递的信息分为两个基本类别：
1. The attributes of the User Agent's request to the uCDN.
1. 用户代理对uCDN的请求的属性。
2. Properties/parameters that the uCDN can use to control the dCDN's response or that can help the dCDN make its decision.
2. uCDN可用于控制dCDN响应或帮助dCDN做出决策的属性/参数。
Generally, dCDNs can provide better routing decisions given additional information about the content request, e.g., the URI of the requested content or the User Agent's IP address or subnet. The information required to base a routing decision on can be highly dependent on the type of content delivered. A uCDN SHOULD only include information that is absolutely necessary for delivering that type of content. Cookies in particular are especially sensitive from a security/privacy point of view and in general SHOULD NOT be conveyed in the RI Requests to the dCDN. The information necessary to be conveyed for a particular type of request is expected to be conveyed out of band between the uCDN and dCDN. See Section 5.2 for more detail on the privacy aspects of using RI Requests to convey information about UA requests.
通常，如果提供有关内容请求的附加信息，例如，所请求内容的URI或用户代理的IP地址或子网，dCDNs可以提供更好的路由决策。路由决策所需的信息在很大程度上取决于交付的内容类型。uCDN应仅包含交付该类型内容绝对必要的信息。从安全/隐私角度来看，Cookie尤其敏感，通常不应在RI请求中传达给dCDN。对于特定类型的请求，需要传输的信息预计将在uCDN和dCDN之间的带外传输。有关使用RI请求传达UA请求信息的隐私方面的更多详细信息，请参见第5.2节。
In order for the dCDN to determine whether it is capable of delivering any requested content, it requires CDNI metadata related to the content the User Agent is requesting. That metadata will describe the content and any policies associated with it. It is expected that the RI request contains sufficient information for the Request Router in the dCDN to be able to retrieve the required CDNI Metadata via the CDNI Metadata interface.
为了让dCDN确定它是否能够交付任何请求的内容，它需要与用户代理请求的内容相关的CDNI元数据。该元数据将描述内容以及与之相关的任何策略。预计RI请求包含足够的信息，以便dCDN中的请求路由器能够通过CDNI元数据接口检索所需的CDNI元数据。
The information passed in RI responses splits into two basic categories:
RI响应中传递的信息分为两个基本类别：
1. The attributes of the RT to return to the User Agent in the DNS response or HTTP response.
1. 要在DNS响应或HTTP响应中返回给用户代理的RT的属性。
2. Parameters/policies that indicate the properties of the response, such as, whether it is cacheable, the scope of the response, etc.
2. 指示响应属性的参数/策略，如响应是否可缓存、响应范围等。
In addition to details about how to redirect the User Agent, the dCDN may wish to return additional policy information to the uCDN. For example, the dCDN may wish to return a policy that expresses "this response can be reused without requiring an RI request for 60 seconds provided the User Agent's IP address is in the range 198.51.100.0 -- 198.51.100.255".
除了有关如何重定向用户代理的详细信息外，dCDN还可能希望向uCDN返回其他策略信息。例如，dCDN可能希望返回一个策略，该策略表示“只要用户代理的IP地址在198.51.100.0--198.51.100.255范围内，该响应可以在不需要RI请求的情况下重复使用60秒”。
These additional policies split into two basic categories:
这些附加政策分为两个基本类别：
o Cacheability information signaled via the HTTP response headers of the RI response (to reduce the number of subsequent RI requests the uCDN needs to make).
o 通过RI响应的HTTP响应头发出信号的可缓存性信息（以减少uCDN需要发出的后续RI请求的数量）。
o The scope of a cacheable response signaled in the HTTP response body of the RI response, for example, whether the response applies to a wider range of IP addresses than what was included in the RI request.
o 在RI响应的HTTP响应体中发出信号的可缓存响应的范围，例如，响应是否应用于比RI请求中包含的IP地址范围更广的IP地址。
The cacheability of the response is indicated using the standard HTTP Cache-Control mechanisms.
使用标准HTTP缓存控制机制指示响应的可缓存性。
The body of RI requests and responses is a JSON object [RFC7159] that contains a dictionary of key:value pairs that MUST conform to [RFC7493]. Senders MUST encode all (top-level object and sub-object) keys specified in this document in lowercase. Receivers MUST ignore any keys that are unknown or invalid.
RI请求和响应的主体是一个JSON对象[RFC7159]，其中包含一个键：值对字典，该字典必须符合[RFC7493]。发件人必须以小写字母对本文档中指定的所有（顶级对象和子对象）键进行编码。接收者必须忽略任何未知或无效的密钥。
The following table defines the top-level keys and indicates whether they are applicable to RI requests, RI responses, or both:
下表定义了顶级键，并指出它们是否适用于RI请求、RI响应或两者：
+----------+------------------+-------------------------------------+
| Key | Request/Response | Description |
+----------+------------------+-------------------------------------+
| dns | Both | The attributes of the UA's DNS |
| | | request or the attributes of the |
| | | RT(s) to return in a DNS response. |
| | | |
| http | Both | The attributes of the UA's HTTP |
| | | request or the attributes of the RT |
| | | to return in an HTTP response. |
| | | |
| scope | Response | The scope of the response (if it is |
| | | cacheable). For example, whether |
| | | the response applies to a wider |
| | | range of IP addresses than what was |
| | | included in the RI request. |
| | | |
| error | Response | Additional details if the response |
| | | is an error response. |
| | | |
| cdn-path | Both | A List of Strings. Contains a list |
| | | of the CDN Provider IDs of previous |
| | | CDNs that have participated in the |
| | | request routing for the associated |
| | | User Agent request. On RI requests, |
| | | it contains the list of previous |
| | | CDNs that this RI request has |
| | | passed through. On RI responses, it |
| | | contains the list of CDNs that were |
| | | involved in obtaining the final |
| | | redirection included in the RI |
| | | response. See Section 4.8. |
| | | |
| max-hops | Request | Integer specifying the maximum |
| | | number of hops (CDN Provider IDs) |
| | | this request is allowed to be |
| | | propagated along. This allows the |
| | | uCDN to coarsely constrain the |
| | | latency of the request routing |
| | | chain. |
+----------+------------------+-------------------------------------+
+----------+------------------+-------------------------------------+
| Key | Request/Response | Description |
+----------+------------------+-------------------------------------+
| dns | Both | The attributes of the UA's DNS |
| | | request or the attributes of the |
| | | RT(s) to return in a DNS response. |
| | | |
| http | Both | The attributes of the UA's HTTP |
| | | request or the attributes of the RT |
| | | to return in an HTTP response. |
| | | |
| scope | Response | The scope of the response (if it is |
| | | cacheable). For example, whether |
| | | the response applies to a wider |
| | | range of IP addresses than what was |
| | | included in the RI request. |
| | | |
| error | Response | Additional details if the response |
| | | is an error response. |
| | | |
| cdn-path | Both | A List of Strings. Contains a list |
| | | of the CDN Provider IDs of previous |
| | | CDNs that have participated in the |
| | | request routing for the associated |
| | | User Agent request. On RI requests, |
| | | it contains the list of previous |
| | | CDNs that this RI request has |
| | | passed through. On RI responses, it |
| | | contains the list of CDNs that were |
| | | involved in obtaining the final |
| | | redirection included in the RI |
| | | response. See Section 4.8. |
| | | |
| max-hops | Request | Integer specifying the maximum |
| | | number of hops (CDN Provider IDs) |
| | | this request is allowed to be |
| | | propagated along. This allows the |
| | | uCDN to coarsely constrain the |
| | | latency of the request routing |
| | | chain. |
+----------+------------------+-------------------------------------+
Table 1: Top-Level Keys in RI Requests/Responses
表1:RI请求/响应中的顶级键
A single request or response MUST contain only one of the dns or http keys. Requests MUST contain a cdn-path key and responses MAY contain a cdn-path key. If the max-hops key is not present, then there is no limit on the number of CDN hops that the RI request can be propagated along. If the first uCDN does not wish the RI request to be propagated beyond the dCDN it is making the request to, then the uCDN MUST set max-hops to 1.
单个请求或响应只能包含一个dns或http密钥。请求必须包含cdn路径密钥，响应可能包含cdn路径密钥。如果max hops密钥不存在，则RI请求可以传播的CDN跳数没有限制。如果第一个uCDN不希望RI请求传播到它发出请求的dCDN之外，则uCDN必须将最大跳数设置为1。
The cdn-path MAY be reflected back in RI responses, although doing so could expose information to the uCDN that a dCDN may not wish to expose (for example, the existence of business relationships between a dCDN and other CDNs).
cdn路径可以在RI响应中反映回来，尽管这样做可能会将dCDN不希望公开的信息公开给uCDN（例如，dCDN和其他cdn之间存在业务关系）。
If the cdn-path is reflected back in the RI response, it MUST contain the value of cdn-path received in the associated RI request with the final dCDN's CDN Provider ID appended. Transit CDNs MAY remove the cdn-path from RI responses but MUST NOT modify the cdn-path in other ways.
如果cdn路径反映回RI响应中，则它必须包含在关联RI请求中接收的cdn路径值，并附加最终dCDN的cdn提供程序ID。传输cdn可以从RI响应中删除cdn路径，但不得以其他方式修改cdn路径。
The presence of an error key within a response that also contains either a dns or http key does not automatically indicate that the RI request was unsuccessful as the error key MAY be used for communicating additional (e.g., debugging) information. When a response contains an error key as well as either a dns or http key, the error-code SHOULD be 1xx (e.g., 100). See Section 4.7 for more details about encoding error information in RI responses.
在还包含dns或http密钥的响应中存在错误密钥并不自动表示RI请求未成功，因为错误密钥可用于传输附加（例如调试）信息。当响应包含错误密钥以及dns或http密钥时，错误代码应为1xx（例如，100）。有关RI响应中编码错误信息的更多详细信息，请参见第4.7节。
All implementations that support IPv4 addresses MUST support the encoding specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986]. Likewise, implementations that support IPv6 addresses MUST support all IPv6 address formats specified in [RFC4291]. Server implementations SHOULD use IPv6 address formats specified in [RFC5952].
所有支持IPv4地址的实现必须支持[RFC3986]第3.2.2节中“IPv4address”规则指定的编码。同样，支持IPv6地址的实现必须支持[RFC4291]中指定的所有IPv6地址格式。服务器实现应使用[RFC5952]中指定的IPv6地址格式。
RI requests MUST use a MIME media type of application/cdni as specified in [RFC7736], with the Payload Type (ptype) parameter set to 'redirection-request'.
RI请求必须使用[RFC7736]中指定的应用程序/cdni的MIME媒体类型，有效负载类型（ptype）参数设置为“重定向请求”。
RI responses MUST use a MIME media type of application/cdni as specified in [RFC7736], with the Payload Type (ptype) parameter set to 'redirection-response'.
RI响应必须使用[RFC7736]中指定的应用程序/cdni的MIME媒体类型，有效负载类型（ptype）参数设置为“重定向响应”。
The following sections provide detailed descriptions of the information that should be passed in RI requests and responses for DNS redirection.
以下各节提供了应在用于DNS重定向的RI请求和响应中传递的信息的详细描述。
For DNS-based redirection, the uCDN needs to pass the following information to the dCDN in the RI request:
对于基于DNS的重定向，uCDN需要在RI请求中将以下信息传递给dCDN：
o The IP address of the DNS resolver that made the DNS request to the uCDN.
o 向uCDN发出DNS请求的DNS解析程序的IP地址。
o The type of DNS query made (usually either A or AAAA).
o 所做DNS查询的类型（通常为A或AAAA）。
o The class of DNS query made (usually IN).
o 进行的DNS查询的类别（通常在中）。
o The fully qualified domain name for which DNS redirection is being requested.
o 请求DNS重定向的完全限定域名。
o The IP address or prefix of the User Agent (if known to the uCDN).
o 用户代理的IP地址或前缀（如果uCDN已知）。
The preceding information is encoded as a set of key:value pairs within the dns dictionary as follows:
上述信息在dns字典中编码为一组键：值对，如下所示：
+-------------+---------+-----------+-------------------------------+
| Key | Value | Mandatory | Description |
+-------------+---------+-----------+-------------------------------+
| resolver-ip | String | Yes | The IP address of the UA's |
| | | | DNS resolver. |
| | | | |
| qtype | String | Yes | The type of DNS query made by |
| | | | the UA's DNS resolvers in |
| | | | uppercase. The value of this |
| | | | field SHALL be set to either |
| | | | 'A' or 'AAAA'. |
| | | | |
| qclass | String | Yes | The class of DNS query made |
| | | | in uppercase (IN, etc.). |
| | | | |
| qname | String | Yes | The fully qualified domain |
| | | | name being queried. |
| | | | |
| c-subnet | String | No | The IP address (or prefix) of |
| | | | the UA in Classless Inter- |
| | | | Domain Routing (CIDR) format. |
| | | | |
| dns-only | Boolean | No | If True, then dCDN MUST only |
| | | | use DNS redirection and MUST |
| | | | include RTs to one or more |
| | | | surrogates in any successful |
| | | | RI response. CDNs MUST |
| | | | include the dns-only property |
| | | | set to True on any cascaded |
| | | | RI requests. Defaults to |
| | | | False. |
+-------------+---------+-----------+-------------------------------+
+-------------+---------+-----------+-------------------------------+
| Key | Value | Mandatory | Description |
+-------------+---------+-----------+-------------------------------+
| resolver-ip | String | Yes | The IP address of the UA's |
| | | | DNS resolver. |
| | | | |
| qtype | String | Yes | The type of DNS query made by |
| | | | the UA's DNS resolvers in |
| | | | uppercase. The value of this |
| | | | field SHALL be set to either |
| | | | 'A' or 'AAAA'. |
| | | | |
| qclass | String | Yes | The class of DNS query made |
| | | | in uppercase (IN, etc.). |
| | | | |
| qname | String | Yes | The fully qualified domain |
| | | | name being queried. |
| | | | |
| c-subnet | String | No | The IP address (or prefix) of |
| | | | the UA in Classless Inter- |
| | | | Domain Routing (CIDR) format. |
| | | | |
| dns-only | Boolean | No | If True, then dCDN MUST only |
| | | | use DNS redirection and MUST |
| | | | include RTs to one or more |
| | | | surrogates in any successful |
| | | | RI response. CDNs MUST |
| | | | include the dns-only property |
| | | | set to True on any cascaded |
| | | | RI requests. Defaults to |
| | | | False. |
+-------------+---------+-----------+-------------------------------+
Table 2
表2
An RI request for DNS-based redirection MUST include a dns dictionary. This dns dictionary MUST contain the following keys: resolver-ip, qtype, qclass, and qname; the value of each MUST be the value of the appropriate part of the User Agent's DNS query/request. For internationalized domain names containing non-ASCII characters, the value of the qname field MUST be the ASCII-compatible encoded (ACE) representation (A-label) of the domain name [RFC5890].
基于DNS重定向的RI请求必须包括DNS字典。此dns字典必须包含以下密钥：解析程序ip、qtype、qclass和qname；每个的值必须是用户代理的DNS查询/请求的适当部分的值。对于包含非ASCII字符的国际化域名，qname字段的值必须是域名[RFC5890]的ASCII兼容编码（ACE）表示（A标签）。
An example RI request (uCDN->dCDN) for DNS-based redirection is as follows:
基于DNS的重定向的示例RI请求（uCDN->dCDN）如下所示：
POST /dcdn/ri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni; ptype=redirection-request
Accept: application/cdni; ptype=redirection-response
POST /dcdn/ri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni; ptype=redirection-request
Accept: application/cdni; ptype=redirection-response
{
"dns" : {
"resolver-ip" : "192.0.2.1",
"c-subnet" : "198.51.100.0/24",
"qtype" : "A",
"qclass" : "IN",
"qname" : "www.example.com"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}
{
"dns" : {
"resolver-ip" : "192.0.2.1",
"c-subnet" : "198.51.100.0/24",
"qtype" : "A",
"qclass" : "IN",
"qname" : "www.example.com"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}
For a successful DNS-based redirection, the dCDN needs to return one of the following to the uCDN in the RI response:
对于成功的基于DNS的重定向，dCDN需要在RI响应中将以下内容之一返回给uCDN：
o The IP address(es) of (or the CNAME of) RTs that are dCDN surrogates (if the dCDN is performing DNS-based redirection directly to a surrogate); or
o 作为dCDN代理的RTs的IP地址（或CNAME）（如果dCDN直接执行到代理的基于DNS的重定向）；或
o The IP address(es) of (or the CNAME of) RTs that are Request Routers (if the dCDN will perform request redirection itself). A dCDN MUST NOT return an RT that is a Request Router if the dns-only key is set to True in the RI request.
o 作为请求路由器的RTs的IP地址（或CNAME）（如果dCDN本身将执行请求重定向）。如果在RI请求中仅dns密钥设置为True，则dCDN不得返回作为请求路由器的RT。
The preceding information is encoded as a set of key:value pairs within the dns dictionary as follows:
上述信息在dns字典中编码为一组键：值对，如下所示：
+-------+-----------+-----------+-----------------------------------+
| Key | Value | Mandatory | Description |
+-------+-----------+-----------+-----------------------------------+
| rcode | Integer | Yes | DNS response code (see |
| | | | [RFC6895]). |
| | | | |
| name | String | Yes | The fully qualified domain name |
| | | | the response relates to. |
| | | | |
| a | List of | No | Set of IPv4 Addresses of RT(s). |
| | String | | |
| | | | |
| aaaa | List of | No | Set of IPv6 Addresses of RT(s). |
| | String | | |
| | | | |
| cname | List of | No | Set of fully qualified domain |
| | String | | names of RT(s). |
| | | | |
| ttl | Integer | No | TTL in seconds of DNS response. |
| | | | Default is 0. |
+-------+-----------+-----------+-----------------------------------+
+-------+-----------+-----------+-----------------------------------+
| Key | Value | Mandatory | Description |
+-------+-----------+-----------+-----------------------------------+
| rcode | Integer | Yes | DNS response code (see |
| | | | [RFC6895]). |
| | | | |
| name | String | Yes | The fully qualified domain name |
| | | | the response relates to. |
| | | | |
| a | List of | No | Set of IPv4 Addresses of RT(s). |
| | String | | |
| | | | |
| aaaa | List of | No | Set of IPv6 Addresses of RT(s). |
| | String | | |
| | | | |
| cname | List of | No | Set of fully qualified domain |
| | String | | names of RT(s). |
| | | | |
| ttl | Integer | No | TTL in seconds of DNS response. |
| | | | Default is 0. |
+-------+-----------+-----------+-----------------------------------+
Table 3
表3
A successful RI response for DNS-based redirection MUST include a dns dictionary and MAY include an error dictionary (see Section 4.7). An unsuccessful RI response for DNS-based redirection MUST include an error dictionary. If a dns dictionary is included in the RI response, it MUST include the rcode and name keys and it MUST include at least one of the following keys: a, aaaa, or cname. The dns dictionary MAY include both a and aaaa keys. If the dns dictionary contains a cname key, it MUST NOT contain either an a or aaaa key. For internationalized domain names containing non-ASCII characters, the value of the cname field MUST be the ACE representation (A-label) of the domain name.
基于DNS的重定向的成功RI响应必须包括DNS字典，并且可能包括错误字典（参见第4.7节）。基于DNS的重定向的不成功RI响应必须包含错误字典。如果RI响应中包含dns字典，则它必须包含rcode和name键，并且必须至少包含以下键之一：a、aaaa或cname。dns字典可能包括a和aaaa密钥。如果dns字典包含cname密钥，则它不能包含a或aaaa密钥。对于包含非ASCII字符的国际化域名，cname字段的值必须是域名的ACE表示（A标签）。
An example of a successful RI response (dCDN->uCDN) for DNS-based redirection with both a and aaaa keys is listed below:
下面列出了使用a和aaaa密钥进行基于DNS的重定向的成功RI响应（dCDN->uCDN）的示例：
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201", "203.0.113.202"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
}
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201", "203.0.113.202"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
}
A further example of a successful RI response (dCDN->uCDN) for DNS-based redirection is listed below, in this case with a cname key containing the FQDN of the RT.
下面列出了基于DNS的重定向的成功RI响应（dCDN->uCDN）的另一个示例，在本例中，使用包含RT的FQDN的cname键。
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"cname" : ["rr1.dcdn.example"],
"ttl" : 20
}
}
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"cname" : ["rr1.dcdn.example"],
"ttl" : 20
}
}
The following sections provide detailed descriptions of the information that should be passed in RI requests and responses for HTTP redirection.
以下各节详细描述了应在HTTP重定向的RI请求和响应中传递的信息。
The dictionary keys used in HTTP Redirection requests and responses use the following conventions for their prefixes:
HTTP重定向请求和响应中使用的字典键的前缀使用以下约定：
o c- is prefixed to keys for information related to the Client (User Agent).
o c-作为与客户机（用户代理）相关信息的键的前缀。
o cs- is prefixed to keys for information passed by the Client (User Agent) to the Server (uCDN).
o cs-前缀为客户端（用户代理）传递给服务器（uCDN）的信息的密钥。
o sc- is prefixed to keys for information to be passed by the Server (uCDN) to the Client (User Agent).
o sc-前缀为密钥，用于服务器（uCDN）传递给客户端（用户代理）的信息。
For HTTP-based redirection, the uCDN needs to pass the following information to the dCDN in the RI request:
对于基于HTTP的重定向，uCDN需要在RI请求中将以下信息传递给dCDN：
o The IP address of the User Agent.
o 用户代理的IP地址。
o The URI requested by the User Agent.
o 用户代理请求的URI。
o The HTTP method requested by the User Agent.
o 用户代理请求的HTTP方法。
o The HTTP version number requested by the User Agent.
o 用户代理请求的HTTP版本号。
The uCDN may also decide to pass the presence and value of particular HTTP headers included in the User Agent request to the dCDN.
uCDN还可以决定将用户代理请求中包含的特定HTTP头的存在和值传递给dCDN。
The preceding information is encoded as a set of key:value pairs within the http dictionary as follows:
上述信息在http字典中被编码为一组key:value对，如下所示：
+-------------------+--------+-----------+--------------------------+
| Key | Value | Mandatory | Description |
+-------------------+--------+-----------+--------------------------+
| c-ip | String | Yes | The IP address of the |
| | | | UA. |
| | | | |
| cs-uri | String | Yes | The Effective Request |
| | | | URI [RFC7230] requested |
| | | | by the UA. |
| | | | |
| cs-method | String | Yes | The method part of the |
| | | | request-line as defined |
| | | | in Section 3.1.1 of |
| | | | [RFC7230]. |
| | | | |
| cs-version | String | Yes | The HTTP-version part of |
| | | | the request-line as |
| | | | defined in Section 3.1.1 |
| | | | of [RFC7230]. |
| | | | |
| cs-(<headername>) | String | No | The field-value of the |
| | | | HTTP header field named |
| | | | <HeaderName> as a |
| | | | string, for example, |
| | | | cs-(cookie) would |
| | | | contain the value of the |
| | | | HTTP Cookie header from |
| | | | the UA request. |
+-------------------+--------+-----------+--------------------------+
+-------------------+--------+-----------+--------------------------+
| Key | Value | Mandatory | Description |
+-------------------+--------+-----------+--------------------------+
| c-ip | String | Yes | The IP address of the |
| | | | UA. |
| | | | |
| cs-uri | String | Yes | The Effective Request |
| | | | URI [RFC7230] requested |
| | | | by the UA. |
| | | | |
| cs-method | String | Yes | The method part of the |
| | | | request-line as defined |
| | | | in Section 3.1.1 of |
| | | | [RFC7230]. |
| | | | |
| cs-version | String | Yes | The HTTP-version part of |
| | | | the request-line as |
| | | | defined in Section 3.1.1 |
| | | | of [RFC7230]. |
| | | | |
| cs-(<headername>) | String | No | The field-value of the |
| | | | HTTP header field named |
| | | | <HeaderName> as a |
| | | | string, for example, |
| | | | cs-(cookie) would |
| | | | contain the value of the |
| | | | HTTP Cookie header from |
| | | | the UA request. |
+-------------------+--------+-----------+--------------------------+
Table 4
表4
An RI request for HTTP-based redirection MUST include an http dictionary. This http dictionary MUST contain the following keys: c-ip, cs-method, cs-version, and cs-uri; the value of each MUST be the value of the appropriate part of the User Agent's HTTP request.
基于HTTP重定向的RI请求必须包括HTTP字典。此http字典必须包含以下键：c-ip、cs方法、cs版本和cs uri；每个的值必须是用户代理HTTP请求的适当部分的值。
The http dictionary of an RI request MUST contain a maximum of one cs-(<headername>) key for each unique header field-name (HTTP header field). <headername> MUST be identical to the equivalent HTTP header field-name encoded in all lowercase.
RI请求的http字典对于每个唯一的头字段名称（http头字段），最多必须包含一个cs-（<headername>）键<headername>必须与所有小写编码的等效HTTP标头字段名相同。
In the case where the User Agent request includes multiple HTTP header fields with the same field-name, it is RECOMMENDED that the uCDN combine these different HTTP headers into a single value according to Section 3.2.2 of [RFC7230]. However, because of the plurality of already defined HTTP header fields and the inconsistency of some of these header fields concerning the combination mechanism defined in RFC 7230, the uCDN MAY have to deviate from using the combination mechanism where appropriate. For example, it might only send the contents of the first occurrence of the HTTP Headers instead.
如果用户代理请求包含多个具有相同字段名的HTTP头字段，建议uCDN根据[RFC7230]第3.2.2节将这些不同的HTTP头合并为一个值。然而，由于多个已经定义的HTTP报头字段以及这些报头字段中的一些与RFC 7230中定义的组合机制有关的不一致，uCDN可能不得不在适当的情况下偏离使用组合机制。例如，它可能只发送第一次出现的HTTP头的内容。
An example RI request (uCDN->dCDN) for HTTP-based redirection is as follows:
基于HTTP的重定向的示例RI请求（uCDN->dCDN）如下所示：
POST /dcdn/rrri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni; ptype=redirection-request
Accept: application/cdni; ptype=redirection-response
POST /dcdn/rrri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni; ptype=redirection-request
Accept: application/cdni; ptype=redirection-response
{
"http": {
"c-ip": "198.51.100.1",
"cs-uri": "http://www.example.com",
"cs-version": "HTTP/1.1",
"cs-method": "GET"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}
{
"http": {
"c-ip": "198.51.100.1",
"cs-uri": "http://www.example.com",
"cs-version": "HTTP/1.1",
"cs-method": "GET"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}
For a successful HTTP-based redirection, the dCDN needs to return one of the following to the uCDN in the RI response:
为了成功实现基于HTTP的重定向，dCDN需要在RI响应中将以下内容之一返回给uCDN：
o A URI pointing to an RT that is the selected dCDN surrogate(s) (if the dCDN is performing HTTP-based redirection directly to a surrogate); or
o 一个URI，指向作为所选dCDN代理项的RT（如果dCDN直接执行到代理项的基于HTTP的重定向）；或
o A URI pointing to an RT that is a Request Router (if the dCDN will perform request redirection itself).
o 指向作为请求路由器的RT的URI（如果dCDN本身将执行请求重定向）。
The preceding information is encoded as a set of key:value pairs within the http dictionary as follows:
上述信息在http字典中被编码为一组key:value对，如下所示：
+-------------------+---------+-----------+-------------------------+
| Key | Value | Mandatory | Description |
+-------------------+---------+-----------+-------------------------+
| sc-status | Integer | Yes | The status-code part of |
| | | | the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA |
| | | | (usually set to 302). |
| | | | |
| sc-version | String | Yes | The HTTP-version part |
| | | | of the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA. |
| | | | |
| sc-reason | String | Yes | The reason-phrase part |
| | | | of the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA. |
| | | | |
| cs-uri | String | Yes | The URI requested by |
| | | | the UA/client. |
| | | | |
| sc-(location) | String | Yes | The contents of the |
| | | | Location header to |
| | | | return to the UA (i.e., |
| | | | a URI pointing to the |
| | | | RT(s)). |
| | | | |
| sc-(<headername>) | String | No | The field-value of the |
| | | | HTTP header field named |
| | | | <HeaderName> to return |
| | | | to the UA. For example, |
| | | | sc-(expires) would |
| | | | contain the value of |
| | | | the HTTP Expires |
| | | | header. |
+-------------------+---------+-----------+-------------------------+
+-------------------+---------+-----------+-------------------------+
| Key | Value | Mandatory | Description |
+-------------------+---------+-----------+-------------------------+
| sc-status | Integer | Yes | The status-code part of |
| | | | the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA |
| | | | (usually set to 302). |
| | | | |
| sc-version | String | Yes | The HTTP-version part |
| | | | of the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA. |
| | | | |
| sc-reason | String | Yes | The reason-phrase part |
| | | | of the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA. |
| | | | |
| cs-uri | String | Yes | The URI requested by |
| | | | the UA/client. |
| | | | |
| sc-(location) | String | Yes | The contents of the |
| | | | Location header to |
| | | | return to the UA (i.e., |
| | | | a URI pointing to the |
| | | | RT(s)). |
| | | | |
| sc-(<headername>) | String | No | The field-value of the |
| | | | HTTP header field named |
| | | | <HeaderName> to return |
| | | | to the UA. For example, |
| | | | sc-(expires) would |
| | | | contain the value of |
| | | | the HTTP Expires |
| | | | header. |
+-------------------+---------+-----------+-------------------------+
Table 5
表5
Note: The sc-(location) key in the preceding table is an example of sc-(<headername>) that has been called out separately as its presence is mandatory in RI responses.
注：上表中的sc-（位置）键是sc-（<headername>）的一个示例，它已被单独调用，因为它在RI响应中是必需的。
A successful RI response for HTTP-based redirection MUST include an http dictionary and MAY include an error dictionary (see Section 4.7). An unsuccessful RI response for HTTP-based redirection MUST include an error dictionary. If an http dictionary is included in the RI response, it MUST include at least the following keys: sc-status, sc-version, sc-reason, cs-uri, and sc-(location).
基于HTTP的重定向的成功RI响应必须包括HTTP字典，并且可能包括错误字典（参见第4.7节）。基于HTTP的重定向的不成功RI响应必须包含错误字典。如果RI响应中包含http字典，则它必须至少包含以下键：sc状态、sc版本、sc原因、cs uri和sc-（位置）。
The http dictionary of an RI response MUST contain a maximum of one sc-(<headername>) key for each unique header field-name (HTTP header field). <headername> MUST be identical to the equivalent HTTP header field-name encoded in all lowercase.
RI响应的http字典对于每个唯一的头字段名称（http头字段），最多必须包含一个sc-（<headername>）键<headername>必须与所有小写编码的等效HTTP标头字段名相同。
The uCDN MAY decide to not return, override, or alter any or all of the HTTP headers defined by sc-(<headername>) keys before sending the HTTP response to the UA. It should be noted that in some cases, sending the HTTP Headers indicated by the dCDN transparently on to the UA might result in, for the uCDN, undesired behavior. As an example, the dCDN might include sc-(cache-control), sc-(last-modified), and sc-(expires) keys in the http dictionary, through which the dCDN may try to influence the cacheability of the response by the UA. If the uCDN would pass these HTTP headers on to the UA, this could mean that further requests from the uCDN would go directly to the dCDN, bypassing the uCDN and any logging it may perform on incoming requests. Therefore, the uCDN is recommended to carefully consider which HTTP headers to pass on, and which to either override or not pass on at all.
在向UA发送HTTP响应之前，uCDN可能决定不返回、覆盖或更改由sc-（<headername>）键定义的任何或所有HTTP头。应该注意的是，在某些情况下，将dCDN指示的HTTP头透明地发送到UA可能会导致uCDN出现不希望出现的行为。例如，dCDN可以在http字典中包括sc-（缓存控制）、sc-（上次修改）和sc-（过期）密钥，通过这些密钥，dCDN可以尝试影响UA响应的可缓存性。如果uCDN将这些HTTP头传递给UA，这可能意味着来自uCDN的进一步请求将直接发送到dCDN，从而绕过uCDN及其可能对传入请求执行的任何日志记录。因此，建议UCDN仔细考虑要传递哪些HTTP报头，或者完全重写或不传递。
An example of a successful RI response (dCDN->uCDN) for HTTP-based redirection is a follows:
基于HTTP的重定向的成功RI响应（dCDN->uCDN）示例如下：
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
}
}
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
}
}
RI responses may be cacheable. As long as a cached RI response is not stale according to standard HTTP Cache-Control or other applicable mechanisms, it may be reused by the uCDN in response to User Agent requests without sending another RI request to the dCDN.
RI响应可能是可缓存的。根据标准HTTP缓存控制或其他适用机制，只要缓存的RI响应不过时，uCDN就可以重新使用它来响应用户代理请求，而无需向dCDN发送另一个RI请求。
An RI response MUST NOT be reused unless the request from the User Agent would generate an identical RI request to the dCDN as the one that resulted in the cached RI response (except for the c-ip field provided that the User Agent's c-ip is covered by the scope in the original RI response, as elaborated upon below).
不得重用RI响应，除非来自用户代理的请求将向dCDN生成与导致缓存RI响应的请求相同的RI请求（c-ip字段除外，前提是用户代理的c-ip包含在原始RI响应的范围内，如下所述）。
Additionally, although RI requests only encode a single User Agent request to be redirected, there may be cases where a dCDN wishes to indicate to the uCDN that the RI response can be reused for other User Agent requests without the uCDN having to make another request via the RI. For example, a dCDN may know that it will always select the same surrogates for a given set of User Agent IP addresses and in order to reduce request volume across the RI or to remove the additional latency associated with an RI request, the dCDN may wish to indicate that set of User Agent IP addresses to the uCDN in the initial RI response. This is achieved by including an optional scope dictionary in the RI response.
此外，尽管RI请求仅对要重定向的单个用户代理请求进行编码，但是可能存在dCDN希望向uCDN指示RI响应可用于其他用户代理请求的情况，而uCDN不必通过RI发出另一请求。例如，dCDN可能知道它将始终为给定的一组用户代理IP地址选择相同的代理，并且为了减少整个RI的请求量或移除与RI请求相关联的额外延迟，dCDN可能希望在初始RI响应中将该组用户代理IP地址指示给uCDN。这是通过在RI响应中包含可选的作用域字典来实现的。
Scope is encoded as a set of key:value pairs within the scope dictionary as follows:
作用域在作用域字典中编码为一组键：值对，如下所示：
+---------+--------+-----------+------------------------------------+
| Key | Value | Mandatory | Description |
+---------+--------+-----------+------------------------------------+
| iprange | List | No | A List of IP subnets in CIDR |
| | of | | notation that this RI response can |
| | String | | be reused for, provided the RI |
| | | | response is still considered |
| | | | fresh. |
+---------+--------+-----------+------------------------------------+
+---------+--------+-----------+------------------------------------+
| Key | Value | Mandatory | Description |
+---------+--------+-----------+------------------------------------+
| iprange | List | No | A List of IP subnets in CIDR |
| | of | | notation that this RI response can |
| | String | | be reused for, provided the RI |
| | | | response is still considered |
| | | | fresh. |
+---------+--------+-----------+------------------------------------+
Table 6
表6
If a uCDN has multiple cached responses with overlapping scopes and a UA request comes in for which the User Agent's IP matches with the IP subnets in multiple of these cached responses, the uCDN SHOULD use the most recent cached response when determining the appropriate RI response to use.
如果uCDN具有多个具有重叠作用域的缓存响应，并且收到用户代理的IP与多个缓存响应中的IP子网匹配的UA请求，则uCDN在确定要使用的适当RI响应时应使用最新的缓存响应。
The following is an example of a DNS redirection response from Section 4.4.2 that is cacheable by the uCDN for 30 seconds and can be returned to any User Agent with an IPv4 address in 198.51.100.0/24.
以下是第4.4.2节中的DNS重定向响应示例，该响应可由uCDN缓存30秒，并可返回到198.51.100.0/24中具有IPv4地址的任何用户代理。
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: public, max-age=30
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: public, max-age=30
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}
The following is an example of an HTTP redirection response from Section 4.5.2 that is cacheable by the uCDN for 60 seconds and can be returned to any User Agent with an IPv4 address in 198.51.100.0/24.
以下是第4.5.2节中的HTTP重定向响应示例，该响应可由uCDN缓存60秒，并可返回到198.51.100.0/24中具有IPv4地址的任何用户代理。
Note: The response to the UA is only valid for 30 seconds, whereas the uCDN can cache the RI response for 60 seconds.
注意：对UA的响应仅在30秒内有效，而uCDN可以缓存RI响应60秒。
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: public, max-age=60
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: public, max-age=60
{
"http": {
"sc-status": 302,
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
"sc-(cache-control)" : "public, max-age=30"
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}
{
"http": {
"sc-status": 302,
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
"sc-(cache-control)" : "public, max-age=30"
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}
From a uCDN perspective, there are two types of errors that can be the result of the transmission of an RI request to a dCDN:
从uCDN的角度来看，将RI请求传输到dCDN可能导致两种类型的错误：
1. An HTTP protocol error signaled via an HTTP status code, indicating a problem with the reception or parsing of the RI request or the generation of the RI response by the dCDN, and
1. 通过HTTP状态代码发出的HTTP协议错误信号，指示dCDN接收或解析RI请求或生成RI响应的问题，以及
2. An RI-level error specified in an RI response message.
2. 在RI响应消息中指定的RI级别错误。
This section deals with the latter type. The former type is outside the scope of this document.
本节讨论后一种类型。前一种类型不在本文档的范围内。
There are numerous reasons for a dCDN to be unable to return an affirmative RI response to a uCDN. Reasons may include both dCDN internal issues such as capacity problems, as well as reasons outside the influence of the dCDN, such as a malformed RI request. To aid with diagnosing the cause of errors, RI responses SHOULD include an error dictionary to provide additional information to the uCDN as to the reason/cause of the error. The intention behind the error dictionary is to aid with either manual or automatic diagnosis of issues. The resolution of such issues is outside the scope of this document; this document does not specify any consequent actions a uCDN should take upon receiving a particular error-code.
dCDN无法向uCDN返回肯定RI响应的原因有很多。原因可能包括dCDN内部问题（如容量问题）以及dCDN影响之外的原因（如格式错误的RI请求）。为了帮助诊断错误原因，RI响应应包括一个错误字典，以向uCDN提供有关错误原因/原因的附加信息。错误字典的目的是帮助手动或自动诊断问题。此类问题的解决不在本文件范围内；本文档未指定uCDN在收到特定错误代码时应采取的任何后续操作。
Error information (if present) is encoded as a set of key:value pairs within a JSON-encoded error dictionary as follows:
错误信息（如果存在）在JSON编码的错误字典中编码为一组键：值对，如下所示：
+------------+---------+-----------+--------------------------------+
| Key | Value | Mandatory | Description |
+------------+---------+-----------+--------------------------------+
| error-code | Integer | Yes | A three-digit numeric code |
| | | | defined by the server to |
| | | | indicate the error(s) that |
| | | | occurred. |
| | | | |
| reason | String | No | A string providing further |
| | | | information related to the |
| | | | error. |
+------------+---------+-----------+--------------------------------+
+------------+---------+-----------+--------------------------------+
| Key | Value | Mandatory | Description |
+------------+---------+-----------+--------------------------------+
| error-code | Integer | Yes | A three-digit numeric code |
| | | | defined by the server to |
| | | | indicate the error(s) that |
| | | | occurred. |
| | | | |
| reason | String | No | A string providing further |
| | | | information related to the |
| | | | error. |
+------------+---------+-----------+--------------------------------+
Table 7
表7
The first digit of the error-code defines the class of error. There are 5 classes of errors distinguished by the first digit of the error-code:
错误代码的第一位数字定义了错误类别。错误代码的第一位数字可区分5类错误：
1xx: Informational (no error): The response should not be considered an error by the uCDN, which may proceed by redirecting the UA according to the values in the RI response. The error-code and accompanying description may be used for informational purposes, e.g., for logging.
1xx：信息性（无错误）：uCDN不应将响应视为错误，它可以根据RI响应中的值重定向UA。错误代码和附带的说明可用于信息目的，例如用于日志记录。
2xx: Reserved.
2xx：保留。
3xx: Reserved.
3xx：保留。
4xx: uCDN error: The dCDN cannot or will not process the request due to something that is perceived to be a uCDN error, for example, the RI request could not be parsed successfully by the dCDN. The last two-digits may be used to more specifically indicate the source of the problem.
4xx:uCDN错误：dCDN无法或将不会处理请求，原因是被认为是uCDN错误，例如，dCDN无法成功解析RI请求。最后两位数字可用于更具体地指示问题的根源。
5xx: dCDN error: Indicates that the dCDN is aware that it has erred or is incapable of satisfying the RI request for some reason, for example, the dCDN was able to parse the RI request but encountered an error for some reason. Examples include the dCDN not being able to retrieve the associated metadata or the dCDN being out of capacity.
5xx:dCDN error：表示dCDN知道由于某种原因出现了错误或无法满足RI请求，例如，dCDN能够解析RI请求，但由于某种原因遇到了错误。示例包括dCDN无法检索关联的元数据或dCDN容量不足。
The following error-codes are defined and maintained by IANA (see Section 6).
IANA定义并维护以下错误代码（见第6节）。
Error-codes with a "Reason" of "<reason>" do not have a defined value for their 'reason'-key. Depending on the error-code semantics, the value of this field may be determined dynamically.
“原因”为“<Reason>”的错误代码的“原因”键没有定义值。根据错误代码语义，可以动态确定此字段的值。
+------+--------------+---------------------------------------------+
| Code | Reason | Description |
+------+--------------+---------------------------------------------+
| 100 | <reason> | Generic informational error-code meant for |
| | (see | carrying a human-readable string |
| | Description) | |
| | | |
| 400 | <reason> | Generic error-code for uCDN errors where |
| | (see | the dCDN cannot or will not process the |
| | Description) | request due to something that is perceived |
| | | to be a uCDN error. The reason field may |
| | | be used to provide more details about the |
| | | source of the error. |
| | | |
+------+--------------+---------------------------------------------+
| Code | Reason | Description |
+------+--------------+---------------------------------------------+
| 100 | <reason> | Generic informational error-code meant for |
| | (see | carrying a human-readable string |
| | Description) | |
| | | |
| 400 | <reason> | Generic error-code for uCDN errors where |
| | (see | the dCDN cannot or will not process the |
| | Description) | request due to something that is perceived |
| | | to be a uCDN error. The reason field may |
| | | be used to provide more details about the |
| | | source of the error. |
| | | |
| 500 | <reason> | Generic error-code for dCDN errors where |
| | (see | the dCDN is aware that it has erred or is |
| | Description) | incapable of satisfying the RI request for |
| | | some reason. The reason field may be used |
| | | to provide more details about the source of |
| | | the error. |
| | | |
| 501 | Unable to | The dCDN is unable to retrieve the metadata |
| | retrieve | associated with the content requested by |
| | metadata | the UA. This may indicate a configuration |
| | | error or that the content requested by the |
| | | UA does not exist. |
| | | |
| 502 | Loop | The dCDN detected a redirection loop (see |
| | detected | Section 4.8). |
| | | |
| 503 | Maximum hops | The dCDN detected the maximum number of |
| | exceeded | redirection hops exceeding max-hops (see |
| | | Section 4.8). |
| | | |
| 504 | Out of | The dCDN does not currently have sufficient |
| | capacity | capacity to handle the UA request. |
| | | |
| 505 | Delivery | The dCDN does not support the (set of) |
| | protocol not | delivery protocols indicated in the CDNI |
| | supported | Metadata of the content requested by the |
| | | UA. |
| | | |
| 506 | Redirection | The dCDN does not support the requested |
| | protocol not | redirection protocol. This error-code is |
| | supported | also used when the RI request has the dns- |
| | | only flag set to True and the dCDN is not |
| | | supported or is not prepared to return an |
| | | RT of a surrogate directly. |
+------+--------------+---------------------------------------------+
| 500 | <reason> | Generic error-code for dCDN errors where |
| | (see | the dCDN is aware that it has erred or is |
| | Description) | incapable of satisfying the RI request for |
| | | some reason. The reason field may be used |
| | | to provide more details about the source of |
| | | the error. |
| | | |
| 501 | Unable to | The dCDN is unable to retrieve the metadata |
| | retrieve | associated with the content requested by |
| | metadata | the UA. This may indicate a configuration |
| | | error or that the content requested by the |
| | | UA does not exist. |
| | | |
| 502 | Loop | The dCDN detected a redirection loop (see |
| | detected | Section 4.8). |
| | | |
| 503 | Maximum hops | The dCDN detected the maximum number of |
| | exceeded | redirection hops exceeding max-hops (see |
| | | Section 4.8). |
| | | |
| 504 | Out of | The dCDN does not currently have sufficient |
| | capacity | capacity to handle the UA request. |
| | | |
| 505 | Delivery | The dCDN does not support the (set of) |
| | protocol not | delivery protocols indicated in the CDNI |
| | supported | Metadata of the content requested by the |
| | | UA. |
| | | |
| 506 | Redirection | The dCDN does not support the requested |
| | protocol not | redirection protocol. This error-code is |
| | supported | also used when the RI request has the dns- |
| | | only flag set to True and the dCDN is not |
| | | supported or is not prepared to return an |
| | | RT of a surrogate directly. |
+------+--------------+---------------------------------------------+
Table 8
表8
The following is an example of an unsuccessful RI response (dCDN->uCDN) for a DNS-based User Agent request:
以下是基于DNS的用户代理请求的不成功RI响应（dCDN->uCDN）的示例：
HTTP/1.1 500 Internal Server Error
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: private, no-cache
HTTP/1.1 500 Internal Server Error
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: private, no-cache
{
"error" : {
"error-code" : 504,
"description" : "Out of capacity"
}
}
{
"error" : {
"error-code" : 504,
"description" : "Out of capacity"
}
}
The following is an example of a successful RI response (dCDN->uCDN) for an HTTP-based User Agent request containing an error dictionary for informational purposes:
以下是一个成功响应基于HTTP的用户代理请求的RI响应（dCDN->uCDN）的示例，该请求包含一个用于提供信息的错误字典：
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: private, no-cache
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: private, no-cache
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
},
"error" : {
"error-code" : 100,
"description" :
"This is a human-readable message meant for debugging purposes"
}
}
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
},
"error" : {
"error-code" : 100,
"description" :
"This is a human-readable message meant for debugging purposes"
}
}
In order to prevent and detect RI request loops, each CDN MUST insert its CDN Provider ID into the cdn-path key of every RI request it originates or cascades. When receiving RI requests, a dCDN MUST check the cdn-path and reject any RI requests that already contain the dCDN's Provider ID in the cdn-path. Transit CDNs MUST NOT propagate to any downstream CDNs if the number of CDN Provider IDs in cdn-path (before adding its own Provider ID) is equal to or greater than max-hops.
为了防止和检测RI请求循环，每个CDN必须将其CDN提供者ID插入其发起或级联的每个RI请求的CDN路径密钥中。当接收RI请求时，dCDN必须检查cdn路径并拒绝cdn路径中已经包含dCDN的提供者ID的任何RI请求。如果CDN路径中的CDN提供程序ID数（在添加自己的提供程序ID之前）等于或大于最大跳数，则传输CDN不得传播到任何下游CDN。
The CDN Provider ID uniquely identifies each CDN Provider during the course of request routing redirection. It consists of the characters AS followed by the CDN Provider's AS number, then a colon (':') and an additional qualifier that is used to guarantee uniqueness in case a particular AS has multiple independent CDNs deployed; for example, "AS64496:0".
CDN提供程序ID在请求路由重定向过程中唯一标识每个CDN提供程序。它由字符组成，后跟CDN提供程序的AS编号，然后是冒号（“：”）和附加限定符，用于在特定AS部署了多个独立CDN的情况下保证唯一性；例如，“AS64496:0”。
If a dCDN receives an RI request whose cdn-path already contains that dCDN's Provider ID, the dCDN MUST send an RI error response that SHOULD include an error-code of 502.
如果dCDN接收到其cdn路径已包含该dCDN的提供者ID的RI请求，则dCDN必须发送一个RI错误响应，该响应应包括错误代码502。
If a dCDN receives an RI request where the number of CDN Provider IDs in cdn-path is greater than max-hops, the dCDN MUST send an RI error response that SHOULD include an error-code of 503.
如果dCDN接收到一个RI请求，其中CDN路径中的CDN提供程序ID数大于最大跳数，则dCDN必须发送一个RI错误响应，该响应应包括一个错误代码503。
It should be noted that the loop detection and prevention mechanisms described above only cover preventing and detecting loops within the RI itself. Besides loops within the RI itself, there is also the possibility of loops in the data plane; for example, if the IP address(es) or URI(s) returned in RI responses do not resolve directly to a surrogate in the final dCDN, there is the possibility that a User Agent may be continuously redirected through a loop of CDNs. The specification of solutions to address data-plane request redirection loops between CDNs is outside of the scope of this document.
应该注意的是，上面描述的环路检测和预防机制仅包括在RI本身内防止和检测环路。除了RI本身中的循环外，数据平面中也可能存在循环；例如，如果在RI响应中返回的IP地址或URI没有直接解析为最终dCDN中的代理，则有可能通过cdn循环连续重定向用户代理。解决CDN之间数据平面请求重定向循环的解决方案规范不在本文档范围内。
Information passed over the RI could be considered personal or sensitive, for example, RI requests contain parts of a User Agent's original request and RI responses reveal information about the dCDN's policy for which surrogates should serve which content/user locations.
通过RI传递的信息可能被视为个人信息或敏感信息，例如，RI请求包含用户代理原始请求的一部分，而RI响应揭示了有关dCDN策略的信息，其中代理应为哪些内容/用户位置提供服务。
The RI interface also provides a mechanism whereby a uCDN could probe a dCDN and infer the dCDN's edge topology by making repeated RI requests for different content and/or UA IP addresses and correlating the responses from the dCDN. Additionally, the ability for a dCDN to indicate that an RI response applies more widely than the original request (via the scope dictionary) may significantly reduce the number of RI requests required to probe and infer the dCDN's edge topology.
RI接口还提供了一种机制，uCDN可以通过对不同内容和/或UA IP地址发出重复的RI请求并关联来自dCDN的响应来探测dCDN并推断dCDN的边缘拓扑。此外，dCDN能够指示RI响应比原始请求（通过作用域字典）应用得更广泛，这可以显著减少探测和推断dCDN边缘拓扑所需的RI请求数量。
The same information could be obtained in the absence of the RI interface, but it could be more difficult to gather as it would require a distributed set of machines with a range of different IP addresses, each making requests directly to the dCDN. However, the RI facilitates easier collection of such information as it enables a single client to query the dCDN for a redirection/surrogate selection on behalf of any UA IP address.
在没有RI接口的情况下，可以获得相同的信息，但收集起来可能更困难，因为这需要一组具有不同IP地址的分布式计算机，每个计算机直接向dCDN发出请求。然而，RI有助于更容易地收集此类信息，因为它使单个客户端能够代表任何UA IP地址查询dCDN以进行重定向/代理选择。
5.1. Authentication, Authorization, Confidentiality, and Integrity Protection
5.1. 身份验证、授权、机密性和完整性保护
An implementation of the CDNI Redirection interface MUST support TLS transport as per [RFC2818] and [RFC7230]. The use of TLS for transport of the CDNI Redirection interface messages allows the dCDN and uCDN to authenticate each other. Once they have mutually authenticated each other, it allows:
根据[RFC2818]和[RFC7230]，CDNI重定向接口的实现必须支持TLS传输。使用TLS传输CDNI重定向接口消息允许dCDN和uCDN相互验证。一旦他们相互认证，它允许：
o The dCDN and uCDN to authorize each other (to ensure they are transmitting/receiving CDNI Redirection messages to/from an authorized CDN);
o dCDN和uCDN相互授权（以确保它们向授权CDN发送/接收CDNI重定向消息）；
o CDNI Redirection interface messages to be transmitted with confidentiality; and
o 要保密传输的CDNI重定向接口消息；和
o The integrity of the CDNI Redirection interface messages to be protected during the exchange.
o 交换期间要保护的CDNI重定向接口消息的完整性。
In an environment where any such protection is required, mutually authenticated encrypted transport MUST be used to ensure confidentiality of the redirection information; to do so, TLS MUST be used (including authentication of the remote end) by the server side (dCDN) and the client side (uCDN) of the CDNI Redirection interface.
在需要任何此类保护的环境中，必须使用相互认证的加密传输来确保重定向信息的机密性；为此，CDNI重定向接口的服务器端（dCDN）和客户端（uCDN）必须使用TLS（包括远程端的身份验证）。
When TLS is used, the general TLS usage guidance in [RFC7525] MUST be followed.
使用TLS时，必须遵守[RFC7525]中的一般TLS使用指南。
Information passed over the RI ought to be considered personal and sensitive. In particular, parts of a User Agent's original request, most notably the UA's IP address and requested URI, are transmitted over the RI to the dCDN. The use of mutually authenticated TLS, as described in the previous section, prevents any other party than the authorized dCDN from gaining access to this information.
通过国际扶轮传递的信息应该被认为是个人的和敏感的。特别地，用户代理的原始请求的一部分，最显著的是UA的IP地址和请求的URI，通过RI传输到dCDN。如前一节所述，使用相互认证的TLS会阻止授权dCDN以外的任何其他方访问此信息。
Regardless of whether the uCDN and dCDN use the RI, a successful redirect from a uCDN to a dCDN will make that dCDN aware of the UA's IP address. As such, the fact that this information is transmitted across the RI does not allow the dCDN to learn new information. On the other hand, if a uCDN uses the RI to check with multiple candidate dCDNs, those candidates that do not end up getting redirected to do obtain information regarding end-user IP addresses and requested URIs that they would not have if the RI not been used.
无论uCDN和dCDN是否使用RI，从uCDN成功重定向到dCDN都将使该dCDN知道UA的IP地址。因此，该信息通过RI传输的事实不允许dCDN学习新信息。另一方面，如果uCDN使用RI与多个候选DCDN进行检查，则那些最终未被重定向的候选将获得有关最终用户IP地址和请求的URI的信息，这些信息在未使用RI的情况下是不会有的。
While it is technically possible to mask some information in the RI Request, such as the last bits of the UA IP address, it is important to note that this will reduce the effectiveness of the RI in certain cases. CDN deployments need to strike a balance between end-user privacy and the features impacted by such masking. This balance is likely to vary from one deployment to another. As an example, when the UA and its DNS resolver is behind a Carrier-grade NAT, and the RI is used to find an appropriate delivery node behind the same NAT, the full IP address might be necessary. Another potential issue when using IP anonymization is that it is no longer possible to correlate an RI Request with a subsequent UA request.
虽然在技术上可以屏蔽RI请求中的某些信息，例如UA IP地址的最后一位，但需要注意的是，在某些情况下，这将降低RI的有效性。CDN部署需要在最终用户隐私和受此类屏蔽影响的功能之间取得平衡。这种平衡可能因部署而异。例如，当UA及其DNS解析器位于载波级NAT之后，并且RI用于在同一NAT之后查找适当的传递节点时，可能需要完整的IP地址。使用IP匿名化时的另一个潜在问题是，不再可能将RI请求与后续UA请求关联起来。
IANA has registered the following two new Payload Types in the "Content Delivery Network Interconnection (CDNI) Parameters" registry for use with the application/cdni MIME media type.
IANA已在“内容交付网络互连（CDNI）参数”注册表中注册了以下两种新的有效负载类型，以便与应用程序/CDNI MIME媒体类型一起使用。
+----------------------+---------------+
| Payload Type | Specification |
+----------------------+---------------+
| redirection-request | RFC 7975 |
| | |
| redirection-response | RFC 7975 |
+----------------------+---------------+
+----------------------+---------------+
| Payload Type | Specification |
+----------------------+---------------+
| redirection-request | RFC 7975 |
| | |
| redirection-response | RFC 7975 |
+----------------------+---------------+
Table 9
表9
Purpose: The purpose of this payload type is to distinguish RI request messages.
目的：此有效负载类型的目的是区分RI请求消息。
Interface: RI
接口：RI
Encoding: See Section 4.4.1 and Section 4.5.1
编码：见第4.4.1节和第4.5.1节
Purpose: The purpose of this payload type is to distinguish RI response messages.
目的：此有效负载类型的目的是区分RI响应消息。
Interface: RI
接口：RI
Encoding: See Section 4.4.2 and Section 4.5.2
编码：见第4.4.2节和第4.5.2节
IANA has created a new "CDNI RI Error response code" subregistry within the "Content Delivery Network Interconnection (CDNI) Parameters" registry. The "CDNI RI Error response code" namespace defines the valid values for the error-code key in RI error responses. The CDNI RI Error response code MUST be a three-digit integer.
IANA在“内容交付网络互连（CDNI）参数”注册表中创建了一个新的“CDNI RI错误响应代码”子区。“CDNI RI错误响应代码”命名空间定义RI错误响应中错误代码键的有效值。CDNI RI错误响应代码必须为三位整数。
Additions to the "RI Error response registry" will be made via "Specification Required" as defined in [RFC5226].
将通过[RFC5226]中定义的“所需规范”对“RI错误响应注册表”进行添加。
The Designated Expert will verify that new error-code registrations do not duplicate existing error-code definitions (in name or functionality), ensure that the new error-code is in accordance with the error classes defined in Section 4.7 of this document, prevent gratuitous additions to the namespace, and prevent any additions to the namespace that would impair the interoperability of CDNI implementations.
指定专家将验证新错误代码注册不会与现有错误代码定义（在名称或功能上）重复，确保新错误代码符合本文件第4.7节中定义的错误类别，防止对名称空间进行无端添加，并防止对名称空间的任何添加会损害CDNI实现的互操作性。
New registrations are required to provide the following information:
新注册需要提供以下信息：
Code: A three-digit numeric error-code, in accordance with the error classes defined in Section 4.7 of this document.
代码：三位数字错误代码，符合本文件第4.7节中定义的错误类别。
Reason: A string that provides further information related to the error that will be included in the JSON error dictionary with the 'reason'-key. Depending on the error-code semantics, the value of this field may be determined dynamically. In that case, the registration should set this value to '<reason>' and define its semantics in the description field.
原因：一个字符串，提供与错误相关的进一步信息，该错误将包含在JSON错误字典中，并带有'Reason'-键。根据错误代码语义，可以动态确定此字段的值。在这种情况下，注册应将该值设置为“<reason>”，并在描述字段中定义其语义。
Description: A brief description of the error-code semantics.
描述：错误代码语义的简要描述。
Specification: Reference to the specification that defines the error-code in more detail.
规范：参考更详细地定义错误代码的规范。
The entries in Table 8 are registered by this document, with the value of the 'Specification' field set to RFC 7975 (this document).
表8中的条目由本文件登记，“规范”字段的值设置为RFC 7975（本文件）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 5952，DOI 10.17487/RFC5952，2010年8月<http://www.rfc-editor.org/info/rfc5952>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <http://www.rfc-editor.org/info/rfc6895>.
[RFC6895]Eastlake 3rd，D.，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 6895，DOI 10.17487/RFC6895，2013年4月<http://www.rfc-editor.org/info/rfc6895>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <http://www.rfc-editor.org/info/rfc7493>.
[RFC7493]Bray，T.，Ed.，“I-JSON消息格式”，RFC 7493，DOI 10.17487/RFC7493，2015年3月<http://www.rfc-editor.org/info/rfc7493>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, DOI 10.17487/RFC6707, September 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6707]Niven Jenkins，B.，Le Faucheur，F.，和N.Bitar，“内容分发网络互连（CDNI）问题声明”，RFC 6707，DOI 10.17487/RFC6707，2012年9月<http://www.rfc-editor.org/info/rfc6707>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<http://www.rfc-editor.org/info/rfc5890>.
[RTMP] Adobe Systems Incorporated, "Real-Time Messaging Protocol (RTMP) specification", December 2012, <http://www.adobe.com/go/spec_rtmp>.
[RTMP]Adobe Systems Incorporated，“实时消息传递协议（RTMP）规范”，2012年12月<http://www.adobe.com/go/spec_rtmp>.
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, <http://www.rfc-editor.org/info/rfc7337>.
[RFC7337]Leung，K.，Ed.和Y.Lee，Ed.，“内容分发网络互连（CDNI）要求”，RFC 7337，DOI 10.17487/RFC7337，2014年8月<http://www.rfc-editor.org/info/rfc7337>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7336]Peterson，L.，Davie，B.，和R.van Brandenburg，编辑，“内容分发网络互连框架（CDNI）”，RFC 7336，DOI 10.17487/RFC7336，2014年8月<http://www.rfc-editor.org/info/rfc7336>.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, <http://www.rfc-editor.org/info/rfc7736>.
[RFC7736]马，K，“内容交付网络互连（CDNI）媒体类型注册”，RFC 7736，DOI 10.17487/RFC7736，2015年12月<http://www.rfc-editor.org/info/rfc7736>.
Acknowledgements
致谢
The authors would like to thank Taesang Choi, Francois Le Faucheur, Matt Miller, Scott Wainner, and Kevin J. Ma for their valuable comments and input to this document.
作者感谢蔡泰生、弗朗索瓦·勒·福彻、马特·米勒、斯科特·韦纳和凯文·J·马对本文件的宝贵评论和投入。
Contributors
贡献者
The following persons have participated as co-authors to this document:
以下人员作为本文件的共同作者参与了本文件：
Wang Danhua Huawei Email: wangdanhua@huawei.com
王丹华华为邮箱：wangdanhua@huawei.com
He Xiaoyan Huawei Email: hexiaoyan@huawei.com
何晓燕华为邮箱：hexiaoyan@huawei.com
Ge Chen China Telecom Email: cheng@gsta.com
Ge Chen中国电信电子邮件：cheng@gsta.com
Ni Wei China Mobile Email: niwei@chinamobile.com
倪伟中国移动邮箱：niwei@chinamobile.com
Yunfei Zhang Email: hishigh@gmail.com
张云飞电邮：hishigh@gmail.com
Spencer Dawkins Huawei Email: spencer@wonderhamster.org
斯宾塞·道金斯华为电子邮件：spencer@wonderhamster.org
Authors' Addresses
作者地址
Ben Niven-Jenkins (editor) Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom
Ben Niven Jenkins（编辑）诺基亚3 Ely Road Milton，剑桥CB24 6DD英国
Email: ben.niven-jenkins@nokia.com
Email: ben.niven-jenkins@nokia.com
Ray van Brandenburg (editor) TNO Anna van Buerenplein 1 The Hague 2595DA The Netherlands
Ray van Brandenburg（编辑）TNO Anna van Buerenplein 1海牙2595DA荷兰
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl