idnits 2.17.1 draft-reschke-http-oob-encoding-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2017) is 2602 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) == Outdated reference: A later version (-09) exists of draft-ietf-httpbis-encryption-encoding-08 == Outdated reference: A later version (-03) exists of draft-thomson-http-mice-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7232 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7233 (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Reschke 3 Internet-Draft greenbytes 4 Intended status: Standards Track S. Loreto 5 Expires: September 12, 2017 Ericsson 6 March 11, 2017 8 'Out-Of-Band' Content Coding for HTTP 9 draft-reschke-http-oob-encoding-11 11 Abstract 13 This document describes an Hypertext Transfer Protocol (HTTP) content 14 coding that can be used to describe the location of a secondary 15 resource that contains the payload. 17 Editorial Note (To be removed by RFC Editor before publication) 19 Distribution of this document is unlimited. Although this is not a 20 work item of the HTTPbis Working Group, comments should be sent to 21 the Hypertext Transfer Protocol (HTTP) mailing list at 22 ietf-http-wg@w3.org [1], which may be joined by sending a message 23 with subject "subscribe" to ietf-http-wg-request@w3.org [2]. 25 Discussions of the HTTPbis Working Group are archived at 26 . 28 XML versions, latest edits, and issue tracking for this document are 29 available from 30 and 31 . 33 The changes in this draft are summarized in Appendix D.11. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 12, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 70 3. 'Out-Of-Band' Content Coding . . . . . . . . . . . . . . . . . 4 71 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.3. Processing Steps . . . . . . . . . . . . . . . . . . . . . 6 74 3.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.4.1. Basic Example . . . . . . . . . . . . . . . . . . . . 7 76 3.4.2. Example for an attempt to use 'out-of-band' 77 cross-origin . . . . . . . . . . . . . . . . . . . . . 9 78 3.4.3. Example involving an encrypted resource . . . . . . . 9 79 3.4.4. Relation to Content Negotiation . . . . . . . . . . . 11 80 4. Content Codings and Range Requests . . . . . . . . . . . . . . 12 81 5. Feature Discovery . . . . . . . . . . . . . . . . . . . . . . 12 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 6.1. Content Modifications . . . . . . . . . . . . . . . . . . 13 84 6.2. Content Stealing . . . . . . . . . . . . . . . . . . . . . 13 85 6.3. Use in Requests . . . . . . . . . . . . . . . . . . . . . 13 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 7.1. Content Coding: out-of-band . . . . . . . . . . . . . . . 14 88 7.2. Internet Media Type: application/oob-stream . . . . . . . 14 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 91 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 92 Appendix A. Problem Reporting . . . . . . . . . . . . . . . . . . 17 93 A.1. Server Not Reachable . . . . . . . . . . . . . . . . . . . 18 94 A.2. Resource Not Found . . . . . . . . . . . . . . . . . . . . 18 95 A.3. Payload Unusable . . . . . . . . . . . . . . . . . . . . . 18 96 A.4. TLS Handshake Failure . . . . . . . . . . . . . . . . . . 18 97 A.5. Example For Problem Reporting . . . . . . . . . . . . . . 18 98 Appendix B. Alternatives, or: why not a new Status Code? . . . . 19 99 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 19 100 C.1. Accessing the Secondary Resource Too Early . . . . . . . . 20 101 C.2. Resource maps . . . . . . . . . . . . . . . . . . . . . . 20 102 C.3. Fragmenting . . . . . . . . . . . . . . . . . . . . . . . 20 103 C.4. Relation to Content Encryption . . . . . . . . . . . . . . 21 104 C.5. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 21 105 C.6. Controlling Transmission Of Various Request Header 106 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 Appendix D. Change Log (to be removed by RFC Editor before 108 publication) . . . . . . . . . . . . . . . . . . . . 22 109 D.1. Changes since draft-reschke-http-oob-encoding-00 . . . . . 22 110 D.2. Changes since draft-reschke-http-oob-encoding-01 . . . . . 22 111 D.3. Changes since draft-reschke-http-oob-encoding-02 . . . . . 22 112 D.4. Changes since draft-reschke-http-oob-encoding-03 . . . . . 22 113 D.5. Changes since draft-reschke-http-oob-encoding-04 . . . . . 23 114 D.6. Changes since draft-reschke-http-oob-encoding-05 . . . . . 23 115 D.7. Changes since draft-reschke-http-oob-encoding-06 . . . . . 23 116 D.8. Changes since draft-reschke-http-oob-encoding-07 . . . . . 24 117 D.9. Changes since draft-reschke-http-oob-encoding-08 . . . . . 24 118 D.10. Changes since draft-reschke-http-oob-encoding-09 . . . . . 24 119 D.11. Changes since draft-reschke-http-oob-encoding-10 . . . . . 24 120 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 24 122 1. Introduction 124 This document describes an Hypertext Transfer Protocol (HTTP) content 125 coding (Section 3.1.2.1 of [RFC7231]) that can be used to describe 126 the location of a secondary resource that contains the payload. 128 The primary use case for this content coding is to enable origin 129 servers to securely delegate the delivery of content to a secondary 130 server that might be "closer" to the client (with respect to network 131 topology) and/or able to cache content ([SCD]), leveraging content 132 encryption ([ENCRYPTENC]). 134 2. Notational Conventions 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 This document reuses terminology used in the base HTTP 141 specifications, namely Section 2 of [RFC7230] and Section 3 of 142 [RFC7231]. 144 3. 'Out-Of-Band' Content Coding 146 3.1. Overview 148 The 'Out-Of-Band' content coding is used to direct the recipient to 149 retrieve the actual message representation (Section 3 of [RFC7231]) 150 from a secondary resource, such as a public cache: 152 1. Client performs a request 154 2. Received response specifies the 'out-of-band' content coding; the 155 payload of the response contains additional meta data, plus the 156 location of the secondary resource 158 3. Client performs GET request on secondary resource (usually again 159 via HTTP(s)) 161 4. Secondary server provides payload 163 5. Client combines above representation with additional 164 representation metadata obtained from the primary resource 166 Client Secondary Server Origin Server 168 sends GET request with Accept-Encoding: out-of-band 169 (1) |---------------------------------------------------------\ 170 status 200 and Content-Coding: out-of-band | 171 (2) <---------------------------------------------------------/ 173 GET to secondary server 174 (3) |---------------------------\ 175 payload | 176 (4) <---------------------------/ 178 (5) 179 Client and combines payload received in (4) 180 with metadata received in (2). 182 3.2. Definitions 184 The name of the content coding is "out-of-band". 186 The payload format uses JavaScript Object Notation (JSON, [RFC7159]), 187 describing an object describing secondary resources; currently only 188 defining one member: 190 'sr' A REQUIRED array of JSON objects. 192 Objects having a member named 'r' describe a secondary resource, 193 with the member's string value containing a URI reference (Section 194 4.1 of [RFC3986]) of the secondary resource (URI references that 195 are relative references are resolved against the URI of the 196 primary resource). 198 An OPTIONAL member 'crypto-key' carries an array of strings, each 199 of which specifying keying material for use in encryption 200 encodings such as the 'aes128gcm' encoding defined in 201 [ENCRYPTENC]. Values consist of the name of the content coding, a 202 "=", and the base64url encoded keying material (see Section 5 of 203 [RFC4648]). 205 The payload format uses an array so that the origin server can 206 specify multiple secondary resources. The ordering within the array 207 reflects the origin server's preference (if any), with the most 208 preferred secondary resource location being first. Clients receiving 209 a response containing multiple entries are free to choose which of 210 these to use. 212 In some cases, the origin server might want to specify a "fallback 213 URI"; identifying a secondary resource served by the origin server 214 itself, but otherwise equivalent "regular" secondary resources. Any 215 secondary resource hosted by the origin server can be considered to 216 be a "fallback"; origin servers will usually list them last in the 217 "sr" array so that they only will be used by clients when there is no 218 other choice. 220 New specifications can define new OPTIONAL member fields, thus 221 clients MUST ignore unknown fields. Furthermore, new specifications 222 can define new object formats for the 'sr' array; however, they MUST 223 NOT use a member named 'r' unless the semantics are compatible with 224 those defined above. 226 Extension specifications will have to update this specification. 228 3.3. Processing Steps 230 Upon receipt of an 'out-of-band' encoded response, a client first 231 needs to obtain the secondary resource's presentation. This is done 232 using an HTTP GET request (independently of the original request 233 method). 235 In order to prevent any leakage of information, the GET request for 236 the secondary resource MUST only contain information provided by the 237 origin server or the secondary server itself, namely HTTP 238 authentication credentials ([RFC7235]) and cookies ([RFC6265]). 240 Furthermore, the request MUST include an "Origin" header field 241 indicating the origin of the original resource ([RFC6454], Section 242 7). The secondary server MUST verify that the specified origin is 243 authorized to retrieve the given payload (or otherwise return an 244 appropriate 4xx status code). 246 In addition to that, the secondary server's response MUST include a 247 "Content-Type" header field indicating an Internet media type of 248 "application/oob-stream". Clients MUST check for this media type and 249 abort out-of-band processing if no media type is specified, or if it 250 doesn't match this value. 252 After receipt of the secondary resource's payload, the client then 253 reconstructs the original message by: 255 1. Unwrapping the encapsulated HTTP message by removing any transfer 256 and content codings. 258 2. Replacing/setting any response header fields from the primary 259 response except for framing-related information such as Content- 260 Length, Transfer-Encoding and Content-Encoding. 262 If the client is unable to retrieve the secondary resource's 263 representation (host can't be reached, non 2xx response status code, 264 payload failing integrity check, etc.), it can choose an alternate 265 secondary resource (if specified), try the fallback URI (if given), 266 or simply retry the request to the origin server without including 267 'out-of-band' in the Accept-Encoding request header field. In the 268 latter case, it can be useful to inform the origin server about what 269 problems were encountered when trying to access the secondary 270 resource; see Appendix A for details. 272 Note that although this mechanism causes the inclusion of external 273 content, it will not affect the application-level security properties 274 of the reconstructed message, such as its web origin ([RFC6454]). 276 The cacheability of the response for the secondary resource does not 277 affect the cacheability of the reconstructed response message, which 278 is the same as for the origin server's response. 280 Use of the 'out-of-band' coding is similar to HTTP redirects 281 ([RFC7231], Section 6.4) in that it can lead to cycles. Unless with 282 HTTP redirects, the client however is in full control: it does not 283 need to advertise support for the 'out-of-band' coding in requests 284 for secondary resources. Alternatively, it can protect itself just 285 like for HTTP redirects -- by limiting the number of indirections it 286 supports. 288 Note that because the server's response depends on the request's 289 Accept-Encoding header field, the response usually will need to be 290 declared to vary on that. See Section 7.1.4 of [RFC7231] and Section 291 2.3 of [RFC7232] for details. 293 3.4. Examples 295 3.4.1. Basic Example 297 Client request of primary resource at https://www.example.com/test: 299 GET /test HTTP/1.1 300 Host: www.example.com 301 Accept-Encoding: gzip, out-of-band 303 Response: 305 HTTP/1.1 200 OK 306 Date: Thu, 14 May 2015 18:52:00 GMT 307 Content-Type: text/plain 308 Cache-Control: max-age=10, public 309 Content-Encoding: out-of-band 310 Content-Length: 165 311 Vary: Accept-Encoding 313 { 314 "sr": [ 315 { "r" : 316 "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"}, 317 { "r" : 318 "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"} 319 ] 320 } 322 (note that the Content-Type header field describes the media type of 323 the secondary's resource representation, and the origin server 324 supplied a fallback URI) 326 Client request for secondary resource: 328 GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1 329 Host: example.net 330 Origin: https://www.example.com 332 Response: 334 HTTP/1.1 200 OK 335 Date: Thu, 14 May 2015 18:52:10 GMT 336 Cache-Control: private 337 Content-Type: application/oob-stream 338 Content-Length: 15 340 Hello, world. 342 Final message after recombining header fields: 344 HTTP/1.1 200 OK 345 Date: Thu, 14 May 2015 18:52:00 GMT 346 Content-Length: 15 347 Cache-Control: max-age=10, public 348 Content-Type: text/plain 350 Hello, world. 352 3.4.2. Example for an attempt to use 'out-of-band' cross-origin 354 Section 3.3 requires the client to include an "Origin" header field 355 in the request to a secondary server. The example below shows how 356 the server for the secondary resource would respond to a request 357 which contains an "Origin" header field identifying an unauthorized 358 origin. 360 Continuing with the example from Section 3.4.1, and a secondary 361 server that is configured to allow only access for requests initiated 362 by "https://www.example.org": 364 Client request for secondary resource: 366 GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1 367 Host: example.net 368 Origin: https://www.example.com 370 Response: 372 HTTP/1.1 403 Forbidden 373 Date: Thu, 14 May 2015 18:52:10 GMT 375 Note that a request missing the "Origin" header field would be 376 treated the same way. 378 [[anchor5: Any reason why to *mandate* a specific 4xx code?]] 380 3.4.3. Example involving an encrypted resource 382 Given the example HTTP message from Section 3.1 of [ENCRYPTENC], a 383 primary resource could use the 'out-of-band' coding to specify just 384 the location of the secondary resource plus the keying material 385 needed to decrypt the payload: 387 Response: 389 HTTP/1.1 200 OK 390 Date: Thu, 14 May 2015 18:52:00 GMT 391 Content-Encoding: aes128gcm, out-of-band 392 Content-Type: text/plain 393 Content-Length: 171 394 Vary: Accept-Encoding 396 { 397 "sr": [ 398 { "r" : 399 "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00", 400 "crypto-key" : 401 [ "aes128gcm=yqdlZ-tYemfogSmv7Ws5PQ" ] } 402 ] 403 } 405 (note that the Content-Type header field describes the media type of 406 the secondary's resource representation) 408 Response for secondary resource: 410 HTTP/1.1 200 OK 411 Date: Thu, 14 May 2015 18:52:10 GMT 412 Content-Type: application/oob-stream 413 Content-Length: 54 415 I1BsxtFttlv3u_Oo94xnmwAAEAAA-NAVub2qFgBEuQKRapoZu-IxkIva3MEB1PD- 416 ly8Thjg 417 (payload body shown in base64 for presentation purposes) 419 Final message undoing all content codings: 421 HTTP/1.1 200 OK 422 Date: Thu, 14 May 2015 18:52:00 GMT 423 Content-Length: 15 424 Content-Type: text/plain 426 I am the walrus 428 Note: in this case, the ability to undo the 'aes128gcm' is needed 429 to process the response. If 'aes128gcm' wasn't listed as 430 acceptable content coding in the request, the origin server 431 wouldn't be able to use the 'out-of-band' mechanism. 433 3.4.4. Relation to Content Negotiation 435 Use of the 'out-of-band' encoding is a case of "proactive content 436 negotiation", as defined in Section 3.4 of [RFC7231]. 438 This however does not rule out combining it with other content 439 codings. As an example, the possible iteractions with the 'gzip' 440 content coding ([RFC7230], Section 4.2.3) are described below: 442 Case 1: Primary resource does not support 'gzip' encoding 444 In this case, the response for the primary resource will never 445 include 'gzip' in the Content-Encoding header field. The secondary 446 resource however might support it, in which case the client could 447 negotiate compression by including "Accept-Encoding: gzip" in the 448 request to the secondary resource. 450 Case 2: Primary resource does support 'gzip' encoding 452 Here, the origin server would actually use two different secondary 453 resources, one of them being gzip-compressed. For instance -- going 454 back to the first example in Section 3.4.1 -- it might reply with: 456 HTTP/1.1 200 OK 457 Date: Thu, 14 May 2015 18:52:00 GMT 458 Content-Type: text/plain 459 Cache-Control: max-age=10, public 460 Content-Encoding: gzip, out-of-band 461 Content-Length: 165 462 Vary: Accept-Encoding 464 { 465 "sr": [ 466 { "r" : 467 "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a01"}, 468 { "r" : 469 "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a01"} 470 ] 471 } 473 which would mean that the payload for the secondary resource already 474 is gzip-compressed. 476 Note: The origin server could also apply gzip compression to the 477 out-of-band payload, in which case the Content-Encoding field 478 value would become: "gzip, out-of-band, gzip". 480 4. Content Codings and Range Requests 482 The combination of content codings ([RFC7231], Section 3.1.2 with 483 range requests ([RFC7233]) can lead to surprising results, as 484 applying the range request happens after applying content codings. 486 Thus, for a request for the bytes starting at position 100000 of a 487 video: 489 GET /test.mp4 HTTP/1.1 490 Host: www.example.com 491 Range: bytes=100000- 492 Accept-Encoding: identity 494 ...a successful response would use status code 206 (Partial Content) 495 and have a payload containing the octets starting at position 100000. 497 HTTP/1.1 206 Partial Content 498 Date: Thu, 08 September 2015 16:49:00 GMT 499 Content-Type: video/mp4 500 Content-Length: 134567 501 Content-Range: bytes 100000-234566/234567 503 (binary data) 505 However, if the request would have allowed the use of 'out-of-band' 506 coding: 508 GET /test.mp4 HTTP/1.1 509 Host: www.example.com 510 Range: bytes=100000- 511 Accept-Encoding: out-of-band 513 ...a server might return an empty payload (if the out-of-band coded 514 response body would be shorter than 100000 bytes, as would be usually 515 the case). 517 Thus, in order to avoid unnecessary network traffic, servers SHOULD 518 NOT apply range request processing to responses using ouf-of-band 519 content coding (or, in other words: ignore "Range" request header 520 fields in this case). 522 5. Feature Discovery 524 New content codings can be deployed easily, as the client can use the 525 "Accept-Encoding" header field (Section 5.3.4 of [RFC7231]) to signal 526 which content codings are supported. 528 6. Security Considerations 530 6.1. Content Modifications 532 This specification does not define means to verify that the payload 533 obtained from the secondary resource really is what the origin server 534 expects it to be. Content signatures can address this concern (see 535 [CONTENTSIG] and [MICE]). 537 6.2. Content Stealing 539 The 'out-of-band' content coding could be used to circumvent the 540 same-origin policy ([RFC6454], Section 3) of user agents: an 541 attacking site which knows the URI of a secondary resource would use 542 the 'out-of-band' coding to trick the user agent to read the contents 543 of the secondary resource, which then, due to the security properties 544 of this coding, would be handled as if it originated from the 545 origin's resource. 547 This scenario is addressed by the client requirement to include the 548 "Origin" request header field and the server requirement to verify 549 that the request was initiated by an authorized origin. In addition, 550 the restriction of the secondary server response's media type to 551 "application/oob-stream" protects existing content on "regular" 552 servers not implementing this specification. 554 Note: similarities with the "Cross-Origin Resource Sharing" 555 protocol ([CORS]) are intentional. 557 Requiring the secondary resource's payload to be encrypted 558 ([ENCRYPTENC]) is an additional mitigation. 560 6.3. Use in Requests 562 In general, content codings can be used in both requests and 563 responses. This particular content coding has been designed for 564 responses. When supported in requests, it creates a new attack 565 vector where the receiving server can be tricked into including 566 content that the client might not have access to otherwise (such as 567 HTTP resources behind a firewall). 569 7. IANA Considerations 570 7.1. Content Coding: out-of-band 572 The IANA "HTTP Content Coding Registry", located at 573 , needs to be 574 updated with the registration below: 576 Name: out-of-band 578 Description: Payload needs to be retrieved from a secondary resource 580 Reference: Section 3 of this document 582 7.2. Internet Media Type: application/oob-stream 584 IANA maintains the registry of Internet media types [BCP13] at 585 . 587 This document serves as the specification for the Internet media type 588 "application/oob-stream". The following is to be registered with 589 IANA. 591 The "application/oob-stream" media type represents a sequence of 592 octets sent as part of the "out-of-band" content coding protocol 593 exchange. The sender does not have any further information about the 594 type of the enclosed data. This type is different from "application/ 595 octet-stream" as it is known not to be in use for pre-existing 596 content. 598 Type name: application 600 Subtype name: oob-stream 602 Required parameters: N/A 604 Optional parameters: N/A 606 Encoding considerations: always "binary" 608 Security considerations: see Section 6 610 Interoperability considerations: N/A 612 Published specification: This specification (see Section 7.2). 614 Applications that use this media type: HTTP servers for secondary 615 resources as defined by this specification. 617 Fragment identifier considerations: N/A 619 Additional information: 621 Magic number(s): N/A 623 Deprecated alias names for this type: N/A 625 File extension(s): N/A 627 Macintosh file type code(s): N/A 629 Person and email address to contact for further information: See 630 Authors' Addresses section. 632 Intended usage: COMMON 634 Restrictions on usage: N/A 636 Author: See Authors' Addresses section. 638 Change controller: IESG 640 8. References 642 8.1. Normative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 646 RFC2119, March 1997, 647 . 649 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 650 "Uniform Resource Identifier (URI): Generic Syntax", 651 STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, 652 . 654 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/ 655 RFC5988, October 2010, 656 . 658 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 659 DOI 10.17487/RFC6265, April 2011, 660 . 662 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 663 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, 664 March 2014, . 666 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 667 Transfer Protocol (HTTP/1.1): Message Syntax and 668 Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, 669 . 671 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 672 Transfer Protocol (HTTP/1.1): Semantics and Content", 673 RFC 7231, DOI 10.17487/RFC7231, June 2014, 674 . 676 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 677 Transfer Protocol (HTTP/1.1): Authentication", 678 RFC 7235, DOI 10.17487/RFC7235, June 2014, 679 . 681 8.2. Informative References 683 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type 684 Specifications and Registration Procedures", BCP 13, 685 RFC 6838, January 2013, 686 . 688 [CONTENTSIG] Thomson, M., "Content-Signature Header Field for HTTP", 689 draft-thomson-http-content-signature-00 (work in 690 progress), July 2015. 692 [CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C 693 Recommendation REC-cors-20140116, January 2014, 694 . 696 Latest version available at 697 . 699 [ENCRYPTENC] Thomson, M., "Encrypted Content-Encoding for HTTP", 700 draft-ietf-httpbis-encryption-encoding-08 (work in 701 progress), March 2017. 703 [MICE] Thomson, M., "Merkle Integrity Content Encoding", 704 draft-thomson-http-mice-02 (work in progress), 705 October 2016. 707 [RFC2017] Freed, N. and K. Moore, "Definition of the URL MIME 708 External-Body Access-Type", RFC 2017, DOI 10.17487/ 709 RFC2017, October 1996, 710 . 712 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 713 Session Initiation Protocol (SIP) Messages", RFC 4483, 714 DOI 10.17487/RFC4483, May 2006, 715 . 717 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 718 Encodings", RFC 4648, DOI 10.17487/RFC4648, 719 October 2006, . 721 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 722 Security (TLS) Protocol Version 1.2", RFC 5246, 723 DOI 10.17487/RFC5246, August 2008, 724 . 726 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 727 DOI 10.17487/RFC6454, December 2011, 728 . 730 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 731 Transfer Protocol (HTTP/1.1): Conditional Requests", 732 RFC 7232, DOI 10.17487/RFC7232, June 2014, 733 . 735 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 736 "Hypertext Transfer Protocol (HTTP/1.1): Range 737 Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, 738 . 740 [RMAP] Eriksson, G., Holmberg, C., Sarker, Z., and J. Reschke, 741 "Resource Maps", draft-eriksson-http-resource-map-00 742 (work in progress), October 2016. 744 [SCD] Thomson, M., Eriksson, G., and C. Holmberg, "An 745 Architecture for Secure Content Delegation using HTTP", 746 draft-thomson-http-scd-02 (work in progress), 747 October 2016. 749 URIs 751 [1] 753 [2] 755 Appendix A. Problem Reporting 757 [[erwip: This is a rough proposal for an error reporting mechanism. 758 Is it good enough? Is it needed at all? Note that Alt-Svc doesn't 759 have anything like this.]] 761 When the client fails to obtain the secondary resource, it can be 762 useful to inform the origin server about the condition. This can be 763 accomplished by adding a "Link" header field ([RFC5988]) to a 764 subsequent request to the origin server, detailing the URI of the 765 secondary resource and the failure reason. 767 The following link extension relations are defined: 769 [[purl: need to register PURLs (now hosted by archive.org, FWIW)]] 771 A.1. Server Not Reachable 773 Used in case the server was not reachable. 775 Link relation: 777 http://purl.org/linkrel/not-reachable 779 A.2. Resource Not Found 781 Used in case the server responded, but the object could not be 782 obtained. 784 Link relation: 786 http://purl.org/linkrel/resource-not-found 788 A.3. Payload Unusable 790 Used in case the payload could be obtained, but wasn't usable (for 791 instance, because integrity checks failed). 793 Link relation: 795 http://purl.org/linkrel/payload-unusable 797 A.4. TLS Handshake Failure 799 Used in case of a TLS handshare failure ([RFC5246]). 801 Link relation: 803 http://purl.org/linkrel/tls-handshake-failure 805 A.5. Example For Problem Reporting 807 Client requests primary resource as in Section 3.4.1, but the attempt 808 to access the secondary resource fails. 810 Response: 812 HTTP/1.1 404 Not Found 813 Date: Thu, 08 September 2015 16:49:00 GMT 814 Content-Type: text/plain 815 Content-Length: 20 817 Resource Not Found 819 Client retries with the origin server and includes Link header field 820 reporting the problem: 822 GET /test HTTP/1.1 823 Host: www.example.com 824 Accept-Encoding: gzip, out-of-band 825 Link: ; 826 rel="http://purl.org/linkrel/resource-not-found" 828 Appendix B. Alternatives, or: why not a new Status Code? 830 A plausible alternative approach would be to implement this 831 functionality one level up, using a new redirect status code (Section 832 6.4 of [RFC7231]). However, this would have several drawbacks: 834 o Servers will need to know whether a client understands the new 835 status code; thus some additional signal to opt into this protocol 836 would always be needed. 838 o In redirect messages, representation metadata (Section 3.1 of 839 [RFC7231]), namely "Content-Type", applies to the response 840 message, not the redirected-to resource. 842 o The origin-preserving nature of using a content coding would be 843 lost. 845 Another alternative would be to implement the indirection on the 846 level of the media type using something similar to the type "message/ 847 external-body", defined in [RFC2017] and refined for use in the 848 Session Initiation Protocol (SIP) in [RFC4483]. This approach though 849 would share most of the drawbacks of the status code approach 850 mentioned above. 852 Appendix C. Open Issues 853 C.1. Accessing the Secondary Resource Too Early 855 One use-case for this protocol is to enable a system of "blind 856 caches", which would serve the secondary resources. These caches 857 might only be populated on demand, thus it could happen that whatever 858 mechanism is used to populate the cache hasn't finished when the 859 client hits it (maybe due to race conditions, or because the cache is 860 behind a middlebox which doesn't allow the origin server to push 861 content to it). 863 In this particular case, it can be useful if the client was able to 864 "piggyback" the URI of the fallback for the primary resource, giving 865 the secondary server a means by which it could obtain the payload 866 itself. This information could be provided in yet another Link 867 header field: 869 GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1 870 Host: example.net 871 Link: ; 872 rel="http://purl.org/linkrel/fallback-resource" 874 (continuing the example from Section 3.4.1) 876 C.2. Resource maps 878 When 'out-of-band' coding is used as part of a caching solution, the 879 additional round trips to the origin server can be a significant 880 performance problem; in particular, when many small resources need to 881 be loaded (such as scripts, images, or video fragments). In cases 882 like these, it could be useful for the origin server to provide a 883 "resource map", allowing to skip the round trips to the origin server 884 for these mapped resources. Plausible ways to transmit the resource 885 map could be: 887 o as extension in the 'out-of-band' coding JSON payload, or 889 o as separate resource identified by a "Link" response header field. 891 See [RMAP] for further information. 893 C.3. Fragmenting 895 It might be interesting to divide the original resource's payload 896 into fragments, each of which being mapped to a distinct secondary 897 resource. This would allow to not store the full payload of a 898 resource in a single cache, thus 899 o distribute load, 901 o caching different parts of the resource with different 902 characteristics (such as only distribute the first minutes of a 903 long video), or 905 o fetching specific parts of a resource (similar to byte range 906 requests), or 908 o hiding information from the secondary server. 910 Another benefit might be that it would allow the origin server to 911 only serve the first part of a resource itself (reducing time to play 912 of a media resource), while delegating the remainder to a cache 913 (however, this might require further adjustments of the 'out-of-band' 914 payload format). 916 C.4. Relation to Content Encryption 918 Right now this specification is orthogonal to [ENCRYPTENC]/[MICE]; 919 that is, it could be used for public content such as software 920 downloads. However, the lack of mandatory encryption affects the 921 security considerations (which currently try to rule attack vectors 922 caused by ambient authority ([RFC6265], Section 8.2). We need to 923 decide whether we need this level of independence. 925 C.5. Reporting 927 This specification already defines hooks through which a client can 928 report failures when accessing secondary resources (see Appendix A). 930 However, it would be useful if there were also ways to report on 931 statistics such as: 933 o Success (Cache Hit) rates, and 935 o Bandwidth to secondary servers. 937 This could be implemented using a new service endpoint and a (JSON?) 938 payload format. 940 Similarly, a reporting facility for use by the secondary servers 941 could be useful. 943 C.6. Controlling Transmission Of Various Request Header Fields 945 Clients by default might include request header fields such as "User- 946 Agent" (or some of the newly defined "Client Hints") into their 947 requests to the secondary server. If the secondary server does not 948 perform any content negotiation, none of these header fields is 949 actually useful, so suppressing them by default might be a good idea 950 to reduce fingerprinting. In this case, we could allow the origin 951 server to opt into sending some of them though. 953 Appendix D. Change Log (to be removed by RFC Editor before publication) 955 D.1. Changes since draft-reschke-http-oob-encoding-00 957 Mention media type approach. 959 Explain that clients can always fall back not to use oob when the 960 secondary resource isn't available. 962 Add Vary response header field to examples and mention that it'll 963 usually be needed 964 (). 966 Experimentally add problem reporting using piggy-backed Link header 967 fields (). 969 D.2. Changes since draft-reschke-http-oob-encoding-01 971 Updated ENCRYPTENC reference. 973 D.3. Changes since draft-reschke-http-oob-encoding-02 975 Add MICE reference. 977 Remove the ability of the secondary resource to contain anything but 978 the payload (). 980 Changed JSON payload to be an object containing an array of URIs plus 981 additional members. Specify "fallback" as one of these additional 982 members, and update Appendix C.1 accordingly). 984 Discuss extensibility a bit. 986 D.4. Changes since draft-reschke-http-oob-encoding-03 988 Mention "Content Stealing" thread. 990 Mention padding. 992 D.5. Changes since draft-reschke-http-oob-encoding-04 994 Reduce information leakage by disallowing ambient authority 995 information being sent to the secondary resource. Require "Origin" 996 to be included in request to secondary resource, and require 997 secondary server to check it. 999 Mention "Origin" + server check on secondary resource as defense to 1000 content stealing. 1002 Update ENCRYPTENC reference, add SCD reference. 1004 Mention fragmentation feature. 1006 Discuss relation with range requests. 1008 D.6. Changes since draft-reschke-http-oob-encoding-05 1010 Remove redundant Cache-Control: private from one example response 1011 (the response payload is encrypted anyway). 1013 Mention looping. 1015 Remove 'metadata' payload element. 1017 Align with changes in ENCRYPTENC spec. 1019 Fix incorrect statement about what kind of cookies/credentials can be 1020 used in the request to the secondary resource. 1022 Rename "URIs" to "sr" ("secondary resources") and treat the fallback 1023 URI like a regular secondary resource. 1025 Mention reporting protocol ideas. 1027 D.7. Changes since draft-reschke-http-oob-encoding-06 1029 Changed the link relation name to the fallback resource from 1030 "primary" to "fallback". Added link relation for reporting TLS 1031 handshake failures. 1033 Added an example about the interaction with 'gzip' coding. 1035 Update ENCRYPTENC, MICE, and SCD references. 1037 D.8. Changes since draft-reschke-http-oob-encoding-07 1039 Restrict the valid media types for the response of the secondary 1040 server to "application/oob-stream". 1042 Changed JSON format to allow annotation (optional flags) and entirely 1043 new types of entries. 1045 D.9. Changes since draft-reschke-http-oob-encoding-08 1047 Moved error reporting into appendix (because it's optional and we're 1048 not sure about the utility of it). See 1049 . 1051 Updated references for ENCRYPTENC, MICE, and SCD. 1053 Mention that we could suppress certain request header fields in the 1054 request to the secondary server. 1056 D.10. Changes since draft-reschke-http-oob-encoding-09 1058 Updated reference for ENCRYPTENC. Added RMAP reference. Use all- 1059 lowercase PURLs and remove "/net" in them. 1061 D.11. Changes since draft-reschke-http-oob-encoding-10 1063 Updated reference for ENCRYPTENC: instead of using Crypto-Key 1064 response header field move the key material into the OOB payload. 1066 Appendix E. Acknowledgements 1068 Thanks to Christer Holmberg, Daniel Lindstrom, Erik Nygren, Goran 1069 Eriksson, John Mattsson, Kevin Smith, Magnus Westerlund, Mark 1070 Nottingham, Martin Thomson, and Roland Zink for feedback on this 1071 document. 1073 Authors' Addresses 1075 Julian F. Reschke 1076 greenbytes GmbH 1077 Hafenweg 16 1078 Muenster, NW 48155 1079 Germany 1081 EMail: julian.reschke@greenbytes.de 1082 URI: http://greenbytes.de/tech/webdav/ 1083 Salvatore Loreto 1084 Ericsson 1085 Torshamnsgatan 21 1086 Stochholm 16483 1087 Sweden 1089 EMail: salvatore.loreto@ericsson.com