Re: Introduce contributor badges

On Fri, 16 Oct 2026 at 16:18, Christoph Berg <myon(at)debian(dot)org> wrote:

> Re: To Dave Page
> > > ## Varnish cache invalidation
> >
> > > 4. **The image URL never changes when the image does.**
> > > `/community/badge/<slug>/image/` has no file extension and no version
> in
> > > it. The docs say Varnish applies a longer policy to images "because
> they
> > > are considered never to change". Varnish itself is purged, but if the
> > > Varnish configuration (VCL) also sends long browser cache headers for
> > > images, browsers will keep showing the old image.
> >
> > I think purging Varnish is enough here. Badge image changes aren't
> > critical, if a user sees the image somewhat longer, that doesn't cause
> > trouble.
>
> I did more research on this point, and that's the result (poking
> around and by Deepseek):
>

<cut some AI bleh>

> No URL versioning. It requires a schema change, and the repository's
> own contract (s-maxage) is
> that only Varnish caches. Adding ?v=<hash> "to avoid the question"
> pays a real cost to guard against a
> configuration the app already argues against.
>

Agreed, no need for URL versioning.

On the related "minor" comment:
>
> > - `badge_image` fetches the image and computes its MD5 before it checks
> > `If-None-Match`; storing the hash would avoid both.
>
> badge_image is only reached on a Varnish miss, and on a miss we're
> almost always about to serve the image anyway. Storing the hash only
> helps the narrow (?) "Django itself receives a conditional request"
> case.
>

No, on the vast majority of misses we'd be serving a 304 Found with no
content. Every time an image expires in any of the caches it would send a
conditional request.

(I have not looked at the rest, so I reserve the right to further review)

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>