Comment 2 for bug 913895

This came out of a meeting with Jorge Williams yesterday. My understanding is that keystone can't be deployed behind an HTTP cache as-is. If you did, you would might see the following behavior.

---

Request from Client 1:

    GET /tenants
    X-Auth-Token: 12345

HTTP Cache: no existing cache; reverse proxies request

Keystone Response:

    { /* tenants specific to token 12345 */ }

HTTP Cache: caches response

Client 1 receives the appropriate tenant list.

---

Request from Client 2:

    GET /tenants
    X-Auth-Token: 67890

HTTP Cache: Existing cache found for GET /tenants

HTTP Cache Response:

    { /* tenants specific to token 12345 */ }

Client 2 receives tenant list for Client 1.

---

Appending a Vary header to the Keystone response would instruct the cache to differentiate between responses relevant to different tokens (i.e. vary the cache response based on the X-Auth-Token header). The same solution would also apply to the new X-Subject-Token header.