18. General Features¶
General Features is a catch-all category for various CDN features that are typically basic Boolean operators and don’t fit into an existing more encompassing feature section.
18.1. Negative TTL¶
Negative TTL allows for the caching of negative response codes to limit origin server load in certain cases. To enable negative TTL, please contact CDN support.
Implementation Details
Allow the error= flag to be used in the response RuleBase.
This should only change the status code of the response; the payload should remain as-is (if a replacement is required, use RespBody).
Extend the footprint_headers module to implement X-WR-Status, which is an FP4 header used to override the response status. This will allow FP4 to specify a cacheable response which we then serve as an arbitrary response code, including something nginx wouldn’t normally cache.
18.2. Log Extras¶
Log Extras provides a way of adding additional log data into the log streaming record. The Log Extras field is always present in the log whether it is populated or not. This config attribute tells the Edge Nodes how to populate the Log Extras field.
Log Extras can be static or dynamic content. Dynamic content can be any number of internal variables. For example Header lines sent to a client have the prefix “sent_http_”, so to capture a custom header’s value in the client request (e.g., cdn_session), you would use $sent_http_cdn_session. Please call CDN support for additional details as to what can be dynamically captured in the Log Extras field.
Note that the Log Extras field in the Log Streaming service is white listed per value. In order for your log extra data to show up, Operations will have to white list your variable (e.g., sent_http_cdn_session).
The Log Extras feature is provisioned against the ReportingID vs. a location. This means it is part of the Match Group ID=0 collective and set against the per reprtingID Match Rule as show below
"matchGroups": [
{
"id": 0,
"matchRules": [
{
"expression": "$id.minor == 12345",
"id": 12345,
"features": {
"logExtras": {
"value": "$sent_http_cdn_session"
}
}
}
]
}
]
18.3. Cache Key¶
The CTL CDN caches objects under their respective OriginID. So multiple Aliases under the same OriginID share the same cache key. So for example, if the following Alias defintion is defined:
"aliasDefinitions": [
{
"reportingId": 98,
"protocol": [
"HTTP"
],
"name": "980",
"id": 980,
"originId": 98,
"aliases": [
"www.example.com",
"www.example.net",
"www.foo.com",
"www.foo.net"
]
}
]
In this case all requests for any of the defined aliases will be stored under the same cache key. So the following requests are considered equivalent when looking for the requested object in the local cache:
www.example.com/video/example_video.m3u8
www.foo.net/video/example_video.m3u8
This approach aligns well in most cases with how the origin tends to work, in that content is stored in a common file system which is agnostic to the underlying host used to reach the origin. However, in some cases, complex origin configurations may be more complex and remap requests to different paths. As such care should be taken when grouping aliases under the same OriginID so as to avoid serving the wrong content.
In the same vein, care should be taken when moving aliases from one originID to another. Moving Aliases can result in double caching of objects and reduction in cache efficiency.