idnits 2.17.1
draft-reschke-http-oob-encoding-07.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 (July 5, 2016) is 2852 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-02
== Outdated reference: A later version (-03) exists of
draft-thomson-http-mice-01
-- 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)
== Outdated reference: A later version (-02) exists of
draft-thomson-http-scd-01
Summary: 6 errors (**), 0 flaws (~~), 4 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: January 6, 2017 Ericsson
6 July 5, 2016
8 'Out-Of-Band' Content Coding for HTTP
9 draft-reschke-http-oob-encoding-07
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 C.7.
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 January 6, 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. Problem Reporting . . . . . . . . . . . . . . . . . . . . 7
75 3.4.1. Server Not Reachable . . . . . . . . . . . . . . . . . 7
76 3.4.2. Resource Not Found . . . . . . . . . . . . . . . . . . 7
77 3.4.3. Payload Unusable . . . . . . . . . . . . . . . . . . . 8
78 3.4.4. TLS Handshake Failure . . . . . . . . . . . . . . . . 8
79 3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
80 3.5.1. Basic Example . . . . . . . . . . . . . . . . . . . . 8
81 3.5.2. Example for an attempt to use 'out-of-band'
82 cross-origin . . . . . . . . . . . . . . . . . . . . . 9
83 3.5.3. Example involving an encrypted resource . . . . . . . 10
84 3.5.4. Example For Problem Reporting . . . . . . . . . . . . 11
85 3.5.5. Relation to Content Negotiation . . . . . . . . . . . 11
86 4. Content Codings and Range Requests . . . . . . . . . . . . . . 12
87 5. Feature Discovery . . . . . . . . . . . . . . . . . . . . . . 13
88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
89 6.1. Content Modifications . . . . . . . . . . . . . . . . . . 13
90 6.2. Content Stealing . . . . . . . . . . . . . . . . . . . . . 13
91 6.3. Use in Requests . . . . . . . . . . . . . . . . . . . . . 14
92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
95 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
96 Appendix A. Alternatives, or: why not a new Status Code? . . . . 16
97 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 17
98 B.1. Accessing the Secondary Resource Too Early . . . . . . . . 17
99 B.2. Resource maps . . . . . . . . . . . . . . . . . . . . . . 17
100 B.3. Fragmenting . . . . . . . . . . . . . . . . . . . . . . . 18
101 B.4. Relation to Content Encryption . . . . . . . . . . . . . . 18
102 B.5. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 19
103 Appendix C. Change Log (to be removed by RFC Editor before
104 publication) . . . . . . . . . . . . . . . . . . . . 19
105 C.1. Changes since draft-reschke-http-oob-encoding-00 . . . . . 19
106 C.2. Changes since draft-reschke-http-oob-encoding-01 . . . . . 19
107 C.3. Changes since draft-reschke-http-oob-encoding-02 . . . . . 19
108 C.4. Changes since draft-reschke-http-oob-encoding-03 . . . . . 20
109 C.5. Changes since draft-reschke-http-oob-encoding-04 . . . . . 20
110 C.6. Changes since draft-reschke-http-oob-encoding-05 . . . . . 20
111 C.7. Changes since draft-reschke-http-oob-encoding-06 . . . . . 20
112 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 21
114 1. Introduction
116 This document describes an Hypertext Transfer Protocol (HTTP) content
117 coding (Section 3.1.2.1 of [RFC7231]) that can be used to describe
118 the location of a secondary resource that contains the payload.
120 The primary use case for this content coding is to enable origin
121 servers to securely delegate the delivery of content to a secondary
122 server that might be "closer" to the client (with respect to network
123 topology) and/or able to cache content ([SCD]), leveraging content
124 encryption ([ENCRYPTENC]).
126 2. Notational Conventions
128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
130 document are to be interpreted as described in [RFC2119].
132 This document reuses terminology used in the base HTTP
133 specifications, namely Section 2 of [RFC7230] and Section 3 of
134 [RFC7231].
136 3. 'Out-Of-Band' Content Coding
138 3.1. Overview
140 The 'Out-Of-Band' content coding is used to direct the recipient to
141 retrieve the actual message representation (Section 3 of [RFC7231])
142 from a secondary resource, such as a public cache:
144 1. Client performs a request
146 2. Received response specifies the 'out-of-band' content coding; the
147 payload of the response contains additional meta data, plus the
148 location of the secondary resource
150 3. Client performs GET request on secondary resource (usually again
151 via HTTP(s))
153 4. Secondary server provides payload
155 5. Client combines above representation with additional
156 representation metadata obtained from the primary resource
158 Client Secondary Server Origin Server
160 sends GET request with Accept-Encoding: out-of-band
161 (1) |---------------------------------------------------------\
162 status 200 and Content-Coding: out-of-band |
163 (2) <---------------------------------------------------------/
165 GET to secondary server
166 (3) |---------------------------\
167 payload |
168 (4) <---------------------------/
170 (5)
171 Client and combines payload received in (4)
172 with metadata received in (2).
174 3.2. Definitions
176 The name of the content coding is "out-of-band".
178 The payload format uses JavaScript Object Notation (JSON, [RFC7159]),
179 describing an object describing secondary resources; currently only
180 defining one member:
182 'sr' A REQUIRED string array containing at least one URI reference
183 (Section 4.1 of [RFC3986]) of a secondary resource (URI references
184 that are relative references are resolved against the URI of the
185 primary resource).
187 [[pext: This payload might be too simple in that there's no simple
188 way to annotate the secondary resources.]]
190 The payload format uses an array so that the origin server can
191 specify multiple secondary resources. The ordering within the array
192 reflects the origin server's preference (if any), with the most
193 preferred secondary resource location being first. Clients receiving
194 a response containing multiple URIs are free to choose which of these
195 to use.
197 In some cases, the origin server might want to specify a "fallback
198 URI"; identifying a secondary resource served by the origin server
199 itself, but otherwise equivalent "regular" secondary resources. Any
200 secondary resource hosted by the origin server can be considered to
201 be a "fallback"; origin servers will usually list them last in the
202 "sr" array so that they only will be used by clients when there is no
203 other choice.
205 New specifications can define new OPTIONAL header fields, thus
206 clients MUST ignore unknown fields. Extension specifications will
207 have to update this specification. [[anchor3: or we define a
208 registry]]
210 3.3. Processing Steps
212 Upon receipt of an 'out-of-band' encoded response, a client first
213 needs to obtain the secondary resource's presentation. This is done
214 using an HTTP GET request (independently of the original request
215 method).
217 In order to prevent any leakage of information, the GET request for
218 the secondary resource MUST only contain information provided by the
219 origin server or the secondary server itself, namely HTTP
220 authentication credentials ([RFC7235]) and cookies ([RFC6265]).
222 Furthermore, the request MUST include an "Origin" header field
223 indicating the origin of the original resource ([RFC6454], Section
224 7). The secondary server MUST verify that the specified origin is
225 authorized to retrieve the given payload (or otherwise return an
226 appropriate 4xx status code).
228 After receipt of the secondary resource's payload, the client then
229 reconstructs the original message by:
231 1. Unwrapping the encapsulated HTTP message by removing any transfer
232 and content codings.
234 2. Replacing/setting any response header fields from the primary
235 response except for framing-related information such as Content-
236 Length, Transfer-Encoding and Content-Encoding.
238 If the client is unable to retrieve the secondary resource's
239 representation (host can't be reached, non 2xx response status code,
240 payload failing integrity check, etc.), it can choose an alternate
241 secondary resource (if specified), try the fallback URI (if given),
242 or simply retry the request to the origin server without including
243 'out-of-band' in the Accept-Encoding request header field. In the
244 latter case, it can be useful to inform the origin server about what
245 problems were encountered when trying to access the secondary
246 resource; see Section 3.4 for details.
248 Note that although this mechanism causes the inclusion of external
249 content, it will not affect the application-level security properties
250 of the reconstructed message, such as its web origin ([RFC6454]).
252 The cacheability of the response for the secondary resource does not
253 affect the cacheability of the reconstructed response message, which
254 is the same as for the origin server's response.
256 Use of the 'out-of-band' coding is similar to HTTP redirects
257 ([RFC7231], Section 6.4) in that it can lead to cycles. Unless with
258 HTTP redirects, the client however is in full control: it does not
259 need to advertise support for the 'out-of-band' coding in requests
260 for secondary resources. Alternatively, it can protect itself just
261 like for HTTP redirects -- by limiting the number of indirections it
262 supports.
264 Note that because the server's response depends on the request's
265 Accept-Encoding header field, the response usually will need to be
266 declared to vary on that. See Section 7.1.4 of [RFC7231] and Section
267 2.3 of [RFC7232] for details.
269 3.4. Problem Reporting
271 When the client fails to obtain the secondary resource, it can be
272 useful to inform the origin server about the condition. This can be
273 accomplished by adding a "Link" header field ([RFC5988]) to a
274 subsequent request to the origin server, detailing the URI of the
275 secondary resource and the failure reason.
277 The following link extension relations are defined:
279 [[purl: purl.org seems to have turned read-only; we may need a
280 different way to mint identifiers]]
282 [[erwip: This is a rough proposal for an error reporting mechanism.
283 Is it good enough? Is it needed at all? Note that Alt-Svc doesn't
284 have anything like this.]]
286 3.4.1. Server Not Reachable
288 Used in case the server was not reachable.
290 Link relation:
292 http://purl.org/NET/linkrel/not-reachable
294 3.4.2. Resource Not Found
296 Used in case the server responded, but the object could not be
297 obtained.
299 Link relation:
301 http://purl.org/NET/linkrel/resource-not-found
303 3.4.3. Payload Unusable
305 Used in case the payload could be obtained, but wasn't usable (for
306 instance, because integrity checks failed).
308 Link relation:
310 http://purl.org/NET/linkrel/payload-unusable
312 3.4.4. TLS Handshake Failure
314 Used in case of a TLS handshare failure ([RFC5246]).
316 Link relation:
318 http://purl.org/NET/linkrel/tls-handshake-failure
320 3.5. Examples
322 3.5.1. Basic Example
324 Client request of primary resource at https://www.example.com/test:
326 GET /test HTTP/1.1
327 Host: www.example.com
328 Accept-Encoding: gzip, out-of-band
330 Response:
332 HTTP/1.1 200 OK
333 Date: Thu, 14 May 2015 18:52:00 GMT
334 Content-Type: text/plain
335 Cache-Control: max-age=10, public
336 Content-Encoding: out-of-band
337 Content-Length: 133
338 Vary: Accept-Encoding
340 {
341 "sr": [
342 "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00",
343 "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"
344 ]
345 }
347 (note that the Content-Type header field describes the media type of
348 the secondary's resource representation, and the origin server
349 supplied a fallback URI)
350 Client request for secondary resource:
352 GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1
353 Host: example.net
354 Origin: https://www.example.com
356 Response:
358 HTTP/1.1 200 OK
359 Date: Thu, 14 May 2015 18:52:10 GMT
360 Cache-Control: private
361 Content-Length: 15
363 Hello, world.
365 (Note no Content-Type header field is present here because the
366 secondary server truly does not know the media type of the payload)
368 Final message after recombining header fields:
370 HTTP/1.1 200 OK
371 Date: Thu, 14 May 2015 18:52:00 GMT
372 Content-Length: 15
373 Cache-Control: max-age=10, public
374 Content-Type: text/plain
376 Hello, world.
378 3.5.2. Example for an attempt to use 'out-of-band' cross-origin
380 Section 3.3 requires the client to include an "Origin" header field
381 in the request to a secondary server. The example below shows how
382 the server for the secondary resource would respond to a request
383 which contains an "Origin" header field identifying an unauthorized
384 origin.
386 Continuing with the example from Section 3.5.1, and a secondary
387 server that is configured to allow only access for requests initiated
388 by "https://www.example.org":
390 Client request for secondary resource:
392 GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1
393 Host: example.net
394 Origin: https://www.example.com
396 Response:
398 HTTP/1.1 403 Forbidden
399 Date: Thu, 14 May 2015 18:52:10 GMT
401 Note that a request missing the "Origin" header field would be
402 treated the same way.
404 [[anchor6: Any reason why to *mandate* a specific 4xx code?]]
406 3.5.3. Example involving an encrypted resource
408 Given the example HTTP message from Section 5.4 of [ENCRYPTENC], a
409 primary resource could use the 'out-of-band' coding to specify just
410 the location of the secondary resource plus the contents of the
411 "Crypto-Key" header field needed to decrypt the payload:
413 Response:
415 HTTP/1.1 200 OK
416 Date: Thu, 14 May 2015 18:52:00 GMT
417 Content-Encoding: aesgcm, out-of-band
418 Content-Type: text/plain
419 Encryption: keyid="a1"; salt="vr0o6Uq3w_KDWeatc27mUg"
420 Crypto-Key: keyid="a1"; aesgcm="csPJEXBYA5U-Tal9EdJi-w"
421 Content-Length: 85
422 Vary: Accept-Encoding
424 {
425 "sr": [
426 "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"
427 ]
428 }
430 (note that the Content-Type header field describes the media type of
431 the secondary's resource representation)
433 Response for secondary resource:
435 HTTP/1.1 200 OK
436 Date: Thu, 14 May 2015 18:52:10 GMT
437 Content-Length: ...
439 VDeU0XxaJkOJDAxPl7h9JD5V8N43RorP7PfpPdZZQuwF
440 (payload body shown in base64 here)
441 Final message undoing all content codings:
443 HTTP/1.1 200 OK
444 Date: Thu, 14 May 2015 18:52:00 GMT
445 Content-Length: 15
446 Content-Type: text/plain
448 I am the walrus
450 Note: in this case, the ability to undo the 'aesgcm' is needed to
451 process the response. If 'aesgcm' wasn't listed as acceptable
452 content coding in the request, the origin server wouldn't be able
453 to use the 'out-of-band' mechanism.
455 3.5.4. Example For Problem Reporting
457 Client requests primary resource as in Section 3.5.1, but the attempt
458 to access the secondary resource fails.
460 Response:
462 HTTP/1.1 404 Not Found
463 Date: Thu, 08 September 2015 16:49:00 GMT
464 Content-Type: text/plain
465 Content-Length: 20
467 Resource Not Found
469 Client retries with the origin server and includes Link header field
470 reporting the problem:
472 GET /test HTTP/1.1
473 Host: www.example.com
474 Accept-Encoding: gzip, out-of-band
475 Link: ;
476 rel="http://purl.org/NET/linkrel/resource-not-found"
478 3.5.5. Relation to Content Negotiation
480 Use of the 'out-of-band' encoding is a case of "proactive content
481 negotiation", as defined in Section 3.4 of [RFC7231].
483 This however does not rule out combining it with other content
484 codings. As an example, the possible iteractions with the 'gzip'
485 content coding ([RFC7230], Section 4.2.3) are described below:
487 Case 1: Primary resource does not support 'gzip' encoding
488 In this case, the response for the primary resource will never
489 include 'gzip' in the Content-Encoding header field. The secondary
490 resource however might support it, in which case the client could
491 negotiate compression by including "Accept-Encoding: gzip" in the
492 request to the secondary resource.
494 Case 2: Primary resource does support 'gzip' encoding
496 Here, the origin server would actually use two different secondary
497 resources, one of them being gzip-compressed. For instance -- going
498 back to the first example in Section 3.5.1 -- it might reply with:
500 HTTP/1.1 200 OK
501 Date: Thu, 14 May 2015 18:52:00 GMT
502 Content-Type: text/plain
503 Cache-Control: max-age=10, public
504 Content-Encoding: gzip, out-of-band
505 Content-Length: 133
506 Vary: Accept-Encoding
508 {
509 "sr": [
510 "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a01",
511 "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a01"
512 ]
513 }
515 which would mean that the payload for the secondary resource already
516 is gzip-compressed.
518 Note: The origin server could also apply gzip compression to the
519 out-of-band payload, in which case the Content-Encoding field
520 value would become: "gzip, out-of-band, gzip".
522 4. Content Codings and Range Requests
524 The combination of content codings ([RFC7231], Section 3.1.2 with
525 range requests ([RFC7233]) can lead to surprising results, as
526 applying the range request happens after applying content codings.
528 Thus, for a request for the bytes starting at position 100000 of a
529 video:
531 GET /test.mp4 HTTP/1.1
532 Host: www.example.com
533 Range: bytes=100000-
534 Accept-Encoding: identity
536 ...a successful response would use status code 206 (Partial Content)
537 and have a payload containing the octets starting at position 100000.
539 HTTP/1.1 206 Partial Content
540 Date: Thu, 08 September 2015 16:49:00 GMT
541 Content-Type: video/mp4
542 Content-Length: 134567
543 Content-Range: bytes 100000-234566/234567
545 (binary data)
547 However, if the request would have allowed the use of 'out-of-band'
548 coding:
550 GET /test.mp4 HTTP/1.1
551 Host: www.example.com
552 Range: bytes=100000-
553 Accept-Encoding: out-of-band
555 ...a server might return an empty payload (if the out-of-band coded
556 response body would be shorter than 100000 bytes, as would be usually
557 the case).
559 Thus, in order to avoid unnecessary network traffic, servers SHOULD
560 NOT apply range request processing to responses using ouf-of-band
561 content coding (or, in other words: ignore "Range" request header
562 fields in this case).
564 5. Feature Discovery
566 New content codings can be deployed easily, as the client can use the
567 "Accept-Encoding" header field (Section 5.3.4 of [RFC7231]) to signal
568 which content codings are supported.
570 6. Security Considerations
572 6.1. Content Modifications
574 This specification does not define means to verify that the payload
575 obtained from the secondary resource really is what the origin server
576 expects it to be. Content signatures can address this concern (see
577 [CONTENTSIG] and [MICE]).
579 6.2. Content Stealing
581 The 'out-of-band' content coding could be used to circumvent the
582 same-origin policy ([RFC6454], Section 3) of user agents: an
583 attacking site which knows the URI of a secondary resource would use
584 the 'out-of-band' coding to trick the user agent to read the contents
585 of the secondary resource, which then, due to the security properties
586 of this coding, would be handled as if it originated from the
587 origin's resource.
589 This scenario is addressed by the client requirement to include the
590 "Origin" request header field and the server requirement to verify
591 that the request was initiated by an authorized origin.
593 Note: similarities with the "Cross-Origin Resource Sharing"
594 protocol ([CORS]) are intentional.
596 Requiring the secondary resource's payload to be encrypted
597 ([ENCRYPTENC]) is an additional mitigation.
599 6.3. Use in Requests
601 In general, content codings can be used in both requests and
602 responses. This particular content coding has been designed for
603 responses. When supported in requests, it creates a new attack
604 vector where the receiving server can be tricked into including
605 content that the client might not have access to otherwise (such as
606 HTTP resources behind a firewall).
608 7. IANA Considerations
610 The IANA "HTTP Content Coding Registry", located at
611 , needs to be
612 updated with the registration below:
614 Name: out-of-band
616 Description: Payload needs to be retrieved from a secondary resource
618 Reference: Section 3 of this document
620 8. References
622 8.1. Normative References
624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
625 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
626 RFC2119, March 1997,
627 .
629 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
630 "Uniform Resource Identifier (URI): Generic Syntax",
631 STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
632 .
634 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/
635 RFC5988, October 2010,
636 .
638 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
639 DOI 10.17487/RFC6265, April 2011,
640 .
642 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
643 Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
644 March 2014, .
646 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
647 Transfer Protocol (HTTP/1.1): Message Syntax and
648 Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014,
649 .
651 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
652 Transfer Protocol (HTTP/1.1): Semantics and Content",
653 RFC 7231, DOI 10.17487/RFC7231, June 2014,
654 .
656 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
657 Transfer Protocol (HTTP/1.1): Authentication",
658 RFC 7235, DOI 10.17487/RFC7235, June 2014,
659 .
661 8.2. Informative References
663 [CONTENTSIG] Thomson, M., "Content-Signature Header Field for HTTP",
664 draft-thomson-http-content-signature-00 (work in
665 progress), July 2015.
667 [CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C
668 Recommendation REC-cors-20140116, January 2014,
669 .
671 Latest version available at
672 .
674 [ENCRYPTENC] Thomson, M., "Encrypted Content-Encoding for HTTP",
675 draft-ietf-httpbis-encryption-encoding-02 (work in
676 progress), June 2016.
678 [MICE] Thomson, M., "Merkle Integrity Content Encoding",
679 draft-thomson-http-mice-01 (work in progress),
680 June 2016.
682 [RFC2017] Freed, N. and K. Moore, "Definition of the URL MIME
683 External-Body Access-Type", RFC 2017, DOI 10.17487/
684 RFC2017, October 1996,
685 .
687 [RFC4483] Burger, E., "A Mechanism for Content Indirection in
688 Session Initiation Protocol (SIP) Messages", RFC 4483,
689 DOI 10.17487/RFC4483, May 2006,
690 .
692 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
693 Security (TLS) Protocol Version 1.2", RFC 5246,
694 DOI 10.17487/RFC5246, August 2008,
695 .
697 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
698 DOI 10.17487/RFC6454, December 2011,
699 .
701 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
702 Transfer Protocol (HTTP/1.1): Conditional Requests",
703 RFC 7232, DOI 10.17487/RFC7232, June 2014,
704 .
706 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
707 "Hypertext Transfer Protocol (HTTP/1.1): Range
708 Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014,
709 .
711 [SCD] Thomson, M., Eriksson, G., and C. Holmberg, "An
712 Architecture for Secure Content Delegation using HTTP",
713 draft-thomson-http-scd-01 (work in progress),
714 June 2016.
716 URIs
718 [1]
720 [2]
722 Appendix A. Alternatives, or: why not a new Status Code?
724 A plausible alternative approach would be to implement this
725 functionality one level up, using a new redirect status code (Section
726 6.4 of [RFC7231]). However, this would have several drawbacks:
728 o Servers will need to know whether a client understands the new
729 status code; thus some additional signal to opt into this protocol
730 would always be needed.
732 o In redirect messages, representation metadata (Section 3.1 of
733 [RFC7231]), namely "Content-Type", applies to the response
734 message, not the redirected-to resource.
736 o The origin-preserving nature of using a content coding would be
737 lost.
739 Another alternative would be to implement the indirection on the
740 level of the media type using something similar to the type "message/
741 external-body", defined in [RFC2017] and refined for use in the
742 Session Initiation Protocol (SIP) in [RFC4483]. This approach though
743 would share most of the drawbacks of the status code approach
744 mentioned above.
746 Appendix B. Open Issues
748 B.1. Accessing the Secondary Resource Too Early
750 One use-case for this protocol is to enable a system of "blind
751 caches", which would serve the secondary resources. These caches
752 might only be populated on demand, thus it could happen that whatever
753 mechanism is used to populate the cache hasn't finished when the
754 client hits it (maybe due to race conditions, or because the cache is
755 behind a middlebox which doesn't allow the origin server to push
756 content to it).
758 In this particular case, it can be useful if the client was able to
759 "piggyback" the URI of the fallback for the primary resource, giving
760 the secondary server a means by which it could obtain the payload
761 itself. This information could be provided in yet another Link
762 header field:
764 GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1
765 Host: example.net
766 Link: ;
767 rel="http://purl.org/NET/linkrel/fallback-resource"
769 (continuing the example from Section 3.5.1)
771 B.2. Resource maps
773 When 'out-of-band' coding is used as part of a caching solution, the
774 additional round trips to the origin server can be a significant
775 performance problem; in particular, when many small resources need to
776 be loaded (such as scripts, images, or video fragments). In cases
777 like these, it could be useful for the origin server to provide a
778 "resource map", allowing to skip the round trips to the origin server
779 for these mapped resources. Plausible ways to transmit the resource
780 map could be:
782 o as extension in the 'out-of-band' coding JSON payload, or
784 o as separate resource identified by a "Link" response header field.
786 This specification does not define a format, nor a mechanism to
787 transport the map, but it's a given that some specification using
788 'out-of-band' coding will do.
790 B.3. Fragmenting
792 It might be interesting to divide the original resource's payload
793 into fragments, each of which being mapped to a distinct secondary
794 resource. This would allow to not store the full payload of a
795 resource in a single cache, thus
797 o distribute load,
799 o caching different parts of the resource with different
800 characteristics (such as only distribute the first minutes of a
801 long video), or
803 o fetching specific parts of a resource (similar to byte range
804 requests), or
806 o hiding information from the secondary server.
808 Another benefit might be that it would allow the origin server to
809 only serve the first part of a resource itself (reducing time to play
810 of a media resource), while delegating the remainder to a cache
811 (however, this might require further adjustments of the 'out-of-band'
812 payload format).
814 B.4. Relation to Content Encryption
816 Right now this specification is orthogonal to [ENCRYPTENC]/[MICE];
817 that is, it could be used for public content such as software
818 downloads. However, the lack of mandatory encryption affects the
819 security considerations (which currently try to rule attack vectors
820 caused by ambient authority ([RFC6265], Section 8.2). We need to
821 decide whether we need this level of independence.
823 B.5. Reporting
825 This specification already defines hooks through which a client can
826 report failures when accessing secondary resources (see Section 3.4).
828 However, it would be useful if there were also ways to report on
829 statistics such as:
831 o Success (Cache Hit) rates, and
833 o Bandwidth to secondary servers.
835 This could be implemented using a new service endpoint and a (JSON?)
836 payload format.
838 Similarly, a reporting facility for use by the secondary servers
839 could be useful.
841 Appendix C. Change Log (to be removed by RFC Editor before publication)
843 C.1. Changes since draft-reschke-http-oob-encoding-00
845 Mention media type approach.
847 Explain that clients can always fall back not to use oob when the
848 secondary resource isn't available.
850 Add Vary response header field to examples and mention that it'll
851 usually be needed
852 ().
854 Experimentally add problem reporting using piggy-backed Link header
855 fields ().
857 C.2. Changes since draft-reschke-http-oob-encoding-01
859 Updated ENCRYPTENC reference.
861 C.3. Changes since draft-reschke-http-oob-encoding-02
863 Add MICE reference.
865 Remove the ability of the secondary resource to contain anything but
866 the payload ().
868 Changed JSON payload to be an object containing an array of URIs plus
869 additional members. Specify "fallback" as one of these additional
870 members, and update Appendix B.1 accordingly).
872 Discuss extensibility a bit.
874 C.4. Changes since draft-reschke-http-oob-encoding-03
876 Mention "Content Stealing" thread.
878 Mention padding.
880 C.5. Changes since draft-reschke-http-oob-encoding-04
882 Reduce information leakage by disallowing ambient authority
883 information being sent to the secondary resource. Require "Origin"
884 to be included in request to secondary resource, and require
885 secondary server to check it.
887 Mention "Origin" + server check on secondary resource as defense to
888 content stealing.
890 Update ENCRYPTENC reference, add SCD reference.
892 Mention fragmentation feature.
894 Discuss relation with range requests.
896 C.6. Changes since draft-reschke-http-oob-encoding-05
898 Remove redundant Cache-Control: private from one example response
899 (the response payload is encrypted anyway).
901 Mention looping.
903 Remove 'metadata' payload element.
905 Align with changes in ENCRYPTENC spec.
907 Fix incorrect statement about what kind of cookies/credentials can be
908 used in the request to the secondary resource.
910 Rename "URIs" to "sr" ("secondary resources") and treat the fallback
911 URI like a regular secondary resource.
913 Mention reporting protocol ideas.
915 C.7. Changes since draft-reschke-http-oob-encoding-06
917 Changed the link relation name to the fallback resource from
918 "primary" to "fallback". Added link relation for reporting TLS
919 handshake failures.
921 Added an example about the interaction with 'gzip' coding.
923 Update ENCRYPTENC, MICE, and SCD references.
925 Appendix D. Acknowledgements
927 Thanks to Christer Holmberg, Daniel Lindstrom, Erik Nygren, Goran
928 Eriksson, John Mattsson, Kevin Smith, Magnus Westerlund, Mark
929 Nottingham, Martin Thomson, and Roland Zink for feedback on this
930 document.
932 Authors' Addresses
934 Julian F. Reschke
935 greenbytes GmbH
936 Hafenweg 16
937 Muenster, NW 48155
938 Germany
940 EMail: julian.reschke@greenbytes.de
941 URI: http://greenbytes.de/tech/webdav/
943 Salvatore Loreto
944 Ericsson
945 Torshamnsgatan 21
946 Stochholm 16483
947 Sweden
949 EMail: salvatore.loreto@ericsson.com