With this behavior enabled, you can decide how the edge servers handle case sensitivity in URLs when caching a request.
How it works
Normally, the origin considers the path and filename in the URL is case-sensitive. So, objects served as a result of requests for Session.html and 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.
Tips and best practices
- 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 the 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.