Caching and cache key used in CORS Assertion.

Document ID : KB000012661
Last Modified Date : 14/02/2018
Show Technical Document Details
Introduction:

The CA API Gateway implemented the cors support before version 9.1 using CORS policy which can be found here ( https://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec0000001355.html)

The context variable ${cors.key} referenced in the question below can be found in CORS Processor policy fragment and its value is  ${request.tcp.remoteIp} by default. In version 9.1 onward CORS was implemented as CORS Assertion.

Question:

Is caching in 9.1 CORS assertion similar to CORS Policy? We have implemented the  CORS policy in 9.0 and changed the cache.key to cache using hostname. What default cache key is used in CORS assertion now? 

 

Environment:
9.0,9.1,9.2
Answer:

The ${cors.key} was necessary because we are managing the max-age ourselves so we do store to cache, retrieve from the cache and compare to determine if the max-age has reached. With the new CORS assertion, the cache is handled in the HTTP header. 


For example: (from https://www.fastly.com/blog/caching-cors) 
GET /v1/data HTTP/1.1 
Host: api.example.com 
Origin: http://www.example.com 
HTTP/1.1 200 Ok 
Content-Type: application/json 
Content-Length: 4365 
Access-Control-Allow-Origin: http://www.example.com 
Vary: Origin 
Cache-Control: max-age=3600 

The cache-control is now part of the HTTP header, so SSG does not cache anything. Hence the cors.key is no longer needed. 

Additional Information: