idnits 2.17.1
draft-reschke-http-oob-encoding-12.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 (June 24, 2017) is 2498 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)
-- Looks like a reference, but probably isn't: '1' on line 22
-- Looks like a reference, but probably isn't: '2' on line 23
** 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 (-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 (~~), 2 warnings (==), 6 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: December 26, 2017 Ericsson
6 June 24, 2017
8 'Out-Of-Band' Content Coding for HTTP
9 draft-reschke-http-oob-encoding-12
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 ietf-http-
22 wg@w3.org [1], which may be joined by sending a message with subject
23 "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 and .
33 The changes in this draft are summarized in Appendix D.12.
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 December 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
69 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
70 3. 'Out-Of-Band' Content Coding . . . . . . . . . . . . . . . . 4
71 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
72 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
73 3.3. Processing Steps . . . . . . . . . . . . . . . . . . . . 5
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' cross-
77 origin . . . . . . . . . . . . . . . . . . . . . . . 8
78 3.4.3. Example involving an encrypted resource . . . . . . . 9
79 3.4.4. Relation to Content Negotiation . . . . . . . . . . . 10
80 4. Content Codings and Range Requests . . . . . . . . . . . . . 11
81 5. Feature Discovery . . . . . . . . . . . . . . . . . . . . . . 12
82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
83 6.1. Content Modifications . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . 19
98 Appendix B. Alternatives, or: why not a new Status Code? . . . . 19
99 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 20
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 Fields 22
106 Appendix D. Change Log (to be removed by RFC Editor before
107 publication) . . . . . . . . . . . . . . . . . . . . 22
108 D.1. Changes since draft-reschke-http-oob-encoding-00 . . . . 22
109 D.2. Changes since draft-reschke-http-oob-encoding-01 . . . . 22
110 D.3. Changes since draft-reschke-http-oob-encoding-02 . . . . 22
111 D.4. Changes since draft-reschke-http-oob-encoding-03 . . . . 22
112 D.5. Changes since draft-reschke-http-oob-encoding-04 . . . . 23
113 D.6. Changes since draft-reschke-http-oob-encoding-05 . . . . 23
114 D.7. Changes since draft-reschke-http-oob-encoding-06 . . . . 23
115 D.8. Changes since draft-reschke-http-oob-encoding-07 . . . . 24
116 D.9. Changes since draft-reschke-http-oob-encoding-08 . . . . 24
117 D.10. Changes since draft-reschke-http-oob-encoding-09 . . . . 24
118 D.11. Changes since draft-reschke-http-oob-encoding-10 . . . . 24
119 D.12. Changes since draft-reschke-http-oob-encoding-11 . . . . 24
120 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
123 1. Introduction
125 This document describes an Hypertext Transfer Protocol (HTTP) content
126 coding (Section 3.1.2.1 of [RFC7231]) that can be used to describe
127 the location of a secondary resource that contains the payload.
129 The primary use case for this content coding is to enable origin
130 servers to securely delegate the delivery of content to a secondary
131 server that might be "closer" to the client (with respect to network
132 topology) and/or able to cache content ([SCD]), leveraging content
133 encryption ([RFC8188]).
135 2. Notational Conventions
137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
139 document are to be interpreted as described in [RFC2119].
141 This document reuses terminology used in the base HTTP
142 specifications, namely Section 2 of [RFC7230] and Section 3 of
143 [RFC7231].
145 3. 'Out-Of-Band' Content Coding
147 3.1. Overview
149 The 'Out-Of-Band' content coding is used to direct the recipient to
150 retrieve the actual message representation (Section 3 of [RFC7231])
151 from a secondary resource, such as a public cache:
153 1. Client performs a request
155 2. Received response specifies the 'out-of-band' content coding; the
156 payload of the response contains additional meta data, plus the
157 location of the secondary resource
159 3. Client performs GET request on secondary resource (usually again
160 via HTTP(s))
162 4. Secondary server provides payload
164 5. Client combines above representation with additional
165 representation metadata obtained from the primary resource
167 Client Secondary Server Origin Server
169 sends GET request with Accept-Encoding: out-of-band
170 (1) |---------------------------------------------------------\
171 status 200 and Content-Coding: out-of-band |
172 (2) <---------------------------------------------------------/
174 GET to secondary server
175 (3) |---------------------------\
176 payload |
177 (4) <---------------------------/
179 (5)
180 Client and combines payload received in (4)
181 with metadata received in (2).
183 3.2. Definitions
185 The name of the content coding is "out-of-band".
187 The payload format uses JavaScript Object Notation (JSON, [RFC7159]),
188 describing an object describing secondary resources; currently only
189 defining one member:
191 'sr' A REQUIRED array of JSON objects.
193 Objects having a member named 'r' describe a secondary resource,
194 with the member's string value containing a URI reference
195 (Section 4.1 of [RFC3986]) of the secondary resource (URI
196 references that are relative references are resolved against the
197 URI of the primary resource).
199 An OPTIONAL member 'crypto-key' carries an array of strings, each
200 of which specifying keying material for use in encryption
201 encodings such as the 'aes128gcm' encoding defined in [RFC8188].
202 Values consist of the name of the content coding, a "=", and the
203 base64url encoded keying material (see Section 5 of [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],
242 Section 7). The secondary server MUST verify that the specified
243 origin is authorized to retrieve the given payload (or otherwise
244 return an 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
291 Section 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 [[CREF1: 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 [RFC8188], 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
418 (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 ([RFC8188]) 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
571 7.1. Content Coding: out-of-band
573 The IANA "HTTP Content Coding Registry", located at
574 , needs to be
575 updated with the registration below:
577 Name: out-of-band
579 Description: Payload needs to be retrieved from a secondary resource
581 Reference: Section 3 of this document
583 7.2. Internet Media Type: application/oob-stream
585 IANA maintains the registry of Internet media types [BCP13] at
586 .
588 This document serves as the specification for the Internet media type
589 "application/oob-stream". The following is to be registered with
590 IANA.
592 The "application/oob-stream" media type represents a sequence of
593 octets sent as part of the "out-of-band" content coding protocol
594 exchange. The sender does not have any further information about the
595 type of the enclosed data. This type is different from "application/
596 octet-stream" as it is known not to be in use for pre-existing
597 content.
599 Type name: application
601 Subtype name: oob-stream
603 Required parameters: N/A
605 Optional parameters: N/A
607 Encoding considerations: always "binary"
609 Security considerations: see Section 6
611 Interoperability considerations: N/A
613 Published specification: This specification (see Section 7.2).
615 Applications that use this media type: HTTP servers for secondary
616 resources as defined by this specification.
618 Fragment identifier considerations: N/A
620 Additional information:
622 Additional information:
624 Magic number(s): N/A
626 Deprecated alias names for this type: N/A
628 File extension(s): N/A
630 Macintosh file type code(s): N/A
632 Person and email address to contact for further information: See Aut
633 hors' Addresses section.
635 Intended usage: COMMON
637 Restrictions on usage: N/A
639 Author: See Authors' Addresses section.
641 Change controller: IESG
643 8. References
645 8.1. Normative References
647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
648 Requirement Levels", BCP 14, RFC 2119,
649 DOI 10.17487/RFC2119, March 1997,
650 .
652 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
653 Resource Identifier (URI): Generic Syntax", STD 66,
654 RFC 3986, DOI 10.17487/RFC3986, January 2005,
655 .
657 [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
658 DOI 10.17487/RFC5988, October 2010,
659 .
661 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
662 DOI 10.17487/RFC6265, April 2011,
663 .
665 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
666 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
667 2014, .
669 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
670 Protocol (HTTP/1.1): Message Syntax and Routing",
671 RFC 7230, DOI 10.17487/RFC7230, June 2014,
672 .
674 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
675 Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
676 DOI 10.17487/RFC7231, June 2014,
677 .
679 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
680 Protocol (HTTP/1.1): Authentication", RFC 7235,
681 DOI 10.17487/RFC7235, June 2014,
682 .
684 8.2. Informative References
686 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
687 Specifications and Registration Procedures", BCP 13,
688 RFC 6838, January 2013,
689 .
691 [CONTENTSIG]
692 Thomson, M., "Content-Signature Header Field for HTTP",
693 draft-thomson-http-content-signature-00 (work in
694 progress), July 2015.
696 [CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C
697 Recommendation REC-cors-20140116, January 2014,
698 .
700 Latest version available at .
702 [MICE] Thomson, M., "Merkle Integrity Content Encoding", draft-
703 thomson-http-mice-02 (work in progress), October 2016.
705 [RFC2017] Freed, N. and K. Moore, "Definition of the URL MIME
706 External-Body Access-Type", RFC 2017,
707 DOI 10.17487/RFC2017, October 1996,
708 .
710 [RFC4483] Burger, E., "A Mechanism for Content Indirection in
711 Session Initiation Protocol (SIP) Messages", RFC 4483,
712 DOI 10.17487/RFC4483, May 2006,
713 .
715 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
716 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
717 .
719 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
720 (TLS) Protocol Version 1.2", RFC 5246,
721 DOI 10.17487/RFC5246, August 2008,
722 .
724 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
725 DOI 10.17487/RFC6454, December 2011,
726 .
728 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
729 Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
730 DOI 10.17487/RFC7232, June 2014,
731 .
733 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
734 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
735 RFC 7233, DOI 10.17487/RFC7233, June 2014,
736 .
738 [RFC8188] Thomson, M., "Encrypted Content-Encoding for HTTP",
739 RFC 8188, DOI 10.17487/RFC8188, June 2017,
740 .
742 [RMAP] Eriksson, G., Holmberg, C., Sarker, Z., and J. Reschke,
743 "Resource Maps", draft-eriksson-http-resource-map-00 (work
744 in progress), October 2016.
746 [SCD] Thomson, M., Eriksson, G., and C. Holmberg, "An
747 Architecture for Secure Content Delegation using HTTP",
748 draft-thomson-http-scd-02 (work in progress), October
749 2016.
751 Appendix A. Problem Reporting
753 [[erwip: This is a rough proposal for an error reporting mechanism.
754 Is it good enough? Is it needed at all? Note that Alt-Svc doesn't
755 have anything like this.]]
757 When the client fails to obtain the secondary resource, it can be
758 useful to inform the origin server about the condition. This can be
759 accomplished by adding a "Link" header field ([RFC5988]) to a
760 subsequent request to the origin server, detailing the URI of the
761 secondary resource and the failure reason.
763 The following link extension relations are defined:
765 A.1. Server Not Reachable
767 Used in case the server was not reachable.
769 Link relation:
771 http://purl.org/linkrel/not-reachable
773 A.2. Resource Not Found
775 Used in case the server responded, but the object could not be
776 obtained.
778 Link relation:
780 http://purl.org/linkrel/resource-not-found
782 A.3. Payload Unusable
784 Used in case the payload could be obtained, but wasn't usable (for
785 instance, because integrity checks failed).
787 Link relation:
789 http://purl.org/linkrel/payload-unusable
791 A.4. TLS Handshake Failure
793 Used in case of a TLS handshare failure ([RFC5246]).
795 Link relation:
797 http://purl.org/linkrel/tls-handshake-failure
799 A.5. Example For Problem Reporting
801 Client requests primary resource as in Section 3.4.1, but the attempt
802 to access the secondary resource fails.
804 Response:
806 HTTP/1.1 404 Not Found
807 Date: Thu, 08 September 2015 16:49:00 GMT
808 Content-Type: text/plain
809 Content-Length: 20
811 Resource Not Found
813 Client retries with the origin server and includes Link header field
814 reporting the problem:
816 GET /test HTTP/1.1
817 Host: www.example.com
818 Accept-Encoding: gzip, out-of-band
819 Link: ;
820 rel="http://purl.org/linkrel/resource-not-found"
822 Appendix B. Alternatives, or: why not a new Status Code?
824 A plausible alternative approach would be to implement this
825 functionality one level up, using a new redirect status code
826 (Section 6.4 of [RFC7231]). However, this would have several
827 drawbacks:
829 o Servers will need to know whether a client understands the new
830 status code; thus some additional signal to opt into this protocol
831 would always be needed.
833 o In redirect messages, representation metadata (Section 3.1 of
834 [RFC7231]), namely "Content-Type", applies to the response
835 message, not the redirected-to resource.
837 o The origin-preserving nature of using a content coding would be
838 lost.
840 Another alternative would be to implement the indirection on the
841 level of the media type using something similar to the type "message/
842 external-body", defined in [RFC2017] and refined for use in the
843 Session Initiation Protocol (SIP) in [RFC4483]. This approach though
844 would share most of the drawbacks of the status code approach
845 mentioned above.
847 Appendix C. Open Issues
849 C.1. Accessing the Secondary Resource Too Early
851 One use-case for this protocol is to enable a system of "blind
852 caches", which would serve the secondary resources. These caches
853 might only be populated on demand, thus it could happen that whatever
854 mechanism is used to populate the cache hasn't finished when the
855 client hits it (maybe due to race conditions, or because the cache is
856 behind a middlebox which doesn't allow the origin server to push
857 content to it).
859 In this particular case, it can be useful if the client was able to
860 "piggyback" the URI of the fallback for the primary resource, giving
861 the secondary server a means by which it could obtain the payload
862 itself. This information could be provided in yet another Link
863 header field:
865 GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1
866 Host: example.net
867 Link: ;
868 rel="http://purl.org/linkrel/fallback-resource"
870 (continuing the example from Section 3.4.1)
872 C.2. Resource maps
874 When 'out-of-band' coding is used as part of a caching solution, the
875 additional round trips to the origin server can be a significant
876 performance problem; in particular, when many small resources need to
877 be loaded (such as scripts, images, or video fragments). In cases
878 like these, it could be useful for the origin server to provide a
879 "resource map", allowing to skip the round trips to the origin server
880 for these mapped resources. Plausible ways to transmit the resource
881 map could be:
883 o as extension in the 'out-of-band' coding JSON payload, or
885 o as separate resource identified by a "Link" response header field.
887 See [RMAP] for further information.
889 C.3. Fragmenting
891 It might be interesting to divide the original resource's payload
892 into fragments, each of which being mapped to a distinct secondary
893 resource. This would allow to not store the full payload of a
894 resource in a single cache, thus
896 o distribute load,
898 o caching different parts of the resource with different
899 characteristics (such as only distribute the first minutes of a
900 long video), or
902 o fetching specific parts of a resource (similar to byte range
903 requests), or
905 o hiding information from the secondary server.
907 Another benefit might be that it would allow the origin server to
908 only serve the first part of a resource itself (reducing time to play
909 of a media resource), while delegating the remainder to a cache
910 (however, this might require further adjustments of the 'out-of-band'
911 payload format).
913 C.4. Relation to Content Encryption
915 Right now this specification is orthogonal to [RFC8188]/[MICE]; that
916 is, it could be used for public content such as software downloads.
917 However, the lack of mandatory encryption affects the security
918 considerations (which currently try to rule attack vectors caused by
919 ambient authority ([RFC6265], Section 8.2). We need to decide
920 whether we need this level of independence.
922 C.5. Reporting
924 This specification already defines hooks through which a client can
925 report failures when accessing secondary resources (see Appendix A).
927 However, it would be useful if there were also ways to report on
928 statistics such as:
930 o Success (Cache Hit) rates, and
932 o Bandwidth to secondary servers.
934 This could be implemented using a new service endpoint and a (JSON?)
935 payload format.
937 Similarly, a reporting facility for use by the secondary servers
938 could be useful.
940 C.6. Controlling Transmission Of Various Request Header Fields
942 Clients by default might include request header fields such as "User-
943 Agent" (or some of the newly defined "Client Hints") into their
944 requests to the secondary server. If the secondary server does not
945 perform any content negotiation, none of these header fields is
946 actually useful, so suppressing them by default might be a good idea
947 to reduce fingerprinting. In this case, we could allow the origin
948 server to opt into sending some of them though.
950 Appendix D. Change Log (to be removed by RFC Editor before publication)
952 D.1. Changes since draft-reschke-http-oob-encoding-00
954 Mention media type approach.
956 Explain that clients can always fall back not to use oob when the
957 secondary resource isn't available.
959 Add Vary response header field to examples and mention that it'll
960 usually be needed ().
963 Experimentally add problem reporting using piggy-backed Link header
964 fields ().
966 D.2. Changes since draft-reschke-http-oob-encoding-01
968 Updated ENCRYPTENC reference.
970 D.3. Changes since draft-reschke-http-oob-encoding-02
972 Add MICE reference.
974 Remove the ability of the secondary resource to contain anything but
975 the payload ().
977 Changed JSON payload to be an object containing an array of URIs plus
978 additional members. Specify "fallback" as one of these additional
979 members, and update Appendix C.1 accordingly).
981 Discuss extensibility a bit.
983 D.4. Changes since draft-reschke-http-oob-encoding-03
985 Mention "Content Stealing" thread.
987 Mention padding.
989 D.5. Changes since draft-reschke-http-oob-encoding-04
991 Reduce information leakage by disallowing ambient authority
992 information being sent to the secondary resource. Require "Origin"
993 to be included in request to secondary resource, and require
994 secondary server to check it.
996 Mention "Origin" + server check on secondary resource as defense to
997 content stealing.
999 Update ENCRYPTENC reference, add SCD reference.
1001 Mention fragmentation feature.
1003 Discuss relation with range requests.
1005 D.6. Changes since draft-reschke-http-oob-encoding-05
1007 Remove redundant Cache-Control: private from one example response
1008 (the response payload is encrypted anyway).
1010 Mention looping.
1012 Remove 'metadata' payload element.
1014 Align with changes in ENCRYPTENC spec.
1016 Fix incorrect statement about what kind of cookies/credentials can be
1017 used in the request to the secondary resource.
1019 Rename "URIs" to "sr" ("secondary resources") and treat the fallback
1020 URI like a regular secondary resource.
1022 Mention reporting protocol ideas.
1024 D.7. Changes since draft-reschke-http-oob-encoding-06
1026 Changed the link relation name to the fallback resource from
1027 "primary" to "fallback". Added link relation for reporting TLS
1028 handshake failures.
1030 Added an example about the interaction with 'gzip' coding.
1032 Update ENCRYPTENC, MICE, and SCD references.
1034 D.8. Changes since draft-reschke-http-oob-encoding-07
1036 Restrict the valid media types for the response of the secondary
1037 server to "application/oob-stream".
1039 Changed JSON format to allow annotation (optional flags) and entirely
1040 new types of entries.
1042 D.9. Changes since draft-reschke-http-oob-encoding-08
1044 Moved error reporting into appendix (because it's optional and we're
1045 not sure about the utility of it). See
1046 .
1048 Updated references for ENCRYPTENC, MICE, and SCD.
1050 Mention that we could suppress certain request header fields in the
1051 request to the secondary server.
1053 D.10. Changes since draft-reschke-http-oob-encoding-09
1055 Updated reference for ENCRYPTENC. Added RMAP reference. Use all-
1056 lowercase PURLs and remove "/net" in them.
1058 D.11. Changes since draft-reschke-http-oob-encoding-10
1060 Updated reference for ENCRYPTENC: instead of using Crypto-Key
1061 response header field move the key material into the OOB payload.
1063 D.12. Changes since draft-reschke-http-oob-encoding-11
1065 Removed note about registration of purl URIs for link relations.
1067 Updated reference for ENCRYPTENC (now RFC 8188).
1069 Acknowledgements
1071 Thanks to Christer Holmberg, Daniel Lindstrom, Erik Nygren, Goran
1072 Eriksson, John Mattsson, Kevin Smith, Magnus Westerlund, Mark
1073 Nottingham, Martin Thomson, and Roland Zink for feedback on this
1074 document.
1076 Authors' Addresses
1077 Julian F. Reschke
1078 greenbytes GmbH
1079 Hafenweg 16
1080 Muenster, NW 48155
1081 Germany
1083 EMail: julian.reschke@greenbytes.de
1084 URI: http://greenbytes.de/tech/webdav/
1086 Salvatore Loreto
1087 Ericsson
1088 Torshamnsgatan 21
1089 Stochholm 16483
1090 Sweden
1092 EMail: salvatore.loreto@ericsson.com