One document matched: draft-reschke-http-oob-encoding-05.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
    This XML document is the output of clean-for-DTD.xslt; a tool that strips
    extensions to RFC2629(bis) from documents for processing with xml2rfc.
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<!DOCTYPE rfc
  PUBLIC "" "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-reschke-http-oob-encoding-05" category="std">

  

	<front>
  <title>'Out-Of-Band' Content Coding for HTTP</title>
  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
    <organization abbrev="greenbytes">greenbytes GmbH</organization>
    <address>
      <postal>
        <street>Hafenweg 16</street>
        <city>Muenster</city><region>NW</region><code>48155</code>
        <country>Germany</country>
      </postal>
      <email>julian.reschke@greenbytes.de</email>
      <uri>http://greenbytes.de/tech/webdav/</uri>
    </address>
  </author>
  <author initials="S." surname="Loreto" fullname="Salvatore Loreto">
    <organization>Ericsson</organization>
    <address>
        <postal>
          <street>Torshamnsgatan 21</street>
          <code>16483</code>
          <city>Stochholm</city>
          <country>Sweden</country>
        </postal>
        <email>salvatore.loreto@ericsson.com</email>
    </address>
  </author>

  <date year="2016" month="April" day="15"/>

  <area>Applications and Real-Time</area>
  <keyword>HTTP</keyword>
  <keyword>content coding</keyword>
  <keyword>ouf-of-band</keyword>

  <abstract>
    <t>
      This document describes an Hypertext Transfer Protocol (HTTP) content
      coding that can be used to describe the location of a secondary resource
      that contains the payload.
    </t>
  </abstract>

  <note title="Editorial Note (To be removed by RFC Editor before publication)">
    <t>
      Distribution of this document is unlimited. Although this is not a work
      item of the HTTPbis Working Group, comments should be sent to the 
      Hypertext Transfer Protocol (HTTP) mailing list at <eref target="mailto:ietf-http-wg@w3.org">ietf-http-wg@w3.org</eref>,
      which may be joined by sending a message with subject 
      "subscribe" to <eref target="mailto:ietf-http-wg-request@w3.org?subject=subscribe">ietf-http-wg-request@w3.org</eref>.
    </t>
    <t>
      Discussions of the HTTPbis Working Group are archived at
      <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.               
    </t>
    <t>
      XML versions, latest edits, and issue tracking for this document
      are available from <eref target="https://github.com/reschke/oobencoding"/> and
      <eref target="http://greenbytes.de/tech/webdav/#draft-reschke-http-oob-encoding"/>.
    </t>
    <t>
      The changes in this draft are summarized in <xref target="changes.since.04"/>.
    </t>
  </note>

  </front>

  <middle>

<section anchor="introduction" title="Introduction">
<t>
  This document describes an Hypertext Transfer Protocol (HTTP) content
  coding (Section 3.1.2.1 of <xref target="RFC7231"/>) that can be used
  to describe the location of a secondary resource that contains the payload.
</t>
<t>
  The primary use case for this content coding is to enable origin servers
  to securely delegate the delivery of content to a secondary server that might
  be "closer" to the client (with respect to network topology) and/or
  able to cache content (<xref target="SCD"/>), leveraging content encryption
  (<xref target="ENCRYPTENC"/>).
</t>
</section>

<section anchor="notational.conventions" title="Notational Conventions">
<t>
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
<t>
   This document reuses terminology used in the base HTTP specifications,
   namely Section 2 of <xref target="RFC7230"/> and
   Section 3 of <xref target="RFC7231"/>.
</t>
</section>

<section anchor="ouf-of-band.content.coding" title="'Out-Of-Band' Content Coding">
<section title="Overview">
<t>
  The 'Out-Of-Band' content coding is used to direct the recipient to retrieve the
  actual message representation (Section 3 of <xref target="RFC7231"/>)
  from a secondary resource, such as a public cache:
