Add nginx location to handle /secure-media-uploads/ requests .ico files were getting a 404 when being looked for via /secure-media-uploads/. this nginx config addition fixes the issue.
* FEATURE: Normalize the service worker route
Update cache headers so they are not immutable outside of the rails app
Add the ability to purge the service worker cache from localhost
Rails -> nginx will pass immutable flags so the file is cached until reloaded.
In most cases, nginx will have its cache flushed on rebuild (new image)
For those needing dynamic re-caching (such as upgrading via the UI),
a rake task for flushing the service worker script is provided
through `assets:flush_sw`
Previously our cache would expire any asset that was not accessed for 10
minutes. This is way too short and was never intended. All the assets we
are serving are usually very long living assets like avatars and css files
1 day is a reasonable setting here cause it offers far better protection.
I would consider upping this to a week though longer term.
Maximum disk space of cache was increased as well to 600m. Very unlikely to
ever hit this except on very large sites.
Additionally, this places all the cached assets in nested directories, we
never want cached files to be in one giant directory cause it is inefficient
Co-authored-by: Sam Saffron <sam.saffron@gmail.com>
Co-authored-by: David Taylor <david@taylorhq.com>
This gives more control over the request. In particular we can easily
lookup DNS dynamically, instead of only upon NGINX startup.
Previously, NGINX was looking up IP for the letter avatar service and
caching the CDN IP address, this caused issues if CDN changed IP, in
which letter avatars would be broken till a container restarted.
NGINX config has been updated to add caching. This change will require
a container rebuild.
The proxy will now function in development environments, so the patch
for `letter_avatar_proxy` has been removed.
This is crucial in multisite installations, because otherwise the nginx logs
are fairly useless, however it can also be quite handy to know what
hostnames are being sent to your site. The variable is quoted, because it
is untrusted input (it is taken directly from the HTTP request), but nginx
helpfully escapes the quoting character automagically, so we don't have to
worry about that.
For now, the log analysis plugin *recognises* the new log format
(and continues to recognise the previous format, for backwards
compatibility), but doesn't do anything with the new log entry field. This
means your multisite performance plugin data is still broken, but it's no
worse than it was before.
On sites that don't otherwise configure an avatar fallback, Discourse will
now tell the client to get its letter avatars from a location which nginx
proxies to the centralised `avatars.discourse.org` service. This alleviates
privacy concerns, whilst still providing some degree of performance benefit
(no need for every site to delay avatar response by 300ms for image
rendering).
It is still possible to gain the benefits of global image caching and the
lower latency of requesting directly from a CDN, by explicitly changing the
`external_system_avatars_url` site setting to
`https://avatars.discourse.org/letter/{first_letter}/{color}/{size}.png`.