With this behavior enabled, you can decide how the edge servers handle case-sensitivity in URLs when caching a request.
Normally, the origin considers the path and filename in the URL as case-sensitive. So, objects served as a result of requests for
session.html are treated as two different objects for caching purposes. With this behavior enabled, cases are ignored and objects fetched with the same URL but different cases are treated as the same object in the cache.
- Some origin servers, like those using Microsoft IIS, are case-insensitive. If your origin is case-insensitive, enable this feature.
- If you ignore cases in the cache key, you should also ignore cases within the path, filename, or file extension rule match under which you are using this feature. Otherwise, the result could be two requests, differing only by the case of the URL, having different settings applied but being cached as the same object.
- Remain cautious when changing this feature or other features that modify the cache key when a property configuration is already active in production.
The cache key identifies the objects in cache. If you change the cache key, the edge servers think it's a different object in the cache. The result may be:
- a sudden enormous demand on the origin for "new" objects the edge servers don't think are cached,
- "cache pollution"—that is, excess cache space taken up with duplicate content.
To use this caching behavior in combination with Akamai NetStorage (or any other Unix-based server) as the origin server, you need to configure that server to also ignore the case of the URLs. For NetStorage, this is accomplished with the Force Case option, which can convert the request to either upper or lower case.
Note, however, that this requires that you consistently name the files on NetStorage in either upper or lower case.
You can find more information about NetStorage and Force Case in the NetStorage Configuration Guide.
Updated almost 2 years ago