</t>
<t><list style="numbers">
  <t anchor="flow.get.request">Client performs a request</t>
  <t anchor="flow.get.response">Received response specifies the 'out-of-band' content coding; the payload
  of the response contains additional meta data, plus the location of the secondary
  resource</t>
  <t anchor="flow.get.request2">Client performs GET request on secondary resource (usually again via HTTP(s))</t>
  <t anchor="flow.get.response2">Secondary server provides payload</t>
  <t anchor="flow.combine">Client combines above representation with additional representation metadata
  obtained from the primary resource</t>
</list></t>
<figure><artwork type="drawing"><![CDATA[
  Client                  Secondary Server           Origin Server

     sends GET request with Accept-Encoding: out-of-band
(1) |---------------------------------------------------------\
                   status 200 and Content-Coding: out-of-band |
(2) <---------------------------------------------------------/

     GET to secondary server
(3) |---------------------------\
                        payload |
(4) <---------------------------/

(5)
   Client and combines payload received in (4)
   with metadata received in (2).]]></artwork></figure>
</section>
<section title="Definitions">
<t>
  The name of the content coding is "out-of-band". 
</t>
<t>
  The payload format uses JavaScript Object Notation (JSON, <xref target="RFC7159"/>),
  describing an object describing secondary resources plus OPTIONAL additional
  metadata:
</t>
<t><?rfc subcompact='no'?><list style="hanging"><t hangText="'URIs'">
    A REQUIRED string array containing at least one URI reference (Section 4.1 of <xref target="RFC3986"/>) of a secondary resource.
  </t><t hangText="'fallback'">
    An OPTIONAL string containing a URI reference of a fallback resource (see <xref target="fallback"/>).
    This URI reference, after resolution against the URI of the primary resource, MUST identify
    a resource on the same server as the primary resource.
  </t><t hangText="'metadata'">
    An OPTIONAL object containing additional members, representing header field values
    which can not appear as header fields in the response message itself 
    (header fields that occur multiple times need to be combined into a single field value as
    per Section 3.2.2 of <xref target="RFC7230"/>; header field names are lower-cased).
  </t></list></t>
<t>
  The payload format uses a JSON array so that the origin server can specify
  multiple secondary resources. When a client receives a response containing
  multiple URIs, it is free to choose which of these to use.
</t>
<t>
  New specifications can define new OPTIONAL header fields, thus clients
  MUST ignore unknown fields. Extension specifications will have to update this
  specification. <cref>or we define a registry</cref>
</t>
</section>
<section anchor="processing" title="Processing Steps">
<t>
  Upon receipt of an out-of-band encoded response, a client first needs to
  obtain the secondary resource's presentation. This is done using
  an HTTP GET request (independantly of the original request method).
</t>
<t>
  In order to prevent any leakage of information, the GET request for
  the secondary resource MUST NOT contain any information provided by
  origins other than the secondary server itself, namely HTTP authentication
  credentials (<xref target="RFC7235"/>) and cookies (<xref target="RFC6265"/>).
</t>
<t>
  Furthermore, the request MUST include an "Origin" header field indicating
  the origin of the original resource (<xref target="RFC6454"/>, Section 7).
  The secondary server MUST verify that the specified origin is
  authorized to retrieve the given payload (or otherwise return an 
  appropriate 4xx status code).
</t>
<t>
  After receipt of the secondary resource's payload, the client then 
  reconstructs the original message by:
</t>
<t><list style="numbers">
  <t>
    Unwrapping the encapsulated HTTP message by removing any transfer and content codings.
  </t>
  <t>
    Replacing/setting any response header fields from the primary
    response except for framing-related information such as
    Content-Length, Transfer-Encoding and Content-Encoding.
  </t>
  <t>
    Replacing/setting any header fields with those present as members
    in the "metadata" object.
    <cref>Do we have a use case for this?</cref>
  </t>
</list></t>
<t>
  If the client is unable to retrieve the secondary resource's representation
  (host can't be reached, non 2xx response status code, payload failing
  integrity check, etc.), it can choose
  an alternate secondary resource (if specified), try the fallback URI (if
  given), or simply retry the
  request to the origin server without including "out-of-band" in the
  Accept-Encoding request header field. In the latter case, it can be useful
  to inform the origin server about what problems were encountered
  when trying to access the secondary resource; see <xref target="problem.reporting"/>
  for details.
</t>
<t>
  Note that although this mechanism causes the inclusion of external
  content, it will not affect the application-level security properties
  of the reconstructed message, such as its web origin (<xref target="RFC6454"/>).
</t>
<t>
  The cacheability of the response for the secondary resource does not affect 
  the cacheability of the reconstructed response message, which is the same as
  for the origin server's response.
</t>
<t>
  Note that because the server's response depends on the request's Accept-Encoding
  header field, the response usually will need to be declared to vary on that. See
  Section 7.1.4 of <xref target="RFC7231"/> and
  Section 2.3 of <xref target="RFC7232"/> for details.
</t>
</section>

<section anchor="problem.reporting" title="Problem Reporting">
<t>
  When the client fails to obtain the secondary resource, it can be useful
  to inform the origin server about the condition. This can be accomplished
  by adding a "Link" header field (<xref target="RFC5988"/>) to a subsequent request to the origin server,
  detailing the URI of the secondary resource and the failure reason.
</t>
<t>
  The following link extension relations are defined:
</t>

<section anchor="rel-not-reachable" title="Server Not Reachable">
<t>
  Used in case the server was not reachable.
</t>
<figure>
<preamble>Link relation:</preamble>
<artwork type="example"><![CDATA[
http://purl.org/NET/linkrel/not-reachable]]></artwork>
</figure>
</section>

<section anchor="rel-resource-not-found" title="Resource Not Found">
<t>
  Used in case the server responded, but the object could not be obtained.
</t>
<figure>
<preamble>Link relation:</preamble>
<artwork type="example"><![CDATA[
http://purl.org/NET/linkrel/resource-not-found]]></artwork>
</figure>
</section>

<section anchor="rel-payload-unusable" title="Payload Unusable">
<t>
  Used in case the the payload could be obtained, but wasn't usable
  (for instance, because integrity checks failed).
</t>
<figure>
<preamble>Link relation:</preamble>
<artwork type="example"><![CDATA[
http://purl.org/NET/linkrel/payload-unusable]]></artwork>
</figure>
</section>

</section>

<section title="Examples">
<section anchor="basic.example" title="Basic Example">
<figure>
<preamble>Client request of primary resource at https://www.example.com/test:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  GET /test HTTP/1.1
  Host: www.example.com
  Accept-Encoding: gzip, out-of-band
  
  ]]></artwork></figure>
<figure>
<preamble>Response:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  HTTP/1.1 200 OK
  Date: Thu, 14 May 2015 18:52:00 GMT
  Content-Type: text/plain
  Cache-Control: max-age=10, public
  Content-Encoding: out-of-band
  Content-Length: 145
  Vary: Accept-Encoding
  
  {
    "URIs": [
      "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"
    ],
    "fallback": "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"
  }
  ]]></artwork>
<postamble>
  (note that the Content-Type header field describes the media type of the
  secondary's resource representation, and the origin server supplied
  a fallback URI)
</postamble>
</figure>
<figure>
<preamble>Client request for secondary resource:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1
  Host: example.net
  Origin: https://www.example.com
  
  ]]></artwork></figure>
<figure>
<preamble>Response:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  HTTP/1.1 200 OK
  Date: Thu, 14 May 2015 18:52:10 GMT
  Cache-Control: private
  Content-Length: 15
  
  Hello, world.
  ]]></artwork>
<postamble>(Note no Content-Type header field is present here because the 
secondary server truly does not know the media type of the payload)</postamble>
</figure>
<figure>
<preamble>Final message after recombining header fields:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  HTTP/1.1 200 OK
  Date: Thu, 14 May 2015 18:52:00 GMT
  Content-Length: 15
  Cache-Control: max-age=10, public
  Content-Type: text/plain
  
  Hello, world.
  ]]></artwork>
</figure>
</section>

<section title="Example for an attempt to use out-of-band cross-origin">
<t>
  <xref target="processing"/> requires the client to include an "Origin"
  header field in the request to a secondary server. The example below
  shows how the server for the secondary resource would respond to a request
  which contains an "Origin" header field identifying an unauthorized origin.
</t>
<t>
  Continuing with the example from <xref target="basic.example"/>,
  and a secondary server that is configured to allow only access for requests 
  initiated by "https://www.example.org":
