前言
這篇譯文其實是高階計網課的作業，教授要求在 IETF 上找一篇尚未成為 RFC、也就是還處於草案狀態的文件翻譯一下。於是筆者隨便搜了篇 HTTP 協議相關的文件。翻譯完畢後感覺還是有一些收穫的。這篇文件主要描述了一種新的內容編碼格式——out-of-band（文中譯為帶外，但是我很不喜歡這個翻譯，如有更合適的譯詞歡迎指正），用於描述包含客戶端請求資源的輔助伺服器的地址。此舉可幫助源伺服器建立“盲快取”機制，將內容的傳遞安全地委派給輔助伺服器，該輔助伺服器可能在網路拓撲層次上來說“更接近”客戶端。感興趣的同學可以繼續往下檢視。文章同步釋出於我的部落格：sunflower->FE，歡迎關注~
以下為草案正文部分。
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 . . . . . . . . . . . . . . . . . . 24複製程式碼1. 介紹
本文件描述了超文字傳輸協議（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 基本示例
客戶端向位於 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 小節中的例子，一個輔助伺服器已被配置，其能夠允許由“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
網址為www.iana.org/assignments…的 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 在www.iana.org/assignments…上維護網際網路媒體型別 [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:ietf-http-wg@w3.org>
[2] <mailto:ietf-http-wg-request@w3.org?subject=subscribe>複製程式碼附錄 A. 問題報告
[[erwip：這是一個錯誤報告機制的粗略建議。它夠好嗎？ 是否需要它？ 注意，Alt-Svc 沒有這樣的東西。]]
當客戶端無法獲取輔助資源時，通知源伺服器該狀況將是有用的。這可以通過新增一個“Link”報頭欄位（[RFC5988]）到後續發往源伺服器的請求來實現。同時該頭欄位需要詳細說明輔助資源的 URI 和失敗原因。
定義以下鏈路擴充套件關係：
[[purl：需要註冊 PURL（現在由 archive.org，FWIW 託管）]]
A.1 伺服器不可達
當伺服器不可達時使用。
連結關係：
purl.org/NET/linkrel…
A.2 資源未發現
當伺服器返回響應，但是目標不可獲取時使用。
連結關係：
purl.org/NET/linkrel…
A.3 負載無法使用
當負責可以獲取到，但是不可使用（例如，完整性校驗失敗）時使用。
連結關係：
purl.org/NET/linkrel…
A.4 TLS 握手失敗
當 TLS 握手失敗時使用（[RFC5246]）。
連結關係：
purl.org/NET/linkrel…
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 (github.com/reschke/oob…).
Experimentally add problem reporting using piggy-backed Link header fields (github.com/reschke/oob…).
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 (github.com/reschke/oob…).
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 github.com/EricssonRes….
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: julian.reschke@greenbytes.de
URI: greenbytes.de/tech/webdav…
Salvatore Loreto
Ericsson
Torshamnsgatan 21
Stochholm 16483
Sweden
EMail: salvatore.loreto@ericsson.com