Hi,
I’ve been looking through the GeoServer source code to determine the reason why I can’t get a layergroup to updated the expiration headers and found two key references.
CachingWebMapService.java has a function at line 192 getCacheAge which appears to rely on the settings I just mentioned on the users group (those on the publishing tab). If those settings are not set then the result will be null and so the calling function will set the Cache-Control header as no-cache.
In fact there is even a comment in that function noting that it prevents cache control on layergroups.
The other reference is found in MapLayerInfo.java but it effectively performs the same function in a different order and uses both the settings on the publishing tab.
I can’t find any reference to the settings which are found on the Tile Caching page but I do know the settings end up in the gwc-layers configuration for the embedded version of GWC.
I can see why the layergroup is an issue but on line 131 of CachingWebMapService.java the if/then statement only checks for null. Would we not fix the issue of we split out the check for enabled for the check for the expiration time as done in the MapLayerInfo.java?
I am assuming here that GWC is using the expireClients setting to set the header but the embedded WMS settings are overriding the GWC setting with no-cache. What would happen if the logic was:
···
- CACHING_ENABLED = null: do not set the header at all in CachingWebMapService
- CACHING_ENABLED = true/false: check the CACHE_ AGE _MAX and return value or no-cache if null
Would that then allow GWC to set the header in the case of layergroups?
Thanks,
Paul
Hi,
Further to the comment below I have attempted to create a change to my fork on github which can be seen here:
https://github.com/paulwittle/geoserver/commit/e4d5dd657551d90e839e6cd8108f67c845f57d04
I hope that is ok, I’m still very new to this but I’m pretty sure that is an update to my copy only. Hopefully it will let you see what I’m talking about in a more suitable format though.
Cheers,
Paul
···
From: Paul Wittle via Geoserver-devel [mailto:geoserver-devel@anonymised.comceforge.net]
Sent: 07 December 2017 12:14
To: ‘geoserver-devel@lists.sourceforge.net’ geoserver-devel@anonymised.coms.sourceforge.net
Subject: [Geoserver-devel] Layergroup cache headers
Hi,
I’ve been looking through the GeoServer source code to determine the reason why I can’t get a layergroup to updated the expiration headers and found two key references.
CachingWebMapService.java has a function at line 192 getCacheAge which appears to rely on the settings I just mentioned on the users group (those on the publishing tab). If those settings are not set then the result will be null and so the calling function will set the Cache-Control header as no-cache.
In fact there is even a comment in that function noting that it prevents cache control on layergroups.
The other reference is found in MapLayerInfo.java but it effectively performs the same function in a different order and uses both the settings on the publishing tab.
I can’t find any reference to the settings which are found on the Tile Caching page but I do know the settings end up in the gwc-layers configuration for the embedded version of GWC.
I can see why the layergroup is an issue but on line 131 of CachingWebMapService.java the if/then statement only checks for null. Would we not fix the issue of we split out the check for enabled for the check for the expiration time as done in the MapLayerInfo.java?
I am assuming here that GWC is using the expireClients setting to set the header but the embedded WMS settings are overriding the GWC setting with no-cache. What would happen if the logic was:
- CACHING_ENABLED = null: do not set the header at all in CachingWebMapService
- CACHING_ENABLED = true/false: check the CACHE_ AGE _MAX and return value or no-cache if null
Would that then allow GWC to set the header in the case of layergroups?
Thanks,
Paul
“This e-mail is intended for the named addressee(s) only and may contain information about individuals or other sensitive information and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this email in error, kindly disregard the content of the message and notify the sender immediately. Please be aware that all email may be subject to recording and/or monitoring in accordance with relevant legislation.”