</t>
<figure>
<preamble>Client request for secondary resource:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1
  Host: example.net
  Origin: https://www.example.com
  
  ]]></artwork></figure>
<figure>
<preamble>Response:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  HTTP/1.1 403 Forbidden
  Date: Thu, 14 May 2015 18:52:10 GMT
  
  ]]></artwork>
<postamble>Note that a request missing the "Origin" header field would be
treated the same way.
</postamble>
</figure>
<t>
  <cref>Any reason why to *mandate* a specific 4xx code?</cref>
</t>
</section>

<section title="Example involving an encrypted resource">
<t>
  Given the example HTTP message from Section 5.4 of <xref target="ENCRYPTENC"/>,
  a primary resource could use the "out-of-band" encoding to specify just
  the location of the secondary resource plus the contents of the 
  "Crypto-Key" header field needed to decrypt the payload: 
</t>
<figure>
<preamble>Response:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  HTTP/1.1 200 OK
  Date: Thu, 14 May 2015 18:52:00 GMT
  Content-Encoding: aesgcm128, out-of-band
  Content-Type: text/plain
  Encryption: keyid="a1"; salt="vr0o6Uq3w_KDWeatc27mUg"
  Crypto-Key: keyid="a1"; aesgcm128="csPJEXBYA5U-Tal9EdJi-w"
  Content-Length: 87
  Vary: Accept-Encoding
  
  {
    "URIs": [
      "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"
    ]
  }
  ]]></artwork>
<postamble>
  (note that the Content-Type header field describes the media type of the
  secondary's resource representation)
</postamble>
</figure>
<figure>
<preamble>Response for secondary resource:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  HTTP/1.1 200 OK
  Date: Thu, 14 May 2015 18:52:10 GMT
  Content-Length: ...
  Cache-Control: private
  
  fuag8ThIRIazSHKUqJ5OduR75UgEUuM76J8UFwadEvg]]></artwork>
<postamble>(payload body shown in base64 here)</postamble>
</figure>
<figure>
<preamble>Final message undoing all content codings:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  HTTP/1.1 200 OK
  Date: Thu, 14 May 2015 18:52:00 GMT
  Content-Length: 15
  Content-Type: text/plain
  
  I am the walrus]]></artwork>
</figure>
<t><list>
<t>
  Note: in this case, the ability to undo the "aescgm128" is needed
  to process the response. If "aescgm128" wasn't listed as acceptable content encoding
  in the request, the origin server wouldn't be able to use the "out-of-band"
  mechanism.
</t>
</list></t>
</section>

<section title="Example For Problem Reporting">
<t>
  Client requests primary resource as in <xref target="basic.example"/>, but the
  attempt to access the secondary resource fails.
</t>
<figure>
<preamble>Response:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  HTTP/1.1 404 Not Found
  Date: Thu, 08 September 2015 16:49:00 GMT
  Content-Type: text/plain
  Content-Length: 20
  
  Resource Not Found
  ]]></artwork>
</figure>
<figure>
<preamble>Client retries with the origin server and includes Link
header field reporting the problem:</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  GET /test HTTP/1.1
  Host: www.example.com
  Accept-Encoding: gzip, out-of-band
  Link: <http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00>;
        rel="http://purl.org/NET/linkrel/resource-not-found"
  
  ]]></artwork></figure>
</section>
</section>
</section>

<section title="Content Codings and Range Requests">
<t>
  The combination of content codings (<xref target="RFC7231"/>, Section 3.1.2 with
  range requests (<xref target="RFC7233"/>) can lead to surprising results, as
  applying the range request happens after applying content codings.
</t>
<figure>
<preamble>
  Thus, for a request for the bytes starting at position 100000 of a video:
</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  GET /test.mp4 HTTP/1.1
  Host: www.example.com
  Range: bytes=100000-
  Accept-Encoding: identity
  
  ]]></artwork></figure>
<figure>
<preamble>
  ...a successful response would use status code 206 (Partial Content) and
  have a payload containing the octets starting at position 100000.
