One document matched: draft-eriksson-http-resource-map-00.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.
-->
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!DOCTYPE rfc
PUBLIC "" "rfc2629.dtd">
<rfc ipr="trust200902" category="info" docName="draft-eriksson-http-resource-map-00">
<front>
<title>
Resource Maps
</title>
<author fullname="Goran AP Eriksson" initials="G. A. P." surname="Eriksson">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<code>16480</code>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>goran.ap.eriksson@ericsson.com</email>
</address>
</author>
<author fullname="Christer Holmberg" initials="C." surname="Holmberg">
<organization>Ericsson</organization>
<address>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<author fullname="Zaheduzzaman Sarker" initials="Z." surname="Sarker">
<organization>Ericsson</organization>
<address>
<email>zaheduzzaman.sarker@ericsson.com</email>
</address>
</author>
<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>
<date year="2016" month="October" day="31"/>
<area>Applications and Real-Time</area>
<abstract>
<t> When the 'out-of-band' content coding ('OOB') is used for delivering a number of resources from a primary server via a secondary server, the additional round trips for OOB responses and load on the primary server can be a significant nuisance.</t>
<t> In such situations, it is useful for the primary server to be able to provide the client with OOB response information for several resources in one go anticipating future client requests.
</t>
<t> This document describes a format for providing the client with the information, called a resource map, and how the resource map could be delivered to a client.
</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/EricssonResearch/Blind-Cache-Drafts"/>.
</t>
<!--<t>
The changes in this draft are summarized in <xref target="changes.since.08"/>.
</t>-->
</note>
</front>
<middle>
<section title="Introduction">
<t>
The mechanisms outlined in "An Architecture for Secure Content Delegation using HTTP" <xref target="SCD"/> and "Caching Secure HTTP Content using Blind Caches" <xref target="BC"/> use the 'out-of-band' content coding ('OOB') mechanism <xref target="OOBENC"/> to delegate the delivery of requested resource from a primary server to one or several secondary servers.
</t>
<t>
A primary server might decide to delegate the delivery of response payload for a set of resources, for instance individual video segments, or a set of images or parts of a large file.
</t>
<t>
In one approach the client sends individual requests for each of the resources to the primary server which provides the OOB content coding response information for the requested resources as meta data in each and every request to the primary server. This approach adds a minimum of one extra RTT (round trip time) for each request before the client can send the request to the desired secondary server.
</t>
<t>
In another approach the primary server anticipates a client's requests, for instance leveraging object dependency graph information, to provide the client with OOB content coding information for the subsequent requests in advance of requests.
</t>
<t>
This document describes a format for providing the client with the information for multipe OOB responses, called a resource map, and how the information is delivered to a client.
</t>
<!-- <section title="Abbreviations">
<t>
TBD
</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>
</section>
</section>
<section title="Basic procedure for providing a Resource Map">
<t>A primary server creates a resource map containing information about how a set of resources on the origin it serves maps to a set of resource locations on one or multiple secondary servers.
</t>
<t>
<xref target="OOBENC"/> describes the basic procedure for providing the client with the OOB response meta data for an individual request, as examplified below:
</t>
<t>
Client request of a resource:
</t>
<figure><artwork type="message/http; msgtype="request""><![CDATA[
GET /test HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip, out-of-band
]]></artwork></figure>
<t>
Response from primary server:
</t>
<figure><artwork type="message/http; msgtype="response""><![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: 165
Vary: Accept-Encoding
{
"sr": [
{ "r" :
"http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"},
{ "r" :
"/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"}
]
}
]]></artwork></figure>
<t>
A primary server can provide a Resource Map location in any response to a request for any resource using a Link header field <xref target="RFC5988"/> — this can
be an OOB response like the one above, but doesn't need to.
</t>
<figure><artwork type="example"><![CDATA[
Link: </map>; rel="http://purl.org/NET/linkrel/resource-map"
]]></artwork></figure>
<t>
Note that in this example, "/map" is a relative reference identifying the
resource map (relative to the request URI), and "http://purl.org/NET/linkrel/resource-map" is the identifier for the link
relation "resource map".
</t>
<t>
A primary server can speculatively anticipate a client requesting a Resource Map and MAY use HTTP/2 <xref target="RFC7540"/> to push the response with the Resource Map to the client to decrease the extra delay a request for resource map otherwise would incur.
</t>
<t>
The basic operation for providing the client with a Resource Map is as follows:
</t>
<t><list style="numbers">
<t>Client requests resource from primary. Request includes Accept-Encoding header field including "out-of-band".</t>
<t>Primary server response includes Link header field identifying the resource map.</t>
<t>Client retrieves the resource map.</t>
<t>Resource Map becomes stale and will be retrieved again.</t>
</list></t>
</section>
<section title="Updating the Resource Map">
<section title="Primary server need to update Resource Map">
<t>
Depending on the nature of the application and the resources, the primary server's need to provide the client with updates of the resource map information vary. In some cases there is no or little need for updates, in others there may be reasons for more frequent updates.
</t>
<t>
For instance, delegation information for static resources such as banners, images and script libraries for analytics might not change. In such a situation, the primary server does not need to stay in touch with the client to provide it with updates.
</t>
<t>
In another use case, the primary server provides the client with updates, for instance changing the secondary servers to be used by a mobile client.
</t>
<t>
Basically there are four approaches for a primary server to provide a client with updates to a resource map:
</t>
<t><list style="symbols">
<t>Piggyback signal about update on response to request from client</t>
<t>Client subscribes to Web Push updates</t>
<t>Client receives continuous updates</t>
<t>Resource Map validity time-out</t>
</list></t>
</section>
<section title="Piggyback">
<t>
A primary server MAY add an Link header field to any response to a client. A client receiving a response with a Link header MUST retrieve the Resource Map web resource and process it.
</t>
</section>
<section title="Using Web Push">
<t>
A primary server MAY add an indication in the Resource Map to the client to use a notification service to receive updates to a Resource Map. When present a client SHOULD register for notifications.
</t>
<t>
A client receiving a Resource Map update notification MUST retrieve the Resource Map using the location information in the notification.
</t>
</section>
<section title="Continuous Updates">
<t>
In some situations, it is desirable to provide the client with a stream of Resource Map updates. Depending on the client type, either a secure bi-directional transport protocol is used, such as WebSocket, or the client is instructed to poll for changes.
</t>
<t>
A primary server MAY add an indication to the client to either poll or use a stream oriented protocol for receiving intermittent, frequent updates.
</t>
</section>
<section title="Resource Map Timer">
<t>
The freshness of a Resource Map can be given by the 'ma' timer. When expired, the OOB delegation is not valid and the client MUST request an update from the primary server
(this duplicates HTTP cache information, but might become important when the resource map is transmitted over a protocol other than HTTP).
</t>
</section>
<section title="Resource Map compression">
<section title="gzip">
<t>
A resource map might be large. For this reason a client can use compression content codings such as 'gzip' to decrease the size.
</t>
</section>
<section title="Formulas">
<t>
When using the resource map, the primary server could use a template or formula to optimize the size of the resource map information. For example, using URI templates <xref target="RFC6570"/>, and an agreed upon HMAC of the path postfix, it would be possible to specify a mapping for many URIs at once.
</t>
<t>
<figure><artwork type="example"><![CDATA[
originURI =
"https://{origin}/images/{postfix}
mappedURI =
"https://cch.example.com/{origin}/images/{hmac-of-postfix}
]]></artwork></figure>
</t>
<t>
...would indicate a mapping for any https URI on "origin" below a root path of
"/images/", where the mapped URI would be constructed by concatenating
"https://cch.example.com/", the origin's host name, "/images/", and a base64- or hex-encoded opaque part, computed based on the remainder of the origin URI's path.
</t>
</section>
</section>
</section>
<section title="The Resource Map format">
<section title="Definitions">
<t>
A resource map will use and extend attributes outlined in <xref target="OOBENC"/> as well as additional extension attributes to be defined later.
</t>
<t>
The format of the resource map uses JavaScript Object Notation (JSON, <xref target="RFC7159"/>) describing a set of objects:
</t>
<t><list style="symbols">
<t>Objects for describing handling of updates of a resource map.</t>
<t>Objects for describing secondary servers and which resources that are mapped.</t>
<t>Objects for describing the resources on the secondary servers.</t>
</list></t>
<figure><artwork type="example"><![CDATA[
{
"resource-map-updates" : {
//Information about resource map updates.
},
"secondary-servers" : {
//Information about secondary servers.
},
"resources" : [
//Information about resources on secondary servers.
]
}
]]></artwork></figure>
</section>
<section title="Updates for Resource Map">
<t>
<cref>Details to be done. Example below illustrates how this could be used.</cref>
</t>
<figure><artwork type="example"><![CDATA[
{
"resource-map-updates" : {
"max-age" : [ ],
"web push" : {
"notification service" : [ ] // URL
... // Other Web Push details
},
"online" : {
"poll" : {
"intervall" : [ ] //Poll
}
"connect" : [ ] // TODO: Relation to URL in Link <map>?
},
}
]]></artwork></figure>
</section>
<section title="Secondary Servers and Mapping of Resources">
<t>
<cref>Details to be done.</cref>
</t>
<!-- <figure><artwork type="example">
{
"secondary-servers" : {
...
},
"resources": [ ],
}
</artwork></figure>-->
</section>
</section>
<section title="Security Considerations">
<t>
All the considerations of <xref target="OOBENC"/> and <xref target="SCD"/> apply.
</t>
<t>
A resource map can be used to cause the client to request malicious content or perform DoS attacks on a victim secondary server. Clients MUST verify the identity of server providing the Resource Map.
</t>
<t>
In the case the resource map is delivered as a separate Web resource, the client MUST verify that the server providing the resource map belong to the same authority as the primary server.
</t>
<t>
The secondary server SHOULD take actions to detect and manage request loops caused by erroneous request from a client.
</t>
<t>
<cref>TODO: Using tokens for access control to secondary.</cref>
<cref>Issue: A resource map attribute that is applicable for a set of resources may open up for mixed attacker-controlled data and secrets.</cref>
</t>
</section>
<section title="IANA Considerations">
<t>
This document currently has no actions for IANA.
</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="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="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="T. Bray"/>
<date year="2014" month="March"/>
</front><seriesInfo name="RFC" value="7159"/><seriesInfo name="DOI" value="10.17487/RFC7159"/></reference>
<reference anchor="OOBENC"><front>
<title>'Out-Of-Band' Content Coding for HTTP</title>
<author initials="J" surname="Reschke" fullname="Julian F. Reschke"/>
<author initials="S" surname="Loreto" fullname="Salvatore Loreto"/>
<date month="October" year="2016"/>
</front><seriesInfo name="Internet-Draft" value="draft-reschke-http-oob-09"/></reference>
</references>
<references title="Informative References">
<reference anchor="RFC6570" target="http://www.rfc-editor.org/info/rfc6570"><front>
<title>URI Template</title>
<author initials="J." surname="Gregorio" fullname="J. Gregorio"/>
<author initials="R." surname="Fielding" fullname="R. Fielding"/>
<author initials="M." surname="Hadley" fullname="M. Hadley"/>
<author initials="M." surname="Nottingham" fullname="M. Nottingham"/>
<author initials="D." surname="Orchard" fullname="D. Orchard"/>
<date year="2012" month="March"/>
</front><seriesInfo name="RFC" value="6570"/><seriesInfo name="DOI" value="10.17487/RFC6570"/></reference>
<reference anchor="RFC7540" target="http://www.rfc-editor.org/info/rfc7540"><front>
<title>Hypertext Transfer Protocol version 2</title>
<author initials="M." surname="Belshe" fullname="Mike Belshe"/>
<author initials="R." surname="Peon" fullname="Roberto Peon"/>
<author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor"/>
<date month="May" year="2015"/>
</front><seriesInfo name="RFC" value="7540"/><seriesInfo name="DOI" value="10.17487/RFC7540"/></reference>
<reference anchor="BC"><front>
<title>Caching Secure HTTP Content using Blind Caches</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="October" year="2016"/>
</front><seriesInfo name="Internet-Draft" value="draft-thomson-http-bc-01"/></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="October" year="2016"/>
</front><seriesInfo name="Internet-Draft" value="draft-thomson-http-scd-02"/></reference>
</references>
<!--
<section title="Call Flows">
<section title="Client initiated cache priming">
</section>
</section>-->
<section title="Multiple Secondary Servers">
<t>
A primary server can provide multiple secondary servers for retrieving a resource or set of resources.
</t>
<t>
A Resource Map for the case when resources on "https://origin.example.com:8080" are mapped to two different secondary servers:
</t>
<figure><artwork type="example"><![CDATA[
{
"secondary-servers": {
"server1": {
"name": "blind cache 1",
"address": "bc.example.com",
"protocol": "https",
"port": 8083,
"description": "Some text for debugging"
},
"server2": {
"name": "blind cache 2",
"address": "bc2.example.com",
"protocol": "https",
"port": 8082
}
},
"resources": [
{
"resource-origin": "/ex_jsl.js",
"mapped-path":
"/origin.example.com%3A8080/j39jl3jaac/29jfnf0f",
"attributes": {
"Content-Type": "application/javascript",
"Content-Encoding": "aesgcm",
"MI": ".....",
"Crypto-Key": "....."
},
"mapped": [
{
"server": "server1",
"attributes": {
"Max-Age": 1800
}
},
{
"server": "server2",
"attributes": {
"Max-Age": 1800
}
}
]
},
{
"resource-origin": "/another_resource.txt",
"mapped-path":
"/origin.example.com%3A8080/i39jfu2/1njknbs3",
"attributes": {
"Content-Type": "text/plain",
"Content-Encoding": "aesgcm",
"MI": ".....",
"Crypto-Key": "....."
},
"mapped": [
{
"server": "server2",
"attributes": {
"Max-Age": 1800
}
}
]
}
]
}]]></artwork></figure>
<t>
<cref>in the above example, why does resource-origin include scheme/host/port?</cref>
</t>
</section>
<section title="Change Log (To be removed before publication as RFC">
<t>Nothing yet.</t>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 14:44:01 |