This Q&A section is focusing on technical questions on a deeper level and is the continuation of the FAQ on our main page. Please check billing and basic questions here: https://www.keycdn.com/faq
- What cache statuses are there?
- Which HTTP request methods do you support?
- Does a pull zone cache any response status?
- Do I need to define specific edge server locations for my KeyCDN zone?
- What does a request Header from a KeyCDN edge server look like?
- Is s-maxage in cache-control header supported?
- Why does the Analytics page show no used storage for a Pull Zone?
- Is stale content served from a pull zone if the origin server is not available?
- Is the URL case sensitive?
- Can I purge content from the CDN?
- Is byte-range not working in combination with S3?
- How are Byte Range Requests cached?
- Why do my files not get cached? Why is my miss ratio high?
- Can I use .htaccess in my zone?
- Will an EV certificate work with KeyCDN’s SSL/TLS?
- Can I change the reporting time zone?
- Why is the HTTP header “Vary: Accept-Encoding” not present?
- Can I override the default cache expiry time?
- You are setting the Expires header fields on your origin but the expiry date is not updating for the cached files?
- Search engines are crawling the CDN URL and I now have duplicate content, how can I solve that?
- Is there a specific UserAgent when KeyCDN is fetching content from the origin server?
- Can I get the IPs of the KeyCDN edge servers?
- I can’t connect to my push zone and upload content, why?
- Can I still use the kxcdn domain if Let’s Encrypt or Custom SSL is enabled?
- How are simultaneous requests to the same asset handled?
- Is HLS supported when Origin Shield is enabled?
- How can I determine how much bandwidth my website currently uses?
- Can I use the KeyCDN Let’s Encrypt SSL option if I’m already using Let’s Encrypt on my origin server?
Different cache statuses can occur for push and pull zones. Here’s an overview of possible cache statuses:
- Your content has been delivered from the cache.
- A MISS indicates that the content was not yet in the cache but will be after the first request. The second request to that file will be a cache HIT.
- The cached content has expired and the new content from the origin server has been fetched.
- It has been verified, that the currently cached content is still valid.
- Content has been served from the cache. There is a cache lock active and new content is being copied from the origin server.
- The most recently cached content is returned to the client. This can occur when the origin is not reachable, the connection times out, or the origin server is using stale-while-revalidate.
In some error cases there is no cache status returned. Raw logs will show a “-” instead of one of above values.
The request methods allowed vary slightly between push and pull zones. For pull zones, we support all common HTTP request methods:
- HEAD and GET requests get cached and will be served from the KeyCDN cache
- PUT, POST, DELETE, OPTIONS requests will not be cached (X-Cache: MISS)
For push zones, we support only HEAD and GET requests. If using a method other than HEAD or GET on a push zone you will receive a 405 Method Not Allow status.
No, only 200, 301, and 302 responses are cached on the edge server from the origin server.
No, this is not required. All KeyCDN zones are automatically configured to work with our complete network of edge server locations. This does not need to be defined manually. Upon user request, assets will be pulled from your origin server and cached at the client’s nearest CDN edge server.
GET /foobar.jpg HTTP/1.1 Host: your_origin_host X-Forwarded-Host: <zonename>-<id>.kxcdn.com X-Forwarded-For: 188.8.131.52 X-Forwarded-Scheme: http X-Pull: KeyCDN Connection: close Accept: */* User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36 Accept-Language: en-US,en;q=0.8,de;q=0.6,ja;q=0.4 Cookie: foobar
- Contains the originally requested host, either the zone or zonealias (e.g. cdn.example.com).
- Forwards the client IP address from our edge server.
- Identifier of the originating scheme of an HTTP request. Either HTTP or HTTPS.
- Contains the value you defined in the dashboard for your zone.
Yes, content will be cached according to s-maxage in “Cache-Control”. The s-maxage header is intended for KeyCDN’s edge servers, while max-age is intended for regular clients. More details in Expire Header and Cache-Control.
Pull Zones on each edge server have a different amount of data cached. This is very dependent on the traffic pattern and expiry values. There is no storage cost for Pull Zones.
Yes, stale content will be served if the origin server is not reachable or if the connection times out. If the origin server is reachable and returns a HTTP 403, 404, 500, 502, 503, 504, the pull zone will not serve stale content but return the same response as it gets from the origin server.
It’s important to distinguish that the domain is not case sensitive but the path is case sensitive.
- The domain can be upper case or lower case. We recommend working with lower case. E.g. cdn.yourdomain.com or CDN.yourdomain.com or cdn.Yourdomain.com will all work
- The path needs to be correct, e.g /yourfile.txt is not the same as /YourFile.txt
Having the path case-insensitive is not available due to performance issues. The case insensitivity of the DNS is specified in RFC 4343.
Content of a pull zone can be purged instantly from all POPs globally. It can be done via the dashboard or the API. Assets of a push zone cannot be purged. A newly uploaded file will be globally distributed in about 15 min, the same goes for deleted files. If more control is needed over a push zone, we recommend to do file name versioning (e.g. myfile-v13.txt). A new version of the file can be uploaded with a new version number and will be instantly available.
AWS S3 does not send the HTTP header Accept-Ranges: bytes if you are using the default endpoint URL. KeyCDN sends only 200 instead of 206 and ignores range requests if this field is missing. Use the following format as the origin URL instead which serves the required Accept-Ranges header field: <bucketname>.s3.amazonaws.com
If the asset is present in the cache, then the KeyCDN edge servers honor a byte-range request and deliver only the specified bytes of that file to the client. If the asset is not cached, or if it is in stale state, the KeyCDN edge servers download the entire asset from the origin server. If the request is for a single byte range, the edge servers send that byte-range to the client as soon as it is encountered in the download stream. If the request specifies multiple byte ranges within the same file, the edge servers deliver the entire asset to the client when the download completes.
After the download completes and is stored in the cache on the KeyCDN edge servers, all future byte-range requests, whether for a single range or multiple ranges, are delivered immediately from the cache.
Please check if you’re sending the HTTP header Content-length from your origin server. The Content-length header must be both present and contain a value greater than 0 in order to produce a cache HIT. Otherwise, it will be a cache MISS.
No, .htaccess files will not be processed.
Yes, any kind of EV certificate on the origin server will work with HTTPS solutions from KeyCDN (Shared SSL, Custom SSL or Let’s Encrypt), the green bar in the browser will remain. It’s also possible to use an EV certificate for Custom SSL in the KeyCDN dashboard.
The reporting time zone in the whole KeyCDN dashboard is UTC, it cannot be changed. Also the time stamp provided in the KeyCDN raw logs is UTC.
KeyCDN adds the HTTP header “Vary: Accept-Encoding” to every request needed. Use our HTTP Header Check to verify the headers. There are certain cases where “Vary: Accept-Encoding” is not required, namely for SPDY and HTTP/2 request. In this cases, “Vary: Accept-Encoding” is not present. Check our detailed Vary Header Guide about this topic.
Yes. You can do that by checking “Show Advanced Features” in the CDN Control Panel, which is visible when you are managing your zone. Alternatively, you can set an expiry header on your origin server.
You are setting the Expires header fields on your origin but the expiry date is not updating for the cached files?
You have set “Ignore Cache-Control” to disabled and “Expires” to 0 to fully honor the expiry headers from your origin server. The Expires header field will be initially cached together with the asset. Further, if that asset is not changing the Expires field won’t either. This means that the date of the Expires header field might is in the past for assets that are rarely changing. The browser needs to revalidate an asset on every request if the Expires date is in the past. The Expires field will be updated as received from the origin server if the asset has been modified (e.g. ETag or Last-Modified has changed), otherwise it will not be updated from the origin server and keep the initial date. This might be undesirable. We recommend that you use the Cache-Control (max-age) header field instead of the Expires header field to overcome this limitation. In case both fields are used, Cache-control has a higher precedence over Expires.
You can use robots.txt or canonical headers to solve that. Check our guide here how you can tackle that:
There’s no specific UserAgent in place. If you want distinguish KeyCDN traffic from other traffic on your origin server, take advantage of the X-Pull request header field. More details here:
We don’t disclose the IPs of the edge servers because the IPs frequently change. If you want to distinguish KeyCDN traffic from other traffic on your origin server, please take advantage of the feature X-Pull.
Make sure you follow the instructions on our knowledge base:
If you still have issues, please send us your IP address and we’ll check if you’ve been blocked.
No. Once you enable and configure the Let’s Encrypt or Custom SSL option, you will no longer be able to use the HTTPS version of the kxcdn domain. This will in most cases result in a common name invalid error or a 404 error.
KeyCDN never blocks a request. We either queue the response for a certain number of seconds (before fetching it again) or we fetch the content in parallel to the other request again from the origin server.
If you’re using HLS to stream pre-recorded media then you can use it in conjunction with the KeyCDN Origin Shield feature. However, if you’re streaming a live event over HLS, Origin Shield should be disabled as it will cause the .m3u8 files to be cached, which is unwanted.
You can check your origin server’s current bandwidth usage numbers. This will give you an approximation of how much bandwidth you will be using via the CDN. For more information and to see where to find your bandwidth numbers, read through our guide How to Identify Your Bandwidth Usage.
Can I use the KeyCDN Let’s Encrypt SSL option if I’m already using Let’s Encrypt on my origin server?
Yes, you can still use the KeyCDN Let’s Encrypt option even if you’re already using Let’s Encrypt on your origin server. The Let’s Encrypt certificate on your origin server will be for your main domain (e.g. yourwebsite.com) while the KeyCDN LE certificate will be associated with your custom CDN URL (e.g. cdn.yourwebsite.com).