</preamble>
<artwork type="message/http; msgtype="response""><![CDATA[
  HTTP/1.1 206 Partial Content
  Date: Thu, 08 September 2015 16:49:00 GMT
  Content-Type: video/mp4
  Content-Length: 134567
  Content-Range: bytes 100000-234566/234567
  
  (binary data)]]></artwork>
</figure>
<figure>
<preamble>
  However, if the request would have allowed the use of out-of-band encoding:
</preamble>
<artwork type="message/http; msgtype="request""><![CDATA[
  GET /test.mp4 HTTP/1.1
  Host: www.example.com
  Range: bytes=100000-
  Accept-Encoding: out-of-band
  
  ]]></artwork>
<postamble>...a server might return an empty payload (if the out-of-band
encoded response body would be shorter than 100000 bytes, as would be usually the case).</postamble>
</figure>
<t>
  Thus, in order to avoid unnecessary network traffic, servers SHOULD NOT
  apply range request processing to responses using ouf-of-band content coding
  (or, in other words: ignore "Range" request header fields in this case).
</t>
</section>

<section anchor="feature.discovery" title="Feature Discovery">
<t>
  New content codings can be deployed easily, as the client can use
  the "Accept-Encoding" header field (Section 5.3.4 of <xref target="RFC7231"/>)
  to signal which content codings are supported.
</t>
</section>

<section anchor="security.considerations" title="Security Considerations">
<section title="Content Modifications">
<t>
  This specification does not define means to verify that the payload
  obtained from the secondary resource really is what the origin server
  expects it to be. Content signatures can address this concern
  (see <xref target="CONTENTSIG"/> and <xref target="MICE"/>).
</t>
</section>
<section title="Content Stealing">
<t>
  The Out-Of-Band content coding could be used to circumvent the same-origin
  policy (<xref target="RFC6454"/>, Section 3) of user agents: an
  attacking site which knows the URI of a secondary resource would use the
  out-of-band coding to trick the user agent to read the contents of the secondary resource,
  which then, due to the security properties of out-of-band codings, would be
  handled as if it originated from the origin's resource.
</t>
<t>
  This scenario is addressed by the client requirement to include
  the "Origin" request header field and the server requirement to verify
  that the request was initiated by an authorized origin.
</t>
<t><list>
  <t>
    Note: similarities with the "Cross-Origin Resource Sharing"
    protocol (<xref target="CORS"/>) are intentional.
  </t>
</list></t>
<t>
  Requiring the secondary resource's payload to be encrypted (<xref target="ENCRYPTENC"/>)
  is an additional mitigation.
</t>
</section>
<section title="Use in Requests">
<t>
  In general, content codings can be used in both requests and responses. This particular
  content coding has been designed for responses. When supported in requests, it
  creates a new attack vector where the receiving server can be tricked into
  including content that the client might not have access to otherwise
  (such as HTTP resources behind a firewall).
</t>
</section>
</section>

<section anchor="iana.considerations" title="IANA Considerations">
<t>
  The IANA "HTTP Content Coding Registry", located at <eref target="http://www.iana.org/assignments/http-parameters"/>,
  needs to be updated with the registration below:
</t>
<t><?rfc subcompact='no'?><list style="hanging"><t hangText="Name:">
    out-of-band
  </t><t hangText="Description:">
    Payload needs to be retrieved from a secondary resource
  </t><t hangText="Reference:">
    <xref target="ouf-of-band.content.coding"/> of this document
  </t></list></t>
</section>

  </middle>
  <back>

<references title="Normative References">

<reference anchor="RFC2119" target="http://www.rfc-editor.org/info/rfc2119"><front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author initials="S." surname="Bradner" fullname="Scott Bradner"/>
    <date month="March" year="1997"/>
  </front><seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="2119"/><seriesInfo name="DOI" value="10.17487/RFC2119"/></reference>

<reference anchor="RFC3986" target="http://www.rfc-editor.org/info/rfc3986"><front>
  <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"/>
  <author initials="R." surname="Fielding" fullname="Roy T. Fielding"/>
  <author initials="L." surname="Masinter" fullname="Larry Masinter"/>
  <date month="January" year="2005"/>
 </front><seriesInfo name="STD" value="66"/><seriesInfo name="RFC" value="3986"/><seriesInfo name="DOI" value="10.17487/RFC3986"/></reference>

