]> CDNI Edge Control Metadata Telefonica
Spain alfonsosiloniz@gmail.com
Lumen Technologies
US glenng1215@gmail.com
Content Delivery Networks Interconnection This specification defines configuration metadata objects used to manage how edge servers control access to resources within Content Delivery Networks (CDNs) and Open Caching systems. A key feature of these configurations is the configuring of Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers. This specification also provides the ability to define response body compression rules and client connection timeouts.
Introduction CDNs and Open Caching systems typically require a set of configuration metadata to provide directives for processing responses downstream (at the edge and in the user agent). This document specifies GenericMetadata objects to meet those requirements, defining edge processing rules such as Cross-Origin Resource Sharing (CORS) handling, response compression, and client connection failures.
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 .
MI.CrossoriginPolicy
Overview When a user interacts with a Content Provider (CP) application, such as a streaming app on a smartphone or a web browser, the device initiates a request for content distributed by a CDN. This process typically begins with an initial request to the CP's URL using a Fully Qualified Domain Name (FQDN) within the CP's own domain. Depending on the CDN architecture, the response may trigger an HTTP redirection to a different FQDN, usually one belonging to the CDN's domain. While this transition is necessary for delivery, many User Agents apply strict 'same-origin' security restrictions to these network requests, which can block the content unless specific access rules are defined. Cross-origin resource sharing (CORS) is a protocol that allows a HTTP client application to access restricted resources from a server on a domain different from the domain that served the original request. It is defined by the Web Hypertext Application Technology Working Group (WHATWG) Fetch Living Standard . CORS is based on HTTP request and response headers, which must be managed appropriately. For clarification, it is important to note that the concept of an Origin in the CDN context is different from that in the CORS context. The former indicates the source from where the CDN acquires content (the Origin Server), while the latter identifies the security context (scheme, host, and port) of the web application making the request. To permit shared cross-origin network requests, CORS protocol defines a set of request and response headers that must be present to permit access to these restricted resources. Two situations can occur when one or more CDNs are involved in processing these requests:
  • CDNs forward the User-Agent (UA) request headers to the CP servers, and they forward the response headers generated back to the UA.
  • CDNs can include logic to dynamically generate the required response headers based on the UA request without contacting the CP servers.
The dynamic generation of CORS headers is typical in modern HTTP request processing and avoids forwarding CORS headers to the uCDN, thereby reducing the load between dCDN and uCDN when the content to be delivered is already cached in the dCDN. Also consider that there are two types of requests involved in the CORS protocol as defined in Section 3.2.2 of :
  • A CORS request is any HTTP request that includes an Origin header. The Origin header is a version of the Referer header that does not reveal a path, as defined in Section 3.1 of
  • A CORS preflight request is a CORS request to check whether the CORS protocol is understood by the delivery server, and to ensure that it includes valid CORS response headers. It uses the OPTIONS method along with some other specific request headers to indicate which method and headers will be used in a future CORS request to the same resource.
The CDN Interconnection (CDNI) metadata model requires extensions to permit a uCDN to declare how a dCDN MUST evaluate and dynamically generate the necessary CORS response headers, avoiding the forwarding of CORS requests and/or preflight requests to the uCDN. Required capabilities:
  • Set a default value for CORS response headers independent of the value of the Origin request header.
  • Match the value of the Origin request header with a list of valid values. If it is successful, the dCDN will inject the appropriate CORS response headers.
  • Set a list of custom response headers that are allowed to be exposed to the client using CORS response headers.
  • Dynamically generate CORS response headers to CORS preflight requests including custom header validation, expose headers, and methods.
  • Support credentials validation within CORS.
dCDN Required behavior The dCDN MUST implement the following behavior as determined by the GenericMetadata object MI.CrossoriginPolicy defined in this section:
  • Validation of the Origin request header - If MI.CrossoriginPolicy defines a list of domains to validate, if the Origin request header does not match, the CORS response headers MUST NOT be included in the dCDN response. UA compliance with Section 3.3 of with "same-origin" restrictions will prevent access to the resource.
  • Wildcard usage - If the Origin request header is valid, depending on the configuration, the value of the CORS response header to include in the response will be the same as the Origin request header, or a wildcard.
  • uCDN is able to configure a list of default values for CORS response headers in MI.CrossoriginPolicy Generic Metadata object that dCDN MUST add if present independent of the value of the Origin request header.
  • If the UA is expected to use CORS preflight requests, uCDN can also configure the dCDN to dynamically generate synthetic responses to HTTP OPTIONS method requests as defined in Section 3.3.2 of
