CDNI Edge Control Metadata

3.1. Overview

When a Content Provider's application requests a content that is being distributed by a CDN it makes an initial request to a CP's URL using a FQDN in the realm of the Content Provider usually. Depending on the CDN architecture used, the response can be a HTTP redirection to a different FQDN, typically one that belongs to the CDN realm. This situation is known as a shared cross-origin response, but many User Agents apply same-origin restrictions to these network requests.¶

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 than the domain that served the original request. It is defined by the Web Hypertext Application Technology Working Group (WHATWG) Fetch Living Standard [WHATWG-FETCH]¶

CORS is based on HTTP request and response headers, that 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, while the latter is related to the source from where the User Agent downloaded the instructions to request the content, also known as the Referer.¶

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. When one or more CDNs are involved to process these requests two situations can occur:¶

• CDNs forward the UA request headers to the Content provider servers and they forward the response headers generated to the UA¶

• CDNs can include the logic to dynamically generate the required response headers based on the UA request without contacting the Content provider servers¶

The dynamic generation of CORS headers is typical in modern HTTP request processing and avoids CORS headers being forwarded to the uCDN reducing the load between dCDN and uCDN when the content to be delivered is already cached in the dCDN.¶

Also consider than there are two type of requests involved in the CORS protocol as defined in Section 3.2.2 of [WHATWG-FETCH]¶

• 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 [WHATWG-FETCH]¶

• A CORS preflight request is one CORS request to check if CORS protocol is understood by the delivery server and it includes the 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 an 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.¶

Depending on the metadata configuration, the logic to apply by the dCDN is:¶

• Validation of the Origin request header - Metadata can include a list of valid domains to validate the Origin request header. If it does not match, the CORS response headers MUST NOT be included in the dCDN response. UA 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.¶

• Possibility to define default values for CORS response headers 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 OPTIONS requests¶

When an uCDN configures one or more of the expose-headers, allow-methods, allow-headers, allow-credentials, 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 no one of those parameters are set in the configuration the dCDN MUST forward every CORS preflight request (OPTIONS method) to the uCDN servers and process its response before responding to the UA.¶

3.2. 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 AccessControlAllowOrigin (Section 3.2.1)¶

• 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 to a CORS preflight request.¶

• Type: Array of Field Names as defined in Section 5.1 of [RFC9110]¶

• Mandatory-to-Specify: No. If not specified, the default behavior is to not 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 of [RFC9110]¶

• Mandatory-to-Specify: No. If not specified, the default behavior is to not 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 of [RFC9110]¶

• Mandatory-to-Specify: No. If not specified, the default behavior is to not 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 to not 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 to not 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.¶

• Type: Array of MI.HTTPHeader objects, defined in Processing Stages Metadata [SVTA2032].¶

• Mandatory-to-Specify: No. If not specified, the default behavior is to not add any CORS response headers¶

Property: preflight-only¶

• Description: Setting this flag 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¶

3.3. Examples

The examples below demonstrate how to configure response headers dynamically for CORS validation.¶

The following is an example of a CORS validation configuration that does not include CORS preflight requests:¶

{
  "generic-metadata-type": "MI.CrossoriginPolicy",
  "generic-metadata-value": {
    "allow-origin": {
      "allow-list": [
        {
          "pattern": "https://sourcepage.example.com"
        }
      ],
      "wildcard-return": true
    }
  }
}

The following is an example of configuration to the dCDN to generate synthetic responses to CORS requests and CORS preflight requests:¶

{
  "generic-metadata-type": "MI.CrossoriginPolicy",
  "generic-metadata-value": {
    "allow-origin": {
      "allow-list": [
        {
          "pattern": "*://sourcepage.example.com"
        },
        "wildcard-return": false
      },
      "allow-methods": [ "GET", "POST" ],
      "allow-credentials": true,
      "allow-headers": [ "X-PINGOTHER", "Content-Type" ],
      "expose-headers": [ "X-User", "Authorization" ],
      "max-age": 3600,
      "no-origin-response-headers": [
          {
            "name": "Access-Control-Allow-Origin",
            "value": "https://sourcepage.example.com",
          }
        ],
      "preflight-only": false
    }
  }
}

7.1. CDNI Payload Types

This document requests the registration of the following entries under the "CDNI Payload Types" registry hosted by IANA:¶

[RFC Editor: Please replace RFCthis with the published RFC number for this document.]¶