<reference anchor="RFC5988" target="http://www.rfc-editor.org/info/rfc5988"><front>
    <title>Web Linking</title>
    <author initials="M." surname="Nottingham" fullname="M. Nottingham"/>
    <date year="2010" month="October"/>
  </front><seriesInfo name="RFC" value="5988"/><seriesInfo name="DOI" value="10.17487/RFC5988"/></reference>

<reference anchor="RFC6265" target="http://www.rfc-editor.org/info/rfc6265"><front>
    <title>HTTP State Management Mechanism</title>
    <author initials="A." surname="Barth" fullname="Adam Barth"/>
    <date year="2011" month="April"/>
  </front><seriesInfo name="RFC" value="6265"/><seriesInfo name="DOI" value="10.17487/RFC6265"/></reference>

<reference anchor="RFC7159" target="http://www.rfc-editor.org/info/rfc7159"><front>
    <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
    <author initials="T." surname="Bray" fullname="Tim Bray"/>
    <date year="2014" month="March"/>
  </front><seriesInfo name="RFC" value="7159"/><seriesInfo name="DOI" value="10.17487/RFC7159"/></reference>

<reference anchor="RFC7230" target="http://www.rfc-editor.org/info/rfc7230"><front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"/>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"/>
    <date month="June" year="2014"/>
  </front><seriesInfo name="RFC" value="7230"/><seriesInfo name="DOI" value="10.17487/RFC7230"/></reference>

<reference anchor="RFC7231" target="http://www.rfc-editor.org/info/rfc7231"><front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"/>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"/>
    <date month="June" year="2014"/>
  </front><seriesInfo name="RFC" value="7231"/><seriesInfo name="DOI" value="10.17487/RFC7231"/></reference>

<reference anchor="RFC7235" target="http://www.rfc-editor.org/info/rfc7235"><front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"/>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"/>
    <date month="June" year="2014"/>
  </front><seriesInfo name="RFC" value="7235"/><seriesInfo name="DOI" value="10.17487/RFC7235"/></reference>

</references>

<references title="Informative References">

<reference anchor="RFC2017" target="http://www.rfc-editor.org/info/rfc2017"><front>
    <title abbrev="URL Access-Type">Definition of the URL MIME External-Body Access-Type</title>
    <author initials="N." surname="Freed" fullname="Ned Freed"/>
    <author initials="K." surname="Moore" fullname="Keith Moore"/>
    <date year="1996" month="October"/>
  </front><seriesInfo name="RFC" value="2017"/><seriesInfo name="DOI" value="10.17487/RFC2017"/></reference>

<reference anchor="RFC4483" target="http://www.rfc-editor.org/info/rfc4483"><front>
    <title>A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages</title>
    <author initials="E." surname="Burger" fullname="E. Burger"/>
    <date year="2006" month="May"/>
  </front><seriesInfo name="RFC" value="4483"/><seriesInfo name="DOI" value="10.17487/RFC4483"/></reference>

<reference anchor="RFC6454" target="http://www.rfc-editor.org/info/rfc6454"><front>
    <title>The Web Origin Concept</title>
    <author initials="A." surname="Barth" fullname="A. Barth"/>
    <date year="2011" month="December"/>
  </front><seriesInfo name="RFC" value="6454"/><seriesInfo name="DOI" value="10.17487/RFC6454"/></reference>

<reference anchor="RFC7232" target="http://www.rfc-editor.org/info/rfc7232"><front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"/>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"/>
    <date month="June" year="2014"/>
  </front><seriesInfo name="RFC" value="7232"/><seriesInfo name="DOI" value="10.17487/RFC7232"/></reference>

<reference anchor="RFC7233" target="http://www.rfc-editor.org/info/rfc7233"><front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"/>
    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"/>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"/>
    <date month="June" year="2014"/>
  </front><seriesInfo name="RFC" value="7233"/><seriesInfo name="DOI" value="10.17487/RFC7233"/></reference>

