You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following behavior was reported when using Cljdoc badges on Github:
When refreshing the Github page shortly after a successful build of a newer release version, the link of the Cljdoc badge already resolves to the newer release version, whereas the Cljdoc badge SVG is still showing the old version. This is probably due to our caching configuration for badges.
It looks like we could use the not-modifiedring middleware to do etags and lowering the max-age is pretty simple. I wonder how many more requests we'd be talking, though, and how the server would do under the extra load?
<aside>
Coming at this from another angle: If we could throw something like Varnish in front of cljdoc we could control our own caching and evicting and serve a ton more reqs/s without breaking a sweat. I'm not sure that's something people would be up for, though.
</aside>
The following behavior was reported when using Cljdoc badges on Github:
When refreshing the Github page shortly after a successful build of a newer release version, the link of the Cljdoc badge already resolves to the newer release version, whereas the Cljdoc badge SVG is still showing the old version. This is probably due to our caching configuration for badges.
max-age
to 30 min for badges: https://github.com/cljdoc/cljdoc/blob/master/src/cljdoc/server/pedestal.clj#L332Maybe an option could be to introduce conditional requests by setting the
Last-Modified
orETag
response header for badges?The text was updated successfully, but these errors were encountered: