Cache-Control: no-cache from client request makes the response itself non-cacheable

[khaled4vokalz]

Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

2.8.1

Current Behavior

When I do

$ curl --silent --dump-header - --header "cache-control: no-cache" --request GET http://localhost:8000/foo-bar/ --output /dev/null
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 4556
Connection: keep-alive
X-Cache-Status: Bypass

to bypass the cache for the current request, the response for this never gets cached. Which is not what the RFC says. The RFC mentions that the request should not use the stored cache.

This creates a situation where someone wanting to force revalidate a cached object using the Cache-Control: no-cache/no-store header fails to do so as kong always bypasses storing the object in the cache.

It doesn't look like an expected behavior. At least nginx itself doesn't foce anything like this. I can always add some nginx config like below that'll skip the nginx proxy_cache and refill it based on the response headers.

  map $http_cache_control $is_no_cache_header_present {
    default 0;
    "~*no-cache" 1;
  }
  
  proxy_cache_bypass $is_no_cache_header_present;

Expected Behavior

we should not decide if the response is cacheable or not based on the request Cache-Control headers, rather it should only be decided based on the response Cache-Control header as the RFC mentions.

Also, it should not be tied to the cache_control configuration as well which is used currently for both request and response. If anything there should be a separate configuration for request IMO.

FYI, the existing behavior of the no-store directive is correct; as described in the RFC

Steps To Reproduce

1. Just enable proxy_cache in a service/route which works

2. enable cache_control

3. curl --silent --dump-header - --request GET http://localhost:8000/foo_bar/ --output /dev/null gives you

   ...
   X-Cache-Status: Miss
   ...
   

4. curl --silent --dump-header - --request GET http://localhost:8000/foo_bar/ --output /dev/null gives you

   ...
   X-Cache-Status: Hit
   ...
   

5. curl --silent --dump-header - --header "cache-control: no-cache" --request GET http://localhost:8000/foo_bar/ --output /dev/null gives you

   ...
   X-Cache-Status: Bypass
   ...
   

6. curl --silent --dump-header - --request GET http://localhost:8000/foo_bar/ --output /dev/null gives you

   ...
   X-Cache-Status: Hit/Miss (depends on the TTL configured)
   ...
   

   which is the previous cached object, not the revalidated one as it was never cached.

[xianghai2]

That's expected behavior, refer to https://docs.konghq.com/hub/kong-inc/proxy-cache/#cache-control.
"the behavior of no-cache is simplified to exclude the entity from being cached entirely"

[khaled4vokalz]

but, @xianghai2 , why is that? To me it seemed like just a small change in the existing handler in proxy_cache. e.g. (Haven't tested it myself BTW)