<reference anchor="ENCRYPTENC"><front>
    <title>Encrypted Content-Encoding for HTTP</title>
    <author initials="M." surname="Thomson" fullname="Martin Thomson"/>
    <date month="March" year="2016"/>
  </front><seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-encryption-encoding-01"/></reference>

<reference anchor="CONTENTSIG"><front>
    <title>Content-Signature Header Field for HTTP</title>
    <author initials="M." surname="Thomson" fullname="Martin Thomson"/>
    <date month="July" year="2015"/>
  </front><seriesInfo name="Internet-Draft" value="draft-thomson-http-content-signature-00"/></reference>

<reference anchor="MICE"><front>
    <title>Merkle Integrity Content Encoding</title>
    <author initials="M." surname="Thomson" fullname="Martin Thomson"/>
    <date month="January" year="2016"/>
  </front><seriesInfo name="Internet-Draft" value="draft-thomson-http-mice-00"/></reference>

<reference anchor="SCD"><front>
    <title>An Architecture for Secure Content Delegation using HTTP</title>
    <author initials="M." surname="Thomson" fullname="Martin Thomson"/>
    <author initials="G." surname="Eriksson" fullname="Goran Eriksson"/>
    <author initials="C." surname="Holmberg" fullname="Christer Holmberg"/>
    <date month="March" day="21" year="2016"/>  
  </front><seriesInfo name="Internet-Draft" value="draft-thomson-http-scd-00"/></reference>

<reference anchor="CORS" target="http://www.w3.org/TR/2014/REC-cors-20140116/"><front>
    <title>Cross-Origin Resource Sharing</title>
    <author fullname="Anne van Kesteren" surname="van Kesteren" initials="A."/>
    <date year="2014" month="January" day="16"/>
  </front><seriesInfo name="W3C Recommendation" value="REC-cors-20140116"/><annotation>
    Latest version available at
    <eref target="http://www.w3.org/TR/cors/"/>.
  </annotation></reference>

</references>

<section anchor="alternatives" title="Alternatives, or: why not a new Status Code?">
<t>
  A plausible alternative approach would be to implement this functionality one level
  up, using a new redirect status code (Section 6.4 of <xref target="RFC7231"/>). However, 
  this would have several drawbacks:
</t>
<t><list style="symbols">
  <t>Servers will need to know whether a client understands the new status code;
  thus some additional signal to opt into this protocol would always be needed.</t>
  <t>In redirect messages, representation metadata (Section 3.1 of <xref target="RFC7231"/>),
  namely "Content-Type", applies to the response message, not the redirected-to
  resource.</t>
  <t>The origin-preserving nature of using a content coding woudld be lost.</t>
</list></t>
<t>
  Another alternative would be to implement the indirection on the level
  of the media type using something similar to the type "message/external-body",
  defined in <xref target="RFC2017"/> and refined for use in the 
  Session Initiation Protocol (SIP) in <xref target="RFC4483"/>. This approach
  though would share most of the drawbacks of the status code approach mentioned 
  above.
</t>
</section>

<section title="Open Issues">
<section anchor="fallback" title="Accessing the Secondary Resource Too Early">
<t>
  One use-case for this protocol is to enable a system of "blind caches",
  which would serve the secondary resources. These caches might only be populated
  on demand, thus it could happen that whatever mechanism is used to populate
  the cache hasn't finished when the client hits it (maybe due to race
  conditions, or because the cache is behind a middlebox which doesn't allow
  the origin server to push content to it).
</t>
<t>
  In this particular case, it can be useful if the client was able to 
  "piggyback" the URI of the fallback for the primary resource, giving the secondary server
  a means by which it could obtain the payload itself. This information could
  be provided in yet another Link header field:
</t>
<figure>
<artwork type="message/http; msgtype="request""><![CDATA[
  GET bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1
  Host: example.net
  Link: <http://example.com/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00>;
        rel="http://purl.org/NET/linkrel/primary-resource"
  
  ]]></artwork>
<postamble>
(continuing the example from <xref target="basic.example"/>)
</postamble>
</figure>
</section>

