fix: index html caching

[KaiVandivier]

This should fix these two issues, which both seem to be caused by HTML files being cached and served by the browser:

• DHIS2-17782
• DHIS2-17804

It seems that in v42, responses for HTML files are missing the Cache-Control: no-cache, no-store, max-age=0, must-revalidate headers that previous versions added to responses -- these changes reintroduce them

To do

• Consider HTML files to handle -- currently handling all HTML files; could instead handle only index.html and plugin.html for routes like /dhis-web- and /api/apps/, for example. Consider other HTML files, like custom reports or custom data entry forms
• Think about what the implications might be of doing this for non-app html files (or html files that aren't index or plugin).
• Need to think about where this should be placed... are bundled apps served with this servlet?
• Why did this stop working in v42? Possibly due to restructuring to support embedded tomcat and/or removal of struts for bundled app serving
• Rename this filter; maybe reuse the app override filter

Testing

The change can be tested by opening up apps and checking the response headers on HTML files -- they should include the Cache-Control headers above. Other requests should not all have the same headers -- a few do, like /api/me/dashboard and api/system/info, but not all. NB: If opening up apps at a URL that hosted a previous v42 instance, you made need to get past previously cached versions of index.html, which can be done by reloading multiple times, hard reloading, or using the Disable Cache option in the Network panel of dev tools

Here are some examples of response headers after the changes:


![Screenshot 2024-08-27 at 2 15 35 PM](https://github.com/user-attachments/assets/3dd951bf-9564-4701-b4bf-b7e933a1133



6)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[amcgee]

Looking good! Few minor comments as discussed.

@netroms could you take a quick look at this to make sure we're doing the filtering in the right place? Thanks!

[amcgee]

This change looks good to me! Tested here https://dev.im.dhis2.org/pr-18458

[jbee]

No can't do it like this. I know of HTML we do want to cache. So the headers need to be added to the specific endpoints, not always for all HTML responses.

[amcgee]

No can't do it like this. I know of HTML we do want to cache. So the headers need to be added to the specific endpoints, not always for all HTML responses.

@jbee which HTML are you thinking of?

We discussed making the regex more targeted, we can do that if there are html files elsewhere that should be cached. It is generally always problematic to cache application root html files, and this was the previous behavior. @netroms and I also discussed that we need to address static asset caching headers more holistically so this will be updated before 42.

[jbee]

@amcgee I was thinking about the /openapi/openapi.html and others in the /openapi path. But you are also allowed to use /api/dataElements/openapi.html and so forth.

[KaiVandivier]

Thanks @jbee!

Regarding the Maps app, I tried switching the order of operations in the filter as recommended:

chain.doFilter(request, response);

if (m.find() && HttpMethod.GET.matches(request.getMethod())) {
  ContextUtils.setNoStore(response);
}

But still the headers don't seem to get applied to the Maps app 🤔 any other ideas? @amcgee

(This screenshot is from before changing the order, but it still looks the same after -- included for illustration)

[jbee]

@KaiVandivier in that case I would revert the change of order again. Send me a message on slack so we can talk about the request this does and I maybe can help debugging it.

[KaiVandivier]

The Maps HTML seems to be working fine on the IM deployment; maybe there was something weird on my local instance 🤔

So I think this is nearly done; just discussing one last thing with Austin

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud