It's possible they're reworking their CMS and that causes files to be moved (breaking links everywhere). Microsoft loves doing that with their developer blogs.
It's funny how CMSes tend to offer "clean URL" configurations (meaning that everything after the origin is 100% controlled by the CMS user) for requests served dynamically (database queries) but requests served statically (public files on disk) often end up containing implementation-specific junk (e.g., "/sites/" in the case of Drupal). The magic that makes clean dynamic URLs (rewrite everything that isn't a file to the boot script) should be expanded to make clean file URLs. Serving files would then need help from a script+db, but so what, that already happens for private files.
Obviously embedded assets that need to be fast (images, stylesheets, scripts, etc.) can't have a slow db query in the way. I'm only talking about files that are a first-class destination in the browser's address bar, like PDFs, and anything where the disposition is that it lands in your Downloads folder. Stuff that might be a search result or otherwise linked-to.
It's kind of clean in that it uses a URL based on a db value instead of the filename on disk, but it's still got CMS-specific junk in that it always starts with "/system/" (at least in D7, I haven't explored it in D9).
Comments
It's possible they're reworking their CMS and that causes files to be moved (breaking links everywhere). Microsoft loves doing that with their developer blogs.
Not cool [0].
It's funny how CMSes tend to offer "clean URL" configurations (meaning that everything after the origin is 100% controlled by the CMS user) for requests served dynamically (database queries) but requests served statically (public files on disk) often end up containing implementation-specific junk (e.g., "/sites/" in the case of Drupal). The magic that makes clean dynamic URLs (rewrite everything that isn't a file to the boot script) should be expanded to make clean file URLs. Serving files would then need help from a script+db, but so what, that already happens for private files.
Obviously embedded assets that need to be fast (images, stylesheets, scripts, etc.) can't have a slow db query in the way. I'm only talking about files that are a first-class destination in the browser's address bar, like PDFs, and anything where the disposition is that it lands in your Downloads folder. Stuff that might be a search result or otherwise linked-to.
[0] https://www.w3.org/Provider/Style/URI
Drupal allow you to set private file mode, which has clean URL.
It's kind of clean in that it uses a URL based on a db value instead of the filename on disk, but it's still got CMS-specific junk in that it always starts with "/system/" (at least in D7, I haven't explored it in D9).