<section anchor="resource.maps" title="Resource maps">
<t>
  When out-of-band encoding is used as part of a caching solution, the additional
  round trips to the origin server can be a significant performance problem;
  in particular, when many small resources need to be loaded (such as 
  scripts, images, or video fragments). In cases like these, it could be 
  useful for the origin server to provide a "resource map", allowing
  to skip the round trips to the origin server for these mapped resources.
  Plausible ways to transmit the resource map could be: 
</t>
<t><list style="symbols">
  <t>
    as extension in the out-of-band encoding JSON payload, or
  </t>
  <t>
    as separate resource identified by a "Link" response header field.
  </t>
</list></t>
<t>
  This specification does not define a format, nor a mechanism to transport
  the map, but it's a given that some specification using "out-of-band"
  encoding will do.
</t>
</section>

<section anchor="padding" title="Padding">
<t>
  It might be a good idea to allow padding in the secondary resource's payload,
  in order to even hide the precise content length. This could be accomplished
  by adding range information to the out-of-band metadata, allowing the client
  to throw away parts of the payload when reconstructing the response body.
</t>
</section>

<section title="Fragmenting">
<t>
  It might be interesting to divide the original resource's payload into fragments,
  each of which being mapped to a distinct secondary resource. This would
  allow to not store the full payload of a resource in a single cache, thus
</t>
<t><list style="symbols">
  <t>distribute load,</t>
  <t>caching different parts of the resource with different characteristics (such as only distribute the first minutes of a long video), or</t>
  <t>hide information from the secondary server.</t>
</list></t>
<t>
  Another benefit might be that it would allow the origin server to only serve the first
  part of a resource itself (reducing time to play of a media resource), while
  delegating the remainder to a cache (however, this might require further adjustments
  of the out-of-band payload format).
</t>
</section>

</section>

<section anchor="change.log" title="Change Log (to be removed by RFC Editor before publication)">
<section anchor="changes.since.00" title="Changes since draft-reschke-http-oob-encoding-00">
<t>
  Mention media type approach.
</t>
<t>
  Explain that clients can always fall back not to use oob when the secondary
  resource isn't available.
</t>
<t>
  Add Vary response header field to examples and mention that it'll
  usually be needed
  (<eref target="https://github.com/reschke/oobencoding/issues/6"/>).
</t>
<t>
  Experimentally add problem reporting using piggy-backed Link header fields
  (<eref target="https://github.com/reschke/oobencoding/issues/7"/>).
</t>
</section>
<section anchor="changes.since.01" title="Changes since draft-reschke-http-oob-encoding-01">
<t>
  Updated ENCRYPTENC reference.
</t>
</section>
<section anchor="changes.since.02" title="Changes since draft-reschke-http-oob-encoding-02">
<t>
  Add MICE reference.
</t>
<t>
  Remove the ability of the secondary resource to contain anything but the
  payload (<eref target="https://github.com/reschke/oobencoding/issues/11"/>).
</t>
<t>
  Changed JSON payload to be an object containing an array of URIs plus
  additional members. Specify "fallback" as one of these additional members,
  and update <xref target="fallback"/> accordingly).
</t>
<t>
  Discuss extensibility a bit.
</t>
</section>
<section anchor="changes.since.03" title="Changes since draft-reschke-http-oob-encoding-03">
<t>
  Mention "Content Stealing" thread.
</t>
<t>
  Mention padding.
</t>
</section>
<section anchor="changes.since.04" title="Changes since draft-reschke-http-oob-encoding-04">
<t>
  Reduce information leakage by disallowing ambient authority information
  being sent to the secondary resource. Require "Origin" to be included
  in request to secondary resource, and require seconday server to check it.
</t>
<t>
  Mention "Origin" + server check on secondary resource as defense to content stealing.
</t>
<t>
  Update ENCRYPTENC reference, add SCD reference.
</t>
<t>
  Mention fragmentation feature.
</t>
<t>
  Discuss relation with range requests.
</t>
</section>
</section>

<section title="Acknowledgements">
<t>
  Thanks to Christer Holmberg, Daniel Lindstrom, Erik Nygren, Goran Eriksson, John Mattsson, Kevin Smith, Magnus Westerlund, Mark Nottingham, Martin Thomson,
  and Roland Zink for feedback on this document.
</t>
</section>

  </back>

</rfc>