Unify Cache-Control handling

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.

After looking through the Cache-Control handling, it appears somewhat fragmented.

In the example NGINX conf (note: it needs work) adapted from the Apache setup, there is Cache-Control handling done for static assets (CSS, JS, SVG, GIF, WOFF). The example chooses 6 months for CSS, JS, SVG, and GIF, while choosing 7 days for WOFF. The arbitrary choices here and the exclusion of image previews got me wondering about Nextcloud Cache-Control. Removing web server Cache-Control, this is what I see at a glance (not scientific, please correct).

• Almost all CSS has Cache-Control (1 year)
• Very little JS has Cache-Control (1 year)
• The logo has 1 year
• Theming resources have 1 day
• Image previews have 1 day
• SVG does not have it

After searching the code base for cacheFor usage, I see that there are several hardcoded values to use for max-age. Mostly, either an hour or a day. 86400, 24 * 3600, 60 * 60 * 24, 3600, etc. Since these values are all hardcoded, and differently, it is difficult to tell whether they are somewhat arbitrary or uniform.

As a result of all this, I can't tell what I am supposed to be doing about my Cache-Control.

Describe the solution you'd like

• Choose and document what Cache-Control should be done by Nextcloud vs. what should be done by web server
• Use common constants for max-age, e.g. JS_CACHE_CONTROL_MAX_AGE, IMAGE_PREVIEW_... or an enumerated value CacheControlMaxAge.JS
• Apply the design choices uniformly across functions

Note that since most [which?] if not all assets appear to be versioned, so we should not be afraid of setting the max-age to 1 year for all "light" assets. For the images with Cache-Control, a day is probably a pretty good choice.

Describe alternatives you've considered

Remove all Cache-Control and leave it to the web server

Pros

• uniform management
• don't have to worry about new routes or apps since the web server layer would handle all
• less, simpler code
• users can decide

Cons

• hard to handle different assets of the same type differently, especially applicable to images
  • would require well-documented routes e.g. for preview images
• naive users do not handle
• can make well-informed decisions in the Nextcloud layer

Middle ground idea

Only handle image Cache-Control in Nextcloud (not including SVG, GIF), and leave all else to the web server

Additional context

• How are app assets integrated?
  • Are they necessarily versioned?
  • Is Cache-Control for them handled in the Nextcloud layer?

Start by reviewing the example NGINX configuration linked in the issue, then search the codebase for cacheFor and the hardcoded max-age values. Inventory how static assets, theming resources, previews, and app assets are handled; done means documenting ownership between Nextcloud and the web server and defining a consistent policy.