invocation specific rustdoc static files are cached too long on `/latest/`

I want to clarify / wrap up a caching issue I'm seeing. We discovered it in the discussion in #1590 (partially fixed by https://github.com/rust-lang/rust/pull/92742).

For rustdoc we serve three kinds of static file types:

• unversioned-shared-resources like fonts. Will be served from static-root-path with its filename, not hashed. Cached forever, can never change.
• toolchain-shared-resources are static files that might only change when the toolchain (nightly) changes. Will be served from static-root-path but includes the toolchain version in the filename (via --resource-suffix). Will be cached forever, when these change, the file name and its references in the HTML changes.

Now we come to invocation-specific, for example sitebar-items.js and search-index.js:

• in the past we only served these under a URL that includes create/version.
• so under the assumption that a certain release with a certain nightly will always get the same output for these, just adding the same night resource suffix is good enough.

Now with /latest/ the URL for these invocation-specific items don't contain the version any more.

so, if there are two releases of a crate with the same nightly version, the cache will still serve the invocation-specific files for both releases

possible solutions?

• I'm not sure about the best one. Our first thought was adding a timestamp or the release to the resource-suffix. The problem is that this would also change the suffix for toolchain shared resources. Which would be a performance issue, and also we would have to change static file serving for these.

Another approach could actually be doing the first step towards #1552 by creating an invalidation-request for /crate_name/* after each release.

I'm open for other ideas.

Start by tracing how /latest/ serves invocation-specific assets such as sitebar-items.js and search-index.js, and how resource-suffix is applied to static-root-path files. Compare releases of the same crate using the same nightly to reproduce the cache collision. Done means invocation-specific files cannot be reused across releases while toolchain-shared resources retain their existing cache behavior.