[譯][草案] HTTP 「帶外」內容編碼

時間 2019-11-29

原文原文鏈接

前言javascript

這篇譯文實際上是高級計網課的做業，教授要求在 IETF 上找一篇還沒有成爲 RFC、也就是還處於草案狀態的文檔翻譯一下。因而筆者隨便搜了篇 HTTP 協議相關的文檔。翻譯完畢後感受仍是有一些收穫的。這篇文檔主要描述了一種新的內容編碼格式——out-of-band（文中譯爲帶外，可是我很不喜歡這個翻譯，若有更合適的譯詞歡迎指正），用於描述包含客戶端請求資源的輔助服務器的地址。此舉可幫助源服務器創建「盲緩存」機制，將內容的傳遞安全地委派給輔助服務器，該輔助服務器可能在網絡拓撲層次上來講「更接近」客戶端。感興趣的同窗能夠繼續往下查看。文章同步發佈於個人博客：sunflower->FE，歡迎關注~css

如下爲草案正文部分。java

Network Working Group
Internet-Draft
Intended status: Standards Track
Expires: May 3, 2017
October 30, 2016
J. Reschke greenbytes S. Loreto Ericssongit

「帶外」 HTTP 內容編碼

draft-reschke-http-oob-encoding-09

摘要

本文檔描述了一種超文本傳輸協議（HTTP）的內容編碼，其可用於描述包含有效負載的輔助資源的位置。github

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 節），其可用於描述包含有效負載輔助資源的位置。web

此內容編碼的主要用例是使得源服務器將內容的傳遞安全地委派給第二個服務器，該服務器可能「更接近」客戶端（相對於網絡拓撲上來講）和/或可以緩存內容（[SCD]）並加密內容（[ENCRYPTENC]）。json

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