When an uCDN configures one or more of the expose-headers, allow-methods, allow-headers, allow-credentials and max-age properties the dCDN MUST generate synthetic responses to any CORS preflight request without contacting the uCDN servers. In this case the dCDN will add the corresponding CORS response headers to every non-empty parameter. If none of those parameters are set in the configuration, the dCDN MUST forward every CORS preflight request (OPTIONS method) to the uCDN servers and process their responses before responding to the UAs.
MI.CrossoriginPolicy MI.CrossoriginPolicy is a GenericMetadata object that allows configuring dynamically generated CORS headers. Property: allow-origin
  • Description: Validation of simple CORS requests.
  • Type: Object MI.AccessControlAllowOrigin
  • Mandatory-to-Specify: Yes
Property: expose-headers
  • Description: A list of header names the dCDN will include in the Access-Control-Expose-Headers response header of a CORS preflight request.
  • Type: Array of Field Names as defined in Section 5.1
  • Mandatory-to-Specify: No. If not specified, the default behavior is not to add the header in the response.
Property: allow-methods
  • Description: A list of request method tokens the dCDN will include in the Access-Control-Allow-Methods response header to a CORS preflight request.
  • Type: Array of method tokens as defined in Section 9.1
  • Mandatory-to-Specify: No. If not specified, the default behavior is not to add the header in the response.
Property: allow-headers
  • Description: A list of header names the dCDN will include in the Access-Control-Allow-Headers response header to a CORS preflight request.
  • Type: Array of Field Names as defined in Section 5.1
  • Mandatory-to-Specify: No. If not specified, the default behavior is not to add the header in the response.
Property: allow-credentials
  • Description: The value the dCDN will include in the Access-Control-Allow-Credentials response header to a CORS preflight request.
  • Type: Boolean
  • Mandatory-to-Specify: No. If not specified, the default behavior is not to add the header in the response.
Property: max-age
  • Description: The value the dCDN will include in the Access-Control-Max-Age response header to a CORS preflight request.
  • Type: Integer
  • Mandatory-to-Specify: No. If not specified, the default behavior is not to add the header in the response.
Property: no-origin-response-headers
  • Description: In the case of a request that has no Origin field, return this set of headers with the response. Content providers need to deal with devices or applications that, even not sending the Origin header in the request, are expecting to receive the Access-Control-* headers in the response.
  • Type: Array of MI.AccessControlHeaders objects.
  • Mandatory-to-Specify: No. If not specified, the default behavior is not to add any CORS response headers.
Property: preflight-only
  • Description: If this flag is set to "true" the dCDN will only generate synthetic responses to OPTIONS requests with proper CORS response headers.
  • Type: Boolean
  • Mandatory-to-Specify: No. The default is "false", so CORS response headers logic will be injected for all HTTP methods.
MI.AccessControlAllowOrigin The MI.AccessControlAllowOrigin object has the following properties: Property: allow-list
  • Description: List of valid expressions that will be used to match the request Origin header. The Origin header is an HTTP extension. Its value is a variation of the Referer header that does not reveal a path in some specific requests and is used for cross-origin requests. Permitted values for the Origin header are of the form schema://host[:port] as defined in Sections 3.1, 3.2.2, and 3.2.3 of
  • Type: Array of Strings, where each String is a pattern as defined in Section 4.1.5
  • Mandatory-to-Specify: Yes
Property: wildcard-return
  • Description: If set to "true", the dCDN will include a wildcard (*) in the Access-Control-Allow-Origin response header. If "false", the dCDN MUST reflect the value of the Origin request header in the Access-Control-Allow-Origin response header.
  • Type: Boolean
  • Mandatory-to-Specify: Yes
MI.AccessControlHeaders The MI.AccessControlAllowHeaders object has the following properties: Property: name
  • Description: The name of the HTTP header.
  • Type: String
  • Mandatory-to-Specify: Yes
Property: value
  • Description: The new value of the named HTTP header.
  • Type: String. A static string.
  • Mandatory-to-Specify: Yes
