8. Accept-Encoding

Configuration Definition: Subscriber
Configuration Application: Match Rule (Property)
Default Behavior: On/Enabled
Limitations: None
Version: 16.2

The Accept-Encoding header field can be used in client requests to indicate what content-codings are acceptable in the response. The Accept-Encoding feature normalizes a client’s Accept-Encoding header to identity (no encoding) and gzip (if included in the client’s request). Any other encoding types are dropped from the client’s request by default. Normalization of the Accept-Encoding: header improves cache efficiency by reducing the variation of the Accept-Encoding value. For example, the following headers are semantically equivalent but not bytewise equivalent:

Accept-Encoding: gzip, default, identity Accept-Encoding: identity, gzip, deflate

With the default Normalization feature enabled, the above requests would be normalized to:

Accept-Encoding: gzip, identity

The Accept-Encoding feature is enabled by default and applies to all requests. It is possible to modify the list of supported encodings based on the file extension present in the request. For example, for image files (e.g., .jpeg, .jpg, .gif, etc.), the origin server likely supports only identity encoding (since these files are already compressed) so it makes sense to avoid considering encodings other than identity when processing the client’s request. For text-based file extensions (e.g., .html, .htm, .txt, .css, etc.), it makes sense to consider requests for compressed encodings, with gzip being by far the most common (making it the default), but with other encodings (e.g., sdch) being optionally configurable. Configuring different compression types does not cause the CDN to perform the compression on the origin’s behalf. If encodings are defined that the origin server does not support, they will not be returned to the client.

Finally, note that the normalization process maintains the relative encoding preferences in the client’s Accept-Encoding header for the supported encodings, never adds an encoding the client did not specify, and preserves a client’s specification that a given encoding is not acceptable. Normalization never causes the CenturyLink CDN to serve an encoding that was not requested or that the client has specified as unacceptable.

To define an AE-override policy:

  1. Create an AE-override definition that identifies the file extensions you want to apply AE normalization to.
  2. Create a match rule definition that references the AE-override definition in step 1.

The AE-override definition is defined at the subscriber level and can be used by any property under that subscriber. An AE-override definition includes a comma-separated list of file extensions, a comma-separated list of encoding types, a name and an ID. The name is used for reference by the match rule definition. The ID is an internal reference that, once set, should not be changed. Following is a sample AE-override definition using the JSON schema:

"aeOverrideDefinitions": [
  {
    "name": "AE-1",
    "id": 594680,
    "compressionTypes": [
      "gzip"
    ]
    "fileExtensions": [
      "m3u8",
      "mpd"
    ]
    "isDefault": false
  }
]

Attributes of a aeOverrideDefinitions are:

  • name: human-readable name given for AE-override definition, unique within a single subscriber. Required.
  • id: unique static identifier for an AE-override definition. Integer, Required.
  • compressionTypes: comma-separated list of compression/encoding types that should be allowed (if the origin server supports them). Required.
  • fileExtensions: comma-separated list of file extensions that AE-override should be applied to. Required.
  • isDefault: if set to True, the AE-override definition applies to all requests under the subscriber (regardless of what property they are under) without requiring a match rule. At most one AE-override definition can be set to True. All others must be set to False. A default AE-override definition can be overridden via a property-level match rule.

An AE-override definition by itself does nothing (unless it is a default definition as described above). To enable the feature, the AE-override definition must be applied to a property-level match rule (within the subscriber’s service image). Property-level match rules are contained under the special matchGroup id=0 and have an expression $id.minor == <coserverid>. Following is a sample AE-override definition using the JSON schema:

"matchGroups": [
  {
    "id": 0,
    "matchRules": [
      {
        "id": 59468
        "expression": "$id.minor == 59468",
        "features": {
          "aeOverride": {
            "value": {
              "id": 594680
            }
          }
        }
      }
    ]
  }
]

If the match rule has both AE-override and DCT definitions and the list of file extensions overlap, then the system takes the overlapping extensions out of the AE-override, keeping the rest of them with the defined encodings. The overlapping extensions are presented in the platform config with default DCT encoding of gzip/identity.