[译][草案] HTTP “带外”内容编码
前言
这篇译文其实是高级计网课的作业，教授要求在 IETF 上找一篇尚未成为 RFC、也就是还处于草案状态的文档翻译一下。于是笔者随便搜了篇 HTTP 协议相关的文档。翻译完毕后感觉还是有一些收获的。这篇文档主要描述了一种新的内容编码格式——out-of-band（文中译为带外，但是我很不喜欢这个翻译，如有更合适的译词欢迎指正），用于描述包含客户端请求资源的辅助服务器的地址。此举可帮助源服务器建立“盲缓存”机制，将内容的传递安全地委派给辅助服务器，该辅助服务器可能在网络拓扑层次上来说“更接近”客户端。感兴趣的同学可以继续往下查看。
Network Working Group
Internet-Draft
Intended status: Standards Track
Expires: May 3, 2017
October 30, 2016
J. Reschke greenbytes S. Loreto Ericsson
“带外” HTTP 内容编码
draft-reschke-http-oob-encoding-09
摘要
本文档描述了一种超文本传输协议（HTTP）的内容编码，其可用于描述包含有效负载的辅助资源的位置。
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
3. 'Out-Of-Band' Content Coding . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Processing Steps . . . . . . . . . . . . . . . . . . . . . 6
3.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4.1. Basic Example . . . . . . . . . . . . . . . . . . . . 7
3.4.2. Example for an attempt to use 'out-of-band' cross-origin . . . . . . . . . . . . 9
3.4.3. Example involving an encrypted resource . . . . . . . 9
3.4.4. Relation to Content Negotiation . . . . . . . . . . . 11
4. Content Codings and Range Requests . . . . . . . . . . . . . . 12
5. Feature Discovery . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.1. Content Modifications . . . . . . . . . . . . . . . . . . 13
6.2. Content Stealing . . . . . . . . . . . . . . . . . . . . . 13
6.3. Use in Requests . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Content Coding: out-of-band . . . . . . . . . . . . . . . 14
7.2. Internet Media Type: application/oob-stream . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Problem Reporting . . . . . . . . . . . . . . . . . . 17
A.1. Server Not Reachable . . . . . . . . . . . . . . . . . . . 18
A.2. Resource Not Found . . . . . . . . . . . . . . . . . . . . 18
A.3. Payload Unusable . . . . . . . . . . . . . . . . . . . . . 18
A.4. TLS Handshake Failure . . . . . . . . . . . . . . . . . . 18
A.5. Example For Problem Reporting . . . . . . . . . . . . . . 18
Appendix B. Alternatives, or: why not a new Status Code? . . . . 19
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 19
C.1. Accessing the Secondary Resource Too Early . . . . . . . . 19
C.2. Resource maps . . . . . . . . . . . . . . . . . . . . . . 20
C.3. Fragmenting . . . . . . . . . . . . . . . . . . . . . . . 20
C.4. Relation to Content Encryption . . . . . . . . . . . . . . 21
C.5. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 21
C.6. Controlling Transmission Of Various Request Header Fields . . . . . . . . . . . . . 21
Appendix D. Change Log (to be removed by RFC Editor before publication) . . . . . . . . . . 22
D.1. Changes since draft-reschke-http-oob-encoding-00 . . . . . 22
D.2. Changes since draft-reschke-http-oob-encoding-01 . . . . . 22
D.3. Changes since draft-reschke-http-oob-encoding-02 . . . . . 22
D.4. Changes since draft-reschke-http-oob-encoding-03 . . . . . 22
D.5. Changes since draft-reschke-http-oob-encoding-04 . . . . . 22
D.6. Changes since draft-reschke-http-oob-encoding-05 . . . . . 23
D.7. Changes since draft-reschke-http-oob-encoding-06 . . . . . 23
D.8. Changes since draft-reschke-http-oob-encoding-07 . . . . . 23
D.9. Changes since draft-reschke-http-oob-encoding-08 . . . . . 23
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 241. 介绍
本文档描述了超文本传输协议（HTTP）的内容编码（[RFC7231] 的第 3.1.2.1 节），其可用于描述包含有效负载辅助资源的位置。
此内容编码的主要用例是使得源服务器将内容的传递安全地委派给辅助服务器，该服务器可能“更接近”客户端（相对于网络拓扑上来说）和/或能够缓存内容（[SCD]）并加密内容（[ENCRYPTENC]）。
2. 符号约定
该文档中的关键词“MUST”，“MUST NOT”，“REQUIRED”，“SHALL”，“SHALL NOT”，“SHOULD”，“SHOULD NOT”，“RECOMMENDED”，“MAY”和“OPTIONAL”应按 [RFC2119] 中所述进行解释。
本文重用基本 HTTP 规范，即 [RFC7230] 的第 2 节和 [RFC7231] 中的第 3 节中使用的术语。
3. “带外”内容编码
3.1 概述
带外内容编码用于指导接收者从一个辅助资源比如公共缓存处检索实际的消息表示（参见[RFC7231] 的第 3 节）
- 客户端发送一个请求
- 接收到的响应指定“带外”内容编码；该响应的负载包含了额外的元数据，以及辅助资源的位置信息
- 客户端向辅助资源发送 GET 请求（通常也是通过 HTTP(s)）
- 辅助服务器提供有效负载资源
- 客户端将以上的表示和从主要资源处获得的表示元数据结合起来
客户端 辅助服务器 源服务器
发送带有 Accept-Encoding: out-of-band 头的 GET 请求
(1) |---------------------------------------------------------\
状态码 200 以及返回头 Content-Coding: out-of-band |
(2) <---------------------------------------------------------/
向辅助服务器发送 GET 请求
(3) |---------------------------\
有效负载 |
(4) <---------------------------/
(5)
客户端将第（4）步接收到的 有效负载和第（2）步接收到的元数据结合起来。3.2 定义
该内容编码的名称为“带外”。
有效负载格式为 JavaScript 对象标记（即 JSON，参见 [RFC7159]）,用于描述一个描述辅助资源信息的对象；目前仅仅定义了一个成员：
“sr”：一个必需的 JSON 对象数组。每个对象包括一个名为“r”的成员，该成员用于描述一个辅助资源的信息，其值为包含一个对该辅助资源的 URI 引用（参见 [RFC3986]的 4.1 小节）的字符串（作为相对引用的 URI 引用会根据主资源的 URI 来解析）。
有效负载格式使用数组以保证源服务器可以指定多个辅助资源地址。数组的排序反映了源服务器对待辅助资源的优先级（如果存在的话）。优先级最高的辅助资源位置将排在第一位。客户端在接收到包含多个辅助资源位置的响应时可以自由选择使用哪一个辅助资源。
在某些情况下，源服务器可能想指定一个“回退 URI”；标识一个由源服务器自身提供的辅助资源，但是除此以外和其他“常规”辅助资源完全相等。任何由源服务器作为主机的辅助资源都可以作为一个“回退”；源服务器通常将这些辅助资源列在“sr”数组的最后，以使它们只有在没有其他选择时才会被客户端使用。
新的规范可以定义新的可选成员字段，因此客户端必须忽略未知字段。此外，新的规范还可以为“sr”数组定义新的对象格式；但是，除非语义上与以上定义的部分相兼容，否则新规范不得使用名为“r”的成员。
扩展的规范必须更新此规范。
3.3 处理步骤
在接收到一个“带外”编码的响应时，客户端首先需要获得辅助资源的呈现。这是使用 HTTP 的 GET 请求实现的（独立于原始请求方法）。
为了防止任何信息泄漏，对辅助资源的 GET 请求必须只包含由源服务器或者辅助服务器自身提供的信息，即 HTTP 认证凭证（[RFC7235]）和 cookie（[RFC6265]）。
此外，该请求必须包括“Origin”报头字段，用于指示原始资源的来源（参见 [RFC6454]的第 7 节）。 辅助服务器必须验证该特定源是经过授权的，才可以检索给定的有效载荷（或以其他方式返回适当的 4xx 状态码）。
除此之外，辅助服务器的响应必须包括一个“Content-Type”报头字段，用于指定一种叫做“application / oob-stream”的互连网媒体类型。 客户端必须校验此媒体类型。如果未指定媒体类型，或其并不匹配此值，则中止带外处理。
在接收到辅助资源的有效负载后，客户端通过以下方式重构原始消息：
- 通过去除所有传输和内容编码来解封装 HTTP 消息
- 替换/设置来自主响应的所有响应头字段，除了 Content-Length，Transfer-Encoding 以及 Content-Encoding 等帧相关的信息。
如果客户端无法检索辅助资源（无法访问主机，非 2xx 响应状态代码，有效载荷完整性校验失败等），它可以选择替代的辅助资源（如果有指定），尝试回退 URI（如果给定），或者简单地重新向源服务器发起请求，但在 Accept-Encoding 请求头字段中不包含 “out-of-band”。在后一种情况下，将请求辅助资源时遇到的问题通知到源服务器是有用的。详情见附录A。
注意，尽管这种机制导致引入了外部内容，但是它不会影响重构消息的应用程序级的安全属性，比如它的 web 源（[RFC6454]）。
辅助资源的响应的缓存能力不会影响重构的响应消息的缓存能力，重构的响应消息的缓存能力与与原始服务器的响应相同。
“带外”编码的使用在某些方面类似于 HTTP 重定向（参见 [RFC7231] 第 6.4 节），比如它可能导致循环。除非遇到 HTTP 重定向，否则客户端是完全处于控制的：它不需要在向辅助资源的请求中宣称支持“带外”编码。或者，它可以像在 HTTP 重定向情况下一样保护自己——通过限制其支持的间接寻址的数量。
注意，因为服务器的响应取决于请求的 Accept-Encoding 头字段，响应通常需要宣告其上的变化。详情参见 [RFC7231] 的 7.1.4 节和 [RFC7232] 的 2.3 节。
3.4 示例
3.4.1 基本示例
客户端向位于 https://www.example.com/test 的主资源发送请求：
GET /test HTTP/1.1 Host: www.example.com Accept-Encoding: gzip, out-of-band
响应：
HTTP/1.1 200 OK
Date: Thu, 14 May 2015 18:52:00 GMT
Content-Type: text/plain
Cache-Control: max-age=10, public
Content-Encoding: out-of-band
Content-Length: 165
Vary: Accept-Encoding
{
"sr": [
{ "r" :
"http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"},
{ "r" :
"/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"}
]
}（注意到 Content-Type 头字段描述了辅助资源的媒体类型，同时源服务器提供了回退 URI）
客户端向辅助资源发送请求：
GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1 Host: example.net Origin: https://www.example.com
响应:
HTTP/1.1 200 OK
Date: Thu, 14 May 2015 18:52:10 GMT
Cache-Control: private
Content-Type: application/oob-stream
Content-Length: 15
Hello, world.在重组头字段后，最终的消息如下：
HTTP/1.1 200 OK
Date: Thu, 14 May 2015 18:52:00 GMT
Content-Length: 15
Cache-Control: max-age=10, public
Content-Type: text/plain
Hello, world.3.4.2 尝试跨域使用“带外”的示例
3.3 小节需要客户端在向辅助服务器发送的请求中包含一个“Origin”头字段。下面的例子展示了用于处理辅助资源的服务器将如何响应一个包含了“Origin”头字段的请求，同时该头字段标识了一个未经授权的源。
继续 3.4.1 小节中的例子，一个辅助服务器已被配置，其能够允许由“https://www.example.org”启动的请求：
客户端向辅助服务器发起的请求：
GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1 Host: example.net Origin: https://www.example.com
响应：
HTTP/1.1 403 Forbidden Date: Thu, 14 May 2015 18:52:10 GMT
注意，缺少“Origin”头字段的请求将获得同以上请求一样的对待。
3.4.3 含有加密资源的示例
给定来自 [ENCRYPTENC] 5.1 小节的示例 HTTP 消息，主要资源可以使用“带外”编码来指定辅助资源的位置以及解密有效载荷所需的“Crypto-Key”报头字段的内容：
响应：
HTTP/1.1 200 OK
Date: Thu, 14 May 2015 18:52:00 GMT
Content-Encoding: aesgcm, out-of-band
Content-Type: text/plain
Encryption: keyid="a1"; salt="vr0o6Uq3w_KDWeatc27mUg"
Crypto-Key: keyid="a1"; aesgcm="csPJEXBYA5U-Tal9EdJi-w"
Content-Length: 101
Vary: Accept-Encoding
{
"sr": [
{ "r" :
"http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"}
]
}（注意，Content-Type 头字段描述了辅助资源的表现形式）
辅助资源的响应：
HTTP/1.1 200 OK
Date: Thu, 14 May 2015 18:52:10 GMT
Content-Type: application/oob-stream
Content-Length: ...
VDeU0XxaJkOJDAxPl7h9JD5V8N43RorP7PfpPdZZQuwF
（这里负载体以 base64 的编码格式显示）解开所有内容编码后的最终消息形式为：
HTTP/1.1 200 OK
Date: Thu, 14 May 2015 18:52:00 GMT
Content-Length: 15
Content-Type: text/plain
I am the walrus注意：在这种情况下，解码“aesgcm”需要先处理响应。如果在请求中“aesgcm”没有被列为可接受的内容编码，源服务器将不能使用“带外”机制。
“带外”编码的使用是“积极内容协商”的一个实例，该概念在 [RFC7231] 的 3.4 小节被定义。
然而，这并不排除将其与其他内容组合编码。 举个例子，与“gzip”内容编码（参见 [RFC7230] 的第 4.2.3 节）可能组合的情形被描述如下：
实例1： 主资源不支持“gzip”编码
在这种情况下，主资源的响应将永远不会在 Content-Encoding 头字段中包含“gzip”。但是辅助资源可能支持它，在这种情况下客户端可以通过在向辅助资源的请求中包含“Accept-Encoding：gzip”来协商压缩。实例2：主资源支持“gzip”编码
这里，原始服务器实际上将使用两个不同的辅助资源，其中之一是经过 gzip 压缩的。 例如——回到 3.4.1 节的第一个例子——它可能回复如下：HTTP/1.1 200 OK Date: Thu, 14 May 2015 18:52:00 GMT Content-Type: text/plain Cache-Control: max-age=10, public Content-Encoding: gzip, out-of-band Content-Length: 165 Vary: Accept-Encoding { "sr": [ { "r" : "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a01"}, { "r" : "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a01"} ] }这意味着辅助资源的有效负载已经经过 gzip 压缩。
注意：原始服务器也可以将 gzip 压缩应用于带外有效载荷，在这种情况下内容编码字段的值将变为：“gzip，out-of-band，gzip”。
4. 内容编码和范围请求
内容编码的组合（参见 [RFC7231] 的第 3.1.2 节与范围请求（[RFC7233]）可以导致令人惊讶的结果，因为应用范围请求在应用内容编码之后发生。
因此，对于从位置 100000 字节处开始的视频的请求：
GET /test.mp4 HTTP/1.1 Host: www.example.com Range: bytes=100000- Accept-Encoding: identity
……成功的响应将使用 206 状态码（部分内容），并且包含一个内容为从位置 100000 开始的八位字节的有效负载。
HTTP/1.1 206 Partial Content Date: Thu, 08 September 2015 16:49:00 GMT Content-Type: video/mp4 Content-Length: 134567 Content-Range: bytes 100000-234566/234567 (二进制数据)
但是，如果请求允许使用“带外”编码：
GET /test.mp4 HTTP/1.1
Host: www.example.com
Range: bytes=100000-
Accept-Encoding: out-of-band……服务器可能会返回一个空的负载（如果经过带外编码的响应体小于 100000 字节，而通常情况下就是这样的）。
因此，为了避免不必要的网络流量，服务器“不应该”将范围请求处理应用于使用带外内容编码的响应（或者，换句话说，忽略“Range”请求头字段）。
5. 功能探索
新的内容编码很容易进行部署，因为客户端可以使用“Accept-Encoding”头字段（参见 [RFC7231]的 5.3.4 小节）来标记其支持哪些内容编码。
6. 安全事项
6.1 内容修改
本规范没有定义如何验证从辅助资源处获得的有效负载是否确实是源服务器期望获得的。不过内容签名可以解决这个问题（见[CONTENTSIG]和[MICE]）。
6.2 内容窃取
“带外”内容编码可以用于规避用户代理的同源原则策略（参见 [RFC6454] 第 3 节）：知道辅助资源的 URI 攻击站点将使用“带外”编码来欺骗用户代理读取辅助资源的内容，然后，由于这种编码的安全属性，这种欺骗行为将被识别成好像其产生于源地址。
这种情况可以这样处理：客户端要求包括“Origin”头字段，同时服务端需要验证收到的请求是由经过验证的源发送的。此外，辅助服务器的响应的媒体类型对“application / oob-stream”的限制能够保护未实现此规范的“正常”服务器上的现有内容。
注：与“跨源资源共享”协议（[CORS]）的相似是有意为之的。
对辅助资源的有效内容进行加密（[ENCRYPTENC]）是一个额外的有效措施。
6.3 在请求中的使用
一般来说，内容编码可以用于请求和响应。 这个特定的内容编码已经被设计用于响应。 当请求中也支持时，它会创建一个新的攻击方向，接收服务器可以被欺骗，然后返回客户端可能原本无法访问的内容（例如由防火墙保护的 HTTP 资源）。
7. IANA 注意事项
7.1 Content Coding: out-of-band
网址为http://www.iana.org/assignments/http-parameters的 IANA（互联网号码分配局） 的“HTTP 内容编码注册”需要用以下的注册内容来更新：
Name: out-of-band Description: Payload needs to be retrieved from a secondary resource Reference: Section 3 of this document
7.2 Internet Media Type: application/oob-stream
IANA 在http://www.iana.org/assignments/media-types上维护互联网媒体类型 [BCP13] 的注册。
此文档用作互联网媒体类型“application / oob-stream” 的规范。 以下是在 IANA 要注册的内容：
Type name: application Subtype name: oob-stream Required parameters: N/A Optional parameters: N/A Encoding considerations: always "binary" Security considerations: see Section 6 Interoperability considerations: N/A Published specification: This specification (see Section 7.2). Applications that use this media type: HTTP servers for secondary resources as defined by this specification. Fragment identifier considerations: N/A Additional information: Magic number(s): N/A Deprecated alias names for this type: N/A File extension(s): N/A Macintosh file type code(s): N/A Person and email address to contact for further information: See Authors' Addresses section. Intended usage: COMMON Restrictions on usage: N/A Author: See Authors' Addresses section. Change controller: IESG
8. 参考文献
8.1 规范性引用文件
[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>.
[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>.
[RFC5988]
Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/
RFC5988, October 2010,
<http://www.rfc-editor.org/info/rfc5988>.
[RFC6265]
Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.
[RFC7159]
Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[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>.
[RFC7231]
Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content",
RFC 7231, DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC7235]
Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication",
RFC 7235, DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>.
[BCP13]
Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013,
<http://www.rfc-editor.org/info/bcp13>.
[CONTENTSIG]
Thomson, M., "Content-Signature Header Field for HTTP",
draft-thomson-http-content-signature-00 (work in
progress), July 2015.
[CORS]
van Kesteren, A., "Cross-Origin Resource Sharing", W3C
Recommendation REC-cors-20140116, January 2014,
<http://www.w3.org/TR/2014/REC-cors-20140116/>.
Latest version available at
<http://www.w3.org/TR/cors/>.
[ENCRYPTENC]
Thomson, M., "Encrypted Content-Encoding for HTTP",
draft-ietf-httpbis-encryption-encoding-03 (work in
progress), October 2016.
[MICE]
Thomson, M., "Merkle Integrity Content Encoding",
draft-thomson-http-mice-02 (work in progress),
October 2016.
[RFC2017]
Freed, N. and K. Moore, "Definition of the URL MIME
External-Body Access-Type", RFC 2017, DOI 10.17487/
RFC2017, October 1996,
<http://www.rfc-editor.org/info/rfc2017>.
[RFC4483]
Burger, E., "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", RFC 4483,
DOI 10.17487/RFC4483, May 2006,
<http://www.rfc-editor.org/info/rfc4483>.
[RFC5246]
Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6454]
Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<http://www.rfc-editor.org/info/rfc6454>.
[RFC7232]
Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests",
RFC 7232, DOI 10.17487/RFC7232, June 2014,
<http://www.rfc-editor.org/info/rfc7232>.
[RFC7233]
Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014,
<http://www.rfc-editor.org/info/rfc7233>.
[SCD]
Thomson, M., Eriksson, G., and C. Holmberg, "An
Architecture for Secure Content Delegation using HTTP",
draft-thomson-http-scd-02 (work in progress),
October 2016.
URIs
[1] <mailto:[email protected]>
[2] <mailto:[email protected]?subject=subscribe>附录 A. 问题报告
[[erwip：这是一个错误报告机制的粗略建议。它够好吗？ 是否需要它？ 注意，Alt-Svc 没有这样的东西。]]
当客户端无法获取辅助资源时，通知源服务器该状况将是有用的。这可以通过添加一个“Link”报头字段（[RFC5988]）到后续发往源服务器的请求来实现。同时该头字段需要详细说明辅助资源的 URI 和失败原因。
定义以下链路扩展关系：
[[purl：需要注册 PURL（现在由 archive.org，FWIW 托管）]]
A.1 服务器不可达
当服务器不可达时使用。
链接关系：
http://purl.org/NET/linkrel/not-reachable
A.2 资源未发现
当服务器返回响应，但是目标不可获取时使用。
链接关系：
http://purl.org/NET/linkrel/resource-not-found
A.3 负载无法使用
当负责可以获取到，但是不可使用（例如，完整性校验失败）时使用。
链接关系：
http://purl.org/NET/linkrel/payload-unusable
A.4 TLS 握手失败
当 TLS 握手失败时使用（[RFC5246]）。
链接关系：
http://purl.org/NET/linkrel/tls-handshake-failure
A.5 问题报告的示例
拿 3.4.1 节客户端向主资源发起的请求为例，此时假设尝试获取辅助资源失败。
响应:
HTTP/1.1 404 Not Found Date: Thu, 08 September 2015 16:49:00 GMT Content-Type: text/plain Content-Length: 20 Resource Not Found
客户端重新向源服务器发起请求，请求中包括“Link”头字段，用于报告问题：
GET /test HTTP/1.1 Host: www.example.com Accept-Encoding: gzip, out-of-band Link: <http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00>;rel="http://purl.org/NET/linkrel/resource-not-found"
附录 B. 备选方案，或者：为什么不加一个新的状态码？
一种貌似合理的备选方法是在更高一级上实现这个功能，使用新的重定向状态码（参见 [RFC7231] 的 6.4 节）。然而，这将具有以下几个缺点：
- 服务器需要知道客户端是否能够理解新的状态码；这样一些额外的标记加入该协议将是必不可少的。
- 在重定向消息中，元数据的表现形式（[RFC7231]的 3.1 节），即“Content-Type”，适用于响应消息，而不适用于重定向到的资源。
- 使用内容编码的原始保留性质将丢失。
另一个选择是在媒体类型级别上使用类似“message/external-body”的某个类型来实现间接获取资源，该方法在 [RFC2017] 上定义并在 [RFC4483] 中被改进，在会话发起协议（SIP）中得到使用。但是这种方法具有与上面提到的状态码方法一样的大部分缺点。
附录 C. 开放议题
C.1 过早访问辅助资源
该协议的一个用例是使得系统可以启用“盲缓存”来提供辅助资源。这些缓存可能在需要时才填充,因此可能出现以下情况：无论填充缓存的机制是什么，当客户端命中该缓存的时候可能填充缓存的操作还没有完成（可能因为竞争条件，或者因为缓存位于一个不允许源服务器推送内容至其上的中间件的后面）。
在这种特殊情况下，如果客户端能够“肩扛”主资源的回退 URI，给予辅助服务器一种可以获得有效载荷本身的方法，这将会是非常有用的。这些信息可以在另一个叫做“Link”的头字段中提供：
GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1 Host: example.net Link: <http://example.com/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00>;rel="http://purl.org/NET/linkrel/fallback-resource"
（继续 3.4.1 节的例子）
C.2 资源映射
当“带外”编码作为缓存解决方案的一部分时，到源服务器的额外往返可能产生重要的性能问题；特别是当许多小资源需要加载时（例如脚本，图像或视频片段）。在这样的情况下，源服务器提供一个“资源映射”，允许这些被映射的资源跳过到源服务器的往返行程将会非常有用。 发送资源映射的合理方式可以是：
- 作为在“带外”编码 JSON 有效载荷中的扩展，或者
- 作为由“Link”响应头字段标识的单独资源。
本规范没有定义格式，也没有定义机制来传输该映射，但它是一些使用“带外”编码的规范将要做的。
C.3 分段
将原始资源的有效载荷分割为片段，每个片段映射到不同的辅助资源处将是很有趣的。 这将允许不在单个缓存中存储一个资源的所有有效载荷。因此
- 分配负载，
- 使用不同的方式来缓存资源的不同部分（例如只分配一个长视频的开始几分钟），或
- 获取资源的特定部分（类似于字节范围请求），或
- 隐藏来自辅助服务器的信息。
C.4 与内容加密的关系
现在该规范与[ENCRYPTENC]/[MICE]正交；也就是说，它可以用于诸如软件下载之类的公共内容。 然而，强制加密的缺乏影响了安全考虑。我们需要决定是否需要这种水平的独立性。
C.5 报告
这个规范已经定义了客户端在访问辅助资源失败时可以报告失败的钩子（参见附录 A）。
但是，如果还有办法报告以下的数据，将是有益的：
- 成功（缓存命中）率，和
- 到辅助服务器的带宽。
这可以通过使用新的服务端点和一个（JSON？）有效载荷格式来实现。
类似地，由辅助服务器使用的报告设施也可能是有用的。
C.6 控制各种请求报头字段的传输
默认情况下，客户端会将一些请求头字段例如“User-Agent“（或一些新定义的”Client Hints“）包含进他们向辅助服务器发送的请求。如果辅助服务器不执行任何内容协商，那么这些头字段实际上都没有用，所以在默认情况下禁止它们可能是一个减少识别的好主意。在这种情况下，我们可以允许源服务器选择发送它们其中的一部分。
附录 D 修改日志（在发布前将被 RFC 编辑者移除）
D.1. Changes since draft-reschke-http-oob-encoding-00
Mention media type approach.
Explain that clients can always fall back not to use oob when the secondary resource isn't available.
Add Vary response header field to examples and mention that it'll usually be needed (https://github.com/reschke/oobencoding/issues/6).
Experimentally add problem reporting using piggy-backed Link header fields (https://github.com/reschke/oobencoding/issues/7).
D.2. Changes since draft-reschke-http-oob-encoding-01
Updated ENCRYPTENC reference.
D.3. Changes since draft-reschke-http-oob-encoding-02
Add MICE reference.
Remove the ability of the secondary resource to contain anything but the payload (https://github.com/reschke/oobencoding/issues/11).
Changed JSON payload to be an object containing an array of URIs plus additional members. Specify "fallback" as one of these additional members, and update Appendix C.1 accordingly).
Discuss extensibility a bit.
D.4. Changes since draft-reschke-http-oob-encoding-03
Mention "Content Stealing" thread.
Mention padding.
D.5. Changes since draft-reschke-http-oob-encoding-04
Reduce information leakage by disallowing ambient authority information being sent to the secondary resource. Require "Origin" to be included in request to secondary resource, and require secondary server to check it.
Mention "Origin" + server check on secondary resource as defense to content stealing.
Update ENCRYPTENC reference, add SCD reference.
Mention fragmentation feature.
Discuss relation with range requests.
D.6. Changes since draft-reschke-http-oob-encoding-05
Remove redundant Cache-Control: private from one example response (the response payload is encrypted anyway).
Mention looping.
Remove 'metadata' payload element.
Align with changes in ENCRYPTENC spec.
Fix incorrect statement about what kind of cookies/credentials can be used in the request to the secondary resource.
Rename "URIs" to "sr" ("secondary resources") and treat the fallback URI like a regular secondary resource.
Mention reporting protocol ideas.
D.7. Changes since draft-reschke-http-oob-encoding-06
Changed the link relation name to the fallback resource from "primary" to "fallback". Added link relation for reporting TLS handshake failures.
Added an example about the interaction with 'gzip' coding.
Update ENCRYPTENC, MICE, and SCD references.
D.8. Changes since draft-reschke-http-oob-encoding-07
Restrict the valid media types for the response of the secondary server to "application/oob-stream".
Changed JSON format to allow annotation (optional flags) and entirely new types of entries.
D.9. Changes since draft-reschke-http-oob-encoding-08
Moved error reporting into appendix (because it's optional and we're not sure about the utility of it). See https://github.com/EricssonResearch/Blind-Cache-Drafts/issues/4.
Updated references for ENCRYPTENC, MICE, and SCD.
Mention that we could suppress certain request header fields in the request to the secondary server.
附录 E 致谢
Thanks to Christer Holmberg, Daniel Lindstrom, Erik Nygren, Goran Eriksson, John Mattsson, Kevin Smith, Magnus Westerlund, Mark Nottingham, Martin Thomson, and Roland Zink for feedback on this document.
作者地址：
Julian F. Reschke
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
EMail: [email protected]
URI: http://greenbytes.de/tech/webdav/
Salvatore Loreto
Ericsson
Torshamnsgatan 21
Stochholm 16483
Sweden
EMail: [email protected]