cacheControlMaxAge Property is not working

[ShakibaMorvarid]

My intent is to have cached features for 24 hours. I am following the instruction on this link https://enterprise.arcgis.com/en/server/latest/publish-services/windows/feature-services-and-client-...

I set cacheControlMaxAge to 24 hours on ArcGIS Admin but when I see the response header still the max-age is 0. I appreciate if anyone can help.

this is how response header looks like:

I am using this service in my application. 

arcgis/rest/services/........../FeatureServer/0/query?f=json&where=

this is how my service looks like regarding cacheControlMaxAge

[LanceKirby2]

Hey I am running into the same issue. Did you ever resolve this?

[LeonAus]

Still doesn't seem to be working in Enterprise 10.9.1.

Reading some old documentation though, I don't think it's supposed to work for all MapServer endpoints:

Optional. Added in 10.2.1. If this property is set cache-control response header max-age value for REST API Export Map and tile resource responses will reflect the value set for this property. Otherwise default values will apply for max-age, which is 0 seconds(s) for export map, 86400 (s) for tiles that client can cache (clientCachingAllowed : true) and 0 (s) for tiles that disallow client caching (clientCachingAllowed : false). Please note cache-control header max-age value for tile responses will be always 0 if client caching is disallowed. Setting this property will have no effect in cache-control response header value for other operations/resources.

Maybe the query endpoint counts as an other operations/resources. 

[ChrisBeaudette]

I can confirm that the cacheControlMaxAge still isn't working as advertised in v11.1.  

I opened a ticket with support on this and their response was:  "We're thinking that because of security the developer tools may not be able to read the cache control max age based on the JSON. As long as in the properties of the service it sys that the cache control max age is set, it is considered to be functioning as expected."

I have an idea what they mean but I don't know exactly and it appears as though it can't be reliably confirmed.

[LanceKirby2]

I spoke to one of the devs at the UC this year and he asked me to email about it. I will follow up when I do.

[FredSpataro]

Found myself here hoping for the enlightenment but found everyone having the same issue...

tldr: I think it's working, just not obvious to prove....

Assuming @ChrisBeaudette's (tag your it 😏) response from esri is valid then there must be some other way to prove it's working so I kept digging a bit and think I found the way to verify it is in fact working. 

Setup:

V11.1 standalone server

Query operation on MapServer/1

"cacheControlMaxAge":"3600"

I've been expecting to see some clear 'it's from cache' cue in the chrome dev tools... but never see a 304 response or 'disk/memory cache' in the size column and the response header always displays: the max-age:0;must-revalidate... chalking it up to the 'javascript fetch/etag' implementation and whatever about security that esri mentioned. 

So, the chrome dev tools network tab has a handy little checkbox "Disable cache'.  Using this and the same service from two different servers (one with the cache control set and one without), I see this:

Requests to first server with cache control setting at 3600 

Enabled, Enabled, Disabled, Disabled, Enabled

I had been hitting the service a bunch so the first requests are already cached (small), then disable the local cache, boom... larger network transfer, then re-enable the local cache, back to smaller 

Requests to second server with cache control setting not defined

Enabled, Enabled, Disabled, Disabled, Enabled, 

Always 709, as expected no difference b/c there's no cache setting

Painful but I think isn't enough to convince myself it's doing what I want and it's worth deploying the setting.