idnits 2.17.1
draft-reschke-http-oob-encoding-09.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 (October 30, 2016) is 2735 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-03
== 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: May 3, 2017 Ericsson
6 October 30, 2016
8 'Out-Of-Band' Content Coding for HTTP
9 draft-reschke-http-oob-encoding-09
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.9.
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 May 3, 2017.
51 Copyright Notice
53 Copyright (c) 2016 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 . . . . . . . . 19
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 . . . . . 22
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 . . . . . 23
117 D.9. Changes since draft-reschke-http-oob-encoding-08 . . . . . 23
118 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 24
120 1. Introduction
122 This document describes an Hypertext Transfer Protocol (HTTP) content
123 coding (Section 3.1.2.1 of [RFC7231]) that can be used to describe
124 the location of a secondary resource that contains the payload.
126 The primary use case for this content coding is to enable origin
127 servers to securely delegate the delivery of content to a secondary
128 server that might be "closer" to the client (with respect to network
129 topology) and/or able to cache content ([SCD]), leveraging content
130 encryption ([ENCRYPTENC]).
132 2. Notational Conventions
134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
136 document are to be interpreted as described in [RFC2119].
138 This document reuses terminology used in the base HTTP
139 specifications, namely Section 2 of [RFC7230] and Section 3 of
140 [RFC7231].
142 3. 'Out-Of-Band' Content Coding
144 3.1. Overview
146 The 'Out-Of-Band' content coding is used to direct the recipient to
147 retrieve the actual message representation (Section 3 of [RFC7231])
148 from a secondary resource, such as a public cache:
150 1. Client performs a request
152 2. Received response specifies the 'out-of-band' content coding; the
153 payload of the response contains additional meta data, plus the
154 location of the secondary resource
156 3. Client performs GET request on secondary resource (usually again
157 via HTTP(s))
159 4. Secondary server provides payload
161 5. Client combines above representation with additional
162 representation metadata obtained from the primary resource
164 Client Secondary Server Origin Server
166 sends GET request with Accept-Encoding: out-of-band
167 (1) |---------------------------------------------------------\
168 status 200 and Content-Coding: out-of-band |
169 (2) <---------------------------------------------------------/
171 GET to secondary server
172 (3) |---------------------------\
173 payload |
174 (4) <---------------------------/
176 (5)
177 Client and combines payload received in (4)
178 with metadata received in (2).
180 3.2. Definitions
182 The name of the content coding is "out-of-band".
184 The payload format uses JavaScript Object Notation (JSON, [RFC7159]),
185 describing an object describing secondary resources; currently only
186 defining one member:
188 'sr' A REQUIRED array of JSON objects. Objects having a member
189 named 'r' describe a secondary resource, with the member's string
190 value containing a URI reference (Section 4.1 of [RFC3986]) of the
191 secondary resource (URI references that are relative references
192 are resolved against the URI of the primary resource).
194 The payload format uses an array so that the origin server can
195 specify multiple secondary resources. The ordering within the array
196 reflects the origin server's preference (if any), with the most
197 preferred secondary resource location being first. Clients receiving
198 a response containing multiple entries are free to choose which of
199 these to use.
201 In some cases, the origin server might want to specify a "fallback
202 URI"; identifying a secondary resource served by the origin server
203 itself, but otherwise equivalent "regular" secondary resources. Any
204 secondary resource hosted by the origin server can be considered to
205 be a "fallback"; origin servers will usually list them last in the
206 "sr" array so that they only will be used by clients when there is no
207 other choice.
209 New specifications can define new OPTIONAL member fields, thus
210 clients MUST ignore unknown fields. Furthermore, new specifications
211 can define new object formats for the 'sr' array; however, they MUST
212 NOT use a member named 'r' unless the semantics are compatible with
213 those defined above.
215 Extension specifications will have to update this specification.
217 3.3. Processing Steps
219 Upon receipt of an 'out-of-band' encoded response, a client first
220 needs to obtain the secondary resource's presentation. This is done
221 using an HTTP GET request (independently of the original request
222 method).
224 In order to prevent any leakage of information, the GET request for
225 the secondary resource MUST only contain information provided by the
226 origin server or the secondary server itself, namely HTTP
227 authentication credentials ([RFC7235]) and cookies ([RFC6265]).
229 Furthermore, the request MUST include an "Origin" header field
230 indicating the origin of the original resource ([RFC6454], Section
231 7). The secondary server MUST verify that the specified origin is
232 authorized to retrieve the given payload (or otherwise return an
233 appropriate 4xx status code).
235 In addition to that, the secondary server's response MUST include a
236 "Content-Type" header field indicating an Internet media type of
237 "application/oob-stream". Clients MUST check for this media type and
238 abort out-of-band processing if no media type is specified, or if it
239 doesn't match this value.
241 After receipt of the secondary resource's payload, the client then
242 reconstructs the original message by:
244 1. Unwrapping the encapsulated HTTP message by removing any transfer
245 and content codings.
247 2. Replacing/setting any response header fields from the primary
248 response except for framing-related information such as Content-
249 Length, Transfer-Encoding and Content-Encoding.
251 If the client is unable to retrieve the secondary resource's
252 representation (host can't be reached, non 2xx response status code,
253 payload failing integrity check, etc.), it can choose an alternate
254 secondary resource (if specified), try the fallback URI (if given),
255 or simply retry the request to the origin server without including
256 'out-of-band' in the Accept-Encoding request header field. In the
257 latter case, it can be useful to inform the origin server about what
258 problems were encountered when trying to access the secondary
259 resource; see Appendix A for details.
261 Note that although this mechanism causes the inclusion of external
262 content, it will not affect the application-level security properties
263 of the reconstructed message, such as its web origin ([RFC6454]).
265 The cacheability of the response for the secondary resource does not
266 affect the cacheability of the reconstructed response message, which
267 is the same as for the origin server's response.
269 Use of the 'out-of-band' coding is similar to HTTP redirects
270 ([RFC7231], Section 6.4) in that it can lead to cycles. Unless with
271 HTTP redirects, the client however is in full control: it does not
272 need to advertise support for the 'out-of-band' coding in requests
273 for secondary resources. Alternatively, it can protect itself just
274 like for HTTP redirects -- by limiting the number of indirections it
275 supports.
277 Note that because the server's response depends on the request's
278 Accept-Encoding header field, the response usually will need to be
279 declared to vary on that. See Section 7.1.4 of [RFC7231] and Section
280 2.3 of [RFC7232] for details.
282 3.4. Examples
284 3.4.1. Basic Example
286 Client request of primary resource at https://www.example.com/test:
288 GET /test HTTP/1.1
289 Host: www.example.com
290 Accept-Encoding: gzip, out-of-band
292 Response:
294 HTTP/1.1 200 OK
295 Date: Thu, 14 May 2015 18:52:00 GMT
296 Content-Type: text/plain
297 Cache-Control: max-age=10, public
298 Content-Encoding: out-of-band
299 Content-Length: 165
300 Vary: Accept-Encoding
302 {
303 "sr": [
304 { "r" :
305 "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"},
306 { "r" :
307 "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"}
308 ]
309 }
311 (note that the Content-Type header field describes the media type of
312 the secondary's resource representation, and the origin server
313 supplied a fallback URI)
315 Client request for secondary resource:
317 GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1
318 Host: example.net
319 Origin: https://www.example.com
321 Response:
323 HTTP/1.1 200 OK
324 Date: Thu, 14 May 2015 18:52:10 GMT
325 Cache-Control: private
326 Content-Type: application/oob-stream
327 Content-Length: 15
329 Hello, world.
331 Final message after recombining header fields:
333 HTTP/1.1 200 OK
334 Date: Thu, 14 May 2015 18:52:00 GMT
335 Content-Length: 15
336 Cache-Control: max-age=10, public
337 Content-Type: text/plain
339 Hello, world.
341 3.4.2. Example for an attempt to use 'out-of-band' cross-origin
343 Section 3.3 requires the client to include an "Origin" header field
344 in the request to a secondary server. The example below shows how
345 the server for the secondary resource would respond to a request
346 which contains an "Origin" header field identifying an unauthorized
347 origin.
349 Continuing with the example from Section 3.4.1, and a secondary
350 server that is configured to allow only access for requests initiated
351 by "https://www.example.org":
353 Client request for secondary resource:
355 GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1
356 Host: example.net
357 Origin: https://www.example.com
359 Response:
361 HTTP/1.1 403 Forbidden
362 Date: Thu, 14 May 2015 18:52:10 GMT
364 Note that a request missing the "Origin" header field would be
365 treated the same way.
367 [[anchor5: Any reason why to *mandate* a specific 4xx code?]]
369 3.4.3. Example involving an encrypted resource
371 Given the example HTTP message from Section 5.1 of [ENCRYPTENC], a
372 primary resource could use the 'out-of-band' coding to specify just
373 the location of the secondary resource plus the contents of the
374 "Crypto-Key" header field needed to decrypt the payload:
376 Response:
378 HTTP/1.1 200 OK
379 Date: Thu, 14 May 2015 18:52:00 GMT
380 Content-Encoding: aesgcm, out-of-band
381 Content-Type: text/plain
382 Encryption: keyid="a1"; salt="vr0o6Uq3w_KDWeatc27mUg"
383 Crypto-Key: keyid="a1"; aesgcm="csPJEXBYA5U-Tal9EdJi-w"
384 Content-Length: 101
385 Vary: Accept-Encoding
387 {
388 "sr": [
389 { "r" :
390 "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"}
391 ]
392 }
394 (note that the Content-Type header field describes the media type of
395 the secondary's resource representation)
397 Response for secondary resource:
399 HTTP/1.1 200 OK
400 Date: Thu, 14 May 2015 18:52:10 GMT
401 Content-Type: application/oob-stream
402 Content-Length: ...
404 VDeU0XxaJkOJDAxPl7h9JD5V8N43RorP7PfpPdZZQuwF
405 (payload body shown in base64 here)
407 Final message undoing all content codings:
409 HTTP/1.1 200 OK
410 Date: Thu, 14 May 2015 18:52:00 GMT
411 Content-Length: 15
412 Content-Type: text/plain
414 I am the walrus
416 Note: in this case, the ability to undo the 'aesgcm' is needed to
417 process the response. If 'aesgcm' wasn't listed as acceptable
418 content coding in the request, the origin server wouldn't be able
419 to use the 'out-of-band' mechanism.
421 3.4.4. Relation to Content Negotiation
423 Use of the 'out-of-band' encoding is a case of "proactive content
424 negotiation", as defined in Section 3.4 of [RFC7231].
426 This however does not rule out combining it with other content
427 codings. As an example, the possible iteractions with the 'gzip'
428 content coding ([RFC7230], Section 4.2.3) are described below:
430 Case 1: Primary resource does not support 'gzip' encoding
432 In this case, the response for the primary resource will never
433 include 'gzip' in the Content-Encoding header field. The secondary
434 resource however might support it, in which case the client could
435 negotiate compression by including "Accept-Encoding: gzip" in the
436 request to the secondary resource.
438 Case 2: Primary resource does support 'gzip' encoding
440 Here, the origin server would actually use two different secondary
441 resources, one of them being gzip-compressed. For instance -- going
442 back to the first example in Section 3.4.1 -- it might reply with:
444 HTTP/1.1 200 OK
445 Date: Thu, 14 May 2015 18:52:00 GMT
446 Content-Type: text/plain
447 Cache-Control: max-age=10, public
448 Content-Encoding: gzip, out-of-band
449 Content-Length: 165
450 Vary: Accept-Encoding
452 {
453 "sr": [
454 { "r" :
455 "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a01"},
456 { "r" :
457 "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a01"}
458 ]
459 }
461 which would mean that the payload for the secondary resource already
462 is gzip-compressed.
464 Note: The origin server could also apply gzip compression to the
465 out-of-band payload, in which case the Content-Encoding field
466 value would become: "gzip, out-of-band, gzip".
468 4. Content Codings and Range Requests
470 The combination of content codings ([RFC7231], Section 3.1.2 with
471 range requests ([RFC7233]) can lead to surprising results, as
472 applying the range request happens after applying content codings.
474 Thus, for a request for the bytes starting at position 100000 of a
475 video:
477 GET /test.mp4 HTTP/1.1
478 Host: www.example.com
479 Range: bytes=100000-
480 Accept-Encoding: identity
482 ...a successful response would use status code 206 (Partial Content)
483 and have a payload containing the octets starting at position 100000.
485 HTTP/1.1 206 Partial Content
486 Date: Thu, 08 September 2015 16:49:00 GMT
487 Content-Type: video/mp4
488 Content-Length: 134567
489 Content-Range: bytes 100000-234566/234567
491 (binary data)
493 However, if the request would have allowed the use of 'out-of-band'
494 coding:
496 GET /test.mp4 HTTP/1.1
497 Host: www.example.com
498 Range: bytes=100000-
499 Accept-Encoding: out-of-band
501 ...a server might return an empty payload (if the out-of-band coded
502 response body would be shorter than 100000 bytes, as would be usually
503 the case).
505 Thus, in order to avoid unnecessary network traffic, servers SHOULD
506 NOT apply range request processing to responses using ouf-of-band
507 content coding (or, in other words: ignore "Range" request header
508 fields in this case).
510 5. Feature Discovery
512 New content codings can be deployed easily, as the client can use the
513 "Accept-Encoding" header field (Section 5.3.4 of [RFC7231]) to signal
514 which content codings are supported.
516 6. Security Considerations
518 6.1. Content Modifications
520 This specification does not define means to verify that the payload
521 obtained from the secondary resource really is what the origin server
522 expects it to be. Content signatures can address this concern (see
523 [CONTENTSIG] and [MICE]).
525 6.2. Content Stealing
527 The 'out-of-band' content coding could be used to circumvent the
528 same-origin policy ([RFC6454], Section 3) of user agents: an
529 attacking site which knows the URI of a secondary resource would use
530 the 'out-of-band' coding to trick the user agent to read the contents
531 of the secondary resource, which then, due to the security properties
532 of this coding, would be handled as if it originated from the
533 origin's resource.
535 This scenario is addressed by the client requirement to include the
536 "Origin" request header field and the server requirement to verify
537 that the request was initiated by an authorized origin. In addition,
538 the restriction of the secondary server response's media type to
539 "application/oob-stream" protects existing content on "regular"
540 servers not implementing this specification.
542 Note: similarities with the "Cross-Origin Resource Sharing"
543 protocol ([CORS]) are intentional.
545 Requiring the secondary resource's payload to be encrypted
546 ([ENCRYPTENC]) is an additional mitigation.
548 6.3. Use in Requests
550 In general, content codings can be used in both requests and
551 responses. This particular content coding has been designed for
552 responses. When supported in requests, it creates a new attack
553 vector where the receiving server can be tricked into including
554 content that the client might not have access to otherwise (such as
555 HTTP resources behind a firewall).
557 7. IANA Considerations
558 7.1. Content Coding: out-of-band
560 The IANA "HTTP Content Coding Registry", located at
561 , needs to be
562 updated with the registration below:
564 Name: out-of-band
566 Description: Payload needs to be retrieved from a secondary resource
568 Reference: Section 3 of this document
570 7.2. Internet Media Type: application/oob-stream
572 IANA maintains the registry of Internet media types [BCP13] at
573 .
575 This document serves as the specification for the Internet media type
576 "application/oob-stream". The following is to be registered with
577 IANA.
579 The "application/oob-stream" media type represents a sequence of
580 octets sent as part of the "out-of-band" content coding protocol
581 exchange. The sender does not have any further information about the
582 type of the enclosed data. This type is different from "application/
583 octet-stream" as it is known not to be in use for pre-existing
584 content.
586 Type name: application
588 Subtype name: oob-stream
590 Required parameters: N/A
592 Optional parameters: N/A
594 Encoding considerations: always "binary"
596 Security considerations: see Section 6
598 Interoperability considerations: N/A
600 Published specification: This specification (see Section 7.2).
602 Applications that use this media type: HTTP servers for secondary
603 resources as defined by this specification.
605 Fragment identifier considerations: N/A
607 Additional information:
609 Magic number(s): N/A
611 Deprecated alias names for this type: N/A
613 File extension(s): N/A
615 Macintosh file type code(s): N/A
617 Person and email address to contact for further information: See
618 Authors' Addresses section.
620 Intended usage: COMMON
622 Restrictions on usage: N/A
624 Author: See Authors' Addresses section.
626 Change controller: IESG
628 8. References
630 8.1. Normative References
632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
633 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
634 RFC2119, March 1997,
635 .
637 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
638 "Uniform Resource Identifier (URI): Generic Syntax",
639 STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
640 .
642 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/
643 RFC5988, October 2010,
644 .
646 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
647 DOI 10.17487/RFC6265, April 2011,
648 .
650 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
651 Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
652 March 2014, .
654 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
655 Transfer Protocol (HTTP/1.1): Message Syntax and
656 Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014,
657 .
659 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
660 Transfer Protocol (HTTP/1.1): Semantics and Content",
661 RFC 7231, DOI 10.17487/RFC7231, June 2014,
662 .
664 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
665 Transfer Protocol (HTTP/1.1): Authentication",
666 RFC 7235, DOI 10.17487/RFC7235, June 2014,
667 .
669 8.2. Informative References
671 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
672 Specifications and Registration Procedures", BCP 13,
673 RFC 6838, January 2013,
674 .
676 [CONTENTSIG] Thomson, M., "Content-Signature Header Field for HTTP",
677 draft-thomson-http-content-signature-00 (work in
678 progress), July 2015.
680 [CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C
681 Recommendation REC-cors-20140116, January 2014,
682 .
684 Latest version available at
685 .
687 [ENCRYPTENC] Thomson, M., "Encrypted Content-Encoding for HTTP",
688 draft-ietf-httpbis-encryption-encoding-03 (work in
689 progress), October 2016.
691 [MICE] Thomson, M., "Merkle Integrity Content Encoding",
692 draft-thomson-http-mice-02 (work in progress),
693 October 2016.
695 [RFC2017] Freed, N. and K. Moore, "Definition of the URL MIME
696 External-Body Access-Type", RFC 2017, DOI 10.17487/
697 RFC2017, October 1996,
698 .
700 [RFC4483] Burger, E., "A Mechanism for Content Indirection in
701 Session Initiation Protocol (SIP) Messages", RFC 4483,
702 DOI 10.17487/RFC4483, May 2006,
703 .
705 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
706 Security (TLS) Protocol Version 1.2", RFC 5246,
707 DOI 10.17487/RFC5246, August 2008,
708 .
710 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
711 DOI 10.17487/RFC6454, December 2011,
712 .
714 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
715 Transfer Protocol (HTTP/1.1): Conditional Requests",
716 RFC 7232, DOI 10.17487/RFC7232, June 2014,
717 .
719 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
720 "Hypertext Transfer Protocol (HTTP/1.1): Range
721 Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014,
722 .
724 [SCD] Thomson, M., Eriksson, G., and C. Holmberg, "An
725 Architecture for Secure Content Delegation using HTTP",
726 draft-thomson-http-scd-02 (work in progress),
727 October 2016.
729 URIs
731 [1]
733 [2]
735 Appendix A. Problem Reporting
737 [[erwip: This is a rough proposal for an error reporting mechanism.
738 Is it good enough? Is it needed at all? Note that Alt-Svc doesn't
739 have anything like this.]]
741 When the client fails to obtain the secondary resource, it can be
742 useful to inform the origin server about the condition. This can be
743 accomplished by adding a "Link" header field ([RFC5988]) to a
744 subsequent request to the origin server, detailing the URI of the
745 secondary resource and the failure reason.
747 The following link extension relations are defined:
749 [[purl: need to register PURLs (now hosted by archive.org, FWIW)]]
751 A.1. Server Not Reachable
753 Used in case the server was not reachable.
755 Link relation:
757 http://purl.org/NET/linkrel/not-reachable
759 A.2. Resource Not Found
761 Used in case the server responded, but the object could not be
762 obtained.
764 Link relation:
766 http://purl.org/NET/linkrel/resource-not-found
768 A.3. Payload Unusable
770 Used in case the payload could be obtained, but wasn't usable (for
771 instance, because integrity checks failed).
773 Link relation:
775 http://purl.org/NET/linkrel/payload-unusable
777 A.4. TLS Handshake Failure
779 Used in case of a TLS handshare failure ([RFC5246]).
781 Link relation:
783 http://purl.org/NET/linkrel/tls-handshake-failure
785 A.5. Example For Problem Reporting
787 Client requests primary resource as in Section 3.4.1, but the attempt
788 to access the secondary resource fails.
790 Response:
792 HTTP/1.1 404 Not Found
793 Date: Thu, 08 September 2015 16:49:00 GMT
794 Content-Type: text/plain
795 Content-Length: 20
797 Resource Not Found
799 Client retries with the origin server and includes Link header field
800 reporting the problem:
802 GET /test HTTP/1.1
803 Host: www.example.com
804 Accept-Encoding: gzip, out-of-band
805 Link: ;
806 rel="http://purl.org/NET/linkrel/resource-not-found"
808 Appendix B. Alternatives, or: why not a new Status Code?
810 A plausible alternative approach would be to implement this
811 functionality one level up, using a new redirect status code (Section
812 6.4 of [RFC7231]). However, this would have several drawbacks:
814 o Servers will need to know whether a client understands the new
815 status code; thus some additional signal to opt into this protocol
816 would always be needed.
818 o In redirect messages, representation metadata (Section 3.1 of
819 [RFC7231]), namely "Content-Type", applies to the response
820 message, not the redirected-to resource.
822 o The origin-preserving nature of using a content coding would be
823 lost.
825 Another alternative would be to implement the indirection on the
826 level of the media type using something similar to the type "message/
827 external-body", defined in [RFC2017] and refined for use in the
828 Session Initiation Protocol (SIP) in [RFC4483]. This approach though
829 would share most of the drawbacks of the status code approach
830 mentioned above.
832 Appendix C. Open Issues
834 C.1. Accessing the Secondary Resource Too Early
836 One use-case for this protocol is to enable a system of "blind
837 caches", which would serve the secondary resources. These caches
838 might only be populated on demand, thus it could happen that whatever
839 mechanism is used to populate the cache hasn't finished when the
840 client hits it (maybe due to race conditions, or because the cache is
841 behind a middlebox which doesn't allow the origin server to push
842 content to it).
844 In this particular case, it can be useful if the client was able to
845 "piggyback" the URI of the fallback for the primary resource, giving
846 the secondary server a means by which it could obtain the payload
847 itself. This information could be provided in yet another Link
848 header field:
850 GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1
851 Host: example.net
852 Link: ;
853 rel="http://purl.org/NET/linkrel/fallback-resource"
855 (continuing the example from Section 3.4.1)
857 C.2. Resource maps
859 When 'out-of-band' coding is used as part of a caching solution, the
860 additional round trips to the origin server can be a significant
861 performance problem; in particular, when many small resources need to
862 be loaded (such as scripts, images, or video fragments). In cases
863 like these, it could be useful for the origin server to provide a
864 "resource map", allowing to skip the round trips to the origin server
865 for these mapped resources. Plausible ways to transmit the resource
866 map could be:
868 o as extension in the 'out-of-band' coding JSON payload, or
870 o as separate resource identified by a "Link" response header field.
872 This specification does not define a format, nor a mechanism to
873 transport the map, but it's a given that some specification using
874 'out-of-band' coding will do.
876 C.3. Fragmenting
878 It might be interesting to divide the original resource's payload
879 into fragments, each of which being mapped to a distinct secondary
880 resource. This would allow to not store the full payload of a
881 resource in a single cache, thus
883 o distribute load,
885 o caching different parts of the resource with different
886 characteristics (such as only distribute the first minutes of a
887 long video), or
889 o fetching specific parts of a resource (similar to byte range
890 requests), or
892 o hiding information from the secondary server.
894 Another benefit might be that it would allow the origin server to
895 only serve the first part of a resource itself (reducing time to play
896 of a media resource), while delegating the remainder to a cache
897 (however, this might require further adjustments of the 'out-of-band'
898 payload format).
900 C.4. Relation to Content Encryption
902 Right now this specification is orthogonal to [ENCRYPTENC]/[MICE];
903 that is, it could be used for public content such as software
904 downloads. However, the lack of mandatory encryption affects the
905 security considerations (which currently try to rule attack vectors
906 caused by ambient authority ([RFC6265], Section 8.2). We need to
907 decide whether we need this level of independence.
909 C.5. Reporting
911 This specification already defines hooks through which a client can
912 report failures when accessing secondary resources (see Appendix A).
914 However, it would be useful if there were also ways to report on
915 statistics such as:
917 o Success (Cache Hit) rates, and
919 o Bandwidth to secondary servers.
921 This could be implemented using a new service endpoint and a (JSON?)
922 payload format.
924 Similarly, a reporting facility for use by the secondary servers
925 could be useful.
927 C.6. Controlling Transmission Of Various Request Header Fields
929 Clients by default might include request header fields such as "User-
930 Agent" (or some of the newly defined "Client Hints") into their
931 requests to the secondary server. If the secondary server does not
932 perform any content negotiation, none of these header fields is
933 actually useful, so suppressing them by default might be a good idea
934 to reduce fingerprinting. In this case, we could allow the origin
935 server to opt into sending some of them though.
937 Appendix D. Change Log (to be removed by RFC Editor before publication)
939 D.1. Changes since draft-reschke-http-oob-encoding-00
941 Mention media type approach.
943 Explain that clients can always fall back not to use oob when the
944 secondary resource isn't available.
946 Add Vary response header field to examples and mention that it'll
947 usually be needed
948 ().
950 Experimentally add problem reporting using piggy-backed Link header
951 fields ().
953 D.2. Changes since draft-reschke-http-oob-encoding-01
955 Updated ENCRYPTENC reference.
957 D.3. Changes since draft-reschke-http-oob-encoding-02
959 Add MICE reference.
961 Remove the ability of the secondary resource to contain anything but
962 the payload ().
964 Changed JSON payload to be an object containing an array of URIs plus
965 additional members. Specify "fallback" as one of these additional
966 members, and update Appendix C.1 accordingly).
968 Discuss extensibility a bit.
970 D.4. Changes since draft-reschke-http-oob-encoding-03
972 Mention "Content Stealing" thread.
974 Mention padding.
976 D.5. Changes since draft-reschke-http-oob-encoding-04
978 Reduce information leakage by disallowing ambient authority
979 information being sent to the secondary resource. Require "Origin"
980 to be included in request to secondary resource, and require
981 secondary server to check it.
983 Mention "Origin" + server check on secondary resource as defense to
984 content stealing.
986 Update ENCRYPTENC reference, add SCD reference.
988 Mention fragmentation feature.
990 Discuss relation with range requests.
992 D.6. Changes since draft-reschke-http-oob-encoding-05
994 Remove redundant Cache-Control: private from one example response
995 (the response payload is encrypted anyway).
997 Mention looping.
999 Remove 'metadata' payload element.
1001 Align with changes in ENCRYPTENC spec.
1003 Fix incorrect statement about what kind of cookies/credentials can be
1004 used in the request to the secondary resource.
1006 Rename "URIs" to "sr" ("secondary resources") and treat the fallback
1007 URI like a regular secondary resource.
1009 Mention reporting protocol ideas.
1011 D.7. Changes since draft-reschke-http-oob-encoding-06
1013 Changed the link relation name to the fallback resource from
1014 "primary" to "fallback". Added link relation for reporting TLS
1015 handshake failures.
1017 Added an example about the interaction with 'gzip' coding.
1019 Update ENCRYPTENC, MICE, and SCD references.
1021 D.8. Changes since draft-reschke-http-oob-encoding-07
1023 Restrict the valid media types for the response of the secondary
1024 server to "application/oob-stream".
1026 Changed JSON format to allow annotation (optional flags) and entirely
1027 new types of entries.
1029 D.9. Changes since draft-reschke-http-oob-encoding-08
1031 Moved error reporting into appendix (because it's optional and we're
1032 not sure about the utility of it). See
1033 .
1035 Updated references for ENCRYPTENC, MICE, and SCD.
1037 Mention that we could suppress certain request header fields in the
1038 request to the secondary server.
1040 Appendix E. Acknowledgements
1042 Thanks to Christer Holmberg, Daniel Lindstrom, Erik Nygren, Goran
1043 Eriksson, John Mattsson, Kevin Smith, Magnus Westerlund, Mark
1044 Nottingham, Martin Thomson, and Roland Zink for feedback on this
1045 document.
1047 Authors' Addresses
1049 Julian F. Reschke
1050 greenbytes GmbH
1051 Hafenweg 16
1052 Muenster, NW 48155
1053 Germany
1055 EMail: julian.reschke@greenbytes.de
1056 URI: http://greenbytes.de/tech/webdav/
1058 Salvatore Loreto
1059 Ericsson
1060 Torshamnsgatan 21
1061 Stochholm 16483
1062 Sweden
1064 EMail: salvatore.loreto@ericsson.com