Akamai just works, … most of the time. But sometimes you have to check what’s going on, and Akamai gives you a handy tool for this.
There is an HTTP request header that tells Akamai to respond with some internal information.
Pragma: akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-get-request-id
With this request header Akamai includes this in the response header
X-Cache: TCP_MISS from a84-53-161-127.deploy.akamaitechnologies.com (AkamaiGHost/9.6.2.0.1-25325260) (-)
X-Cache-Key: S/L/16382/612780/0s/www.yourdomain.de/ cid=what_TOKEN=dings_
X-Cache-Key-Extended-Internal-Use-Only: S/L/16382/612780/0s/www.yourdomain.de/ vcd=1948 cid=what_TOKEN=dings_
X-True-Cache-Key: /L/www.yourdomain.de/ vcd=1948 cid=what_TOKEN=dings_
X-Akamai-SSL-Client-Sid: lZWwRTj17XXXXXXXXXU5Cw==
X-Check-Cacheable: NO
X-Akamai-Request-ID: f82516c
Some important parts:
- TCP_MISS shows that Akamai didn’t use it’s cache for this request, but the origin
- X-Cache-Key shows what Akamai used to reference the cache position. In this case the url was http://www.yourdomain.de/?what and a cookie named TOKEN was included in the cacheID (“cid=…”)