Examples The informative examples below demonstrate how to configure response headers dynamically for CORS validation. The following is an informative example of a CORS validation configuration that does not include CORS preflight requests:
The following is an informative example of configuration to the dCDN to generate synthetic responses to CORS requests and CORS preflight requests:
MI.AllowCompress Downstream CDNs often have the ability to compress HTTP response bodies in cases where the client has declared that it can accept compressed responses (via an Accept-Encoding header), but the source/origin has returned an uncompressed response. The specific compression algorithm used by the dCDN is negotiated by the client's Accept-Encoding header according to Section 12.5.3 (including "q=" preferences) and the compression capabilities available on the dCDN. In addition, HeaderTransform allows the uCDN to normalize, or modify, the Accept-Encoding header to allow for fine-grain control over the selection of the compression algorithm (e.g., gzip, compress, deflate, br, etc.). MI.AllowCompress is a new GenericMetadata object that allows the dCDN to compress content before sending it to the client. Property: allow-compress
  • Description: If set to "true", the dCDN SHOULD try to compress the response to the client based on the Accept-Encoding request header and its available capabilities. In case is not able to do the compression, the content will be delivered uncompressed.
  • Type: Boolean
  • Mandatory-to-Specify: No. The default is "false".
Examples The following is an informative example of the usage of MI.AllowCompress:
MI.ClientConnectionControl Configuration metadata is required to define how connections to a client are maintained by a dCDN. In some use cases, like video streaming or other critical object delivery, UA applications' connection to the cache server must be managed to ensure the best possible user experience. This metadata allows a uCDN to accommodate device-specific constraints and performance optimization. A dCDN can also benefit from this configuration metadata to meet its security and resource consumption requirements. MI.ClientConnectionControl is a new GenericMetadata object that specifies how the uCDN wants that the dCDN manages its connections to UAs. Property: connection-keep-alive-time-ms
  • Description: Specifies the time, in milliseconds, to keep an idle connection open before trying to close it.
  • Type: Integer
  • Mandatory-to-Specify: No. When not specified, a default value selected by the dCDN will be used.
Examples The following informative example shows how a connection setup and a keep alive timeout of 3 seconds can be set for client connections to a dCDN:
The FCI and MI objects defined in this document are transferred via the interfaces defined in CDNI which describes how to secure these interfaces by protecting integrity and confidentiality while ensuring the authenticity of the dCDN and uCDN.
This document requests the registration of the following entries under the "CDNI Payload Types" registry hosted by IANA: CDNI Payload Types
Payload TypeSpecification
MI.CrossoriginPolicyRFCthis
MI.AccessControlAllowOriginRFCthis
MI.AllowCompressRFCthis
MI.ClientConnectionControlRFCthis
MI.AccessControlHeadersRFCthis
[RFC Editor: Please replace RFCthis with the published RFC number for this document.]
Purpose: The purpose of this Payload Type is to distinguish CrossoriginPolicy MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: See
Purpose: The purpose of this Payload Type is to distinguish AccessControlAllowOrigin MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: See
Purpose: The purpose of this Payload Type is to distinguish AllowCompress MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: See
Purpose: The purpose of this Payload Type is to distinguish ClientConnectionControl MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: See
Purpose: The purpose of this Payload Type is to distinguish AccessControlHeaders MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: See
The authors would like to express their gratitude to the members of the Streaming Video Technology Alliance Open Caching Working Group for their contributions and guidance. Particularly the following people contribute in vairous ways to the content of this draft:
  • Guillaume Bichot (Broadpeak)
  • Christoph Neumann (Broadpeak)
  • Chris Lemmons (Comcast)
  • Pankaj Chaudhari (Disney Streaming)
  • Robert Colantuoni (Disney Streaming)
  • Will Power (Lumen)
  • Rajeev RK (picoNETS)
  • Shmuel Asafi (Qwilt)
  • Yoav Gressel (Qwilt)
  • Nir Sopher (Qwilt)
  • Arnon Warshavsky (Qwilt)
  • Eric Klein (Sirius XM)
  • Francisco Cano Hila (Telefonica)
  • Ben Rosenblum (Vecima)
 Streaming Video Technology Alliance Home Page SVTA Fetch Standard Web Hypertext Application Technology Working Group (WHATWG) Open Caching: Interoperable Caching Specifications by the SVTA SVTA