About www.debian.org/security (/dsa) HTTP caching

Ville Skyttä <[email protected]> Fri, 24 Jul 2026 10:35:37 +0300
Newsgroups gmane.linux.debian.devel.www
Message-ID <CAOdXSVSc=Qr3juPdV+RVYB1JUXauHs6h6nXUd0CO5eOe1Pzd0g@mail.gmail.com>
--000000000000ddf1ab0657566b7f
Content-Type: text/plain; charset="UTF-8"

Hello!

I noticed that the https://www.debian.org/security/ page and the
https://www.debian.org/security/dsa feed are served with HTTP headers that
allow their content to be cached up to 24 hours by clients or intermediate
proxies/caches (see details at end of this mail).

Considering the information at these URLs is security related as it lists
advisories, I was wondering if it is intentionally configured this way?

I understand that the page and the feed are not the primary sources for
this information but the debian-security-announce mailing list is, but
especially the feed is likely something through which its consumers expect
to see relatively up to date info. I gather the website is built every 4
hours, so as it stands it could be that the info is 4 hours + 24 hours +
(whatever the feed client's own delay happens to be at that point) old when
it is delivered to the user.

This could be alleviated client side by forcing the fetch ignoring the
cache-control/expires, but not all clients have an option to do that. For
example, the Slack RSS app does not,
https://slack.com/help/articles/218688467-Add-RSS-feeds-to-Slack

So, maybe consider if the max-age/expires for these pages could be
shortened?

$ date
Fri Jul 24 10:23:40 AM EEST 2026
$ curl -sI https://www.debian.org/security/ | grep -E
'cache-control|expires'
cache-control: max-age=86400
expires: Sat, 25 Jul 2026 07:23:46 GMT
$ curl -sI https://www.debian.org/security/dsa | grep -E
'cache-control|expires'
cache-control: max-age=86400
expires: Sat, 25 Jul 2026 07:23:51 GMT

Cheers, Ville

--000000000000ddf1ab0657566b7f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello!</div><div><br></div><div>I noticed that the=C2=
=A0<a href=3D"https://www.debian.org/security/">https://www.debian.org/secu=
rity/</a> page and the=C2=A0<a href=3D"https://www.debian.org/security/dsa"=
>https://www.debian.org/security/dsa</a> feed are served with HTTP headers =
that allow their content to be cached up to 24 hours by clients or intermed=
iate proxies/caches (see details at end of this mail).</div><div><br></div>=
<div>Considering the information at these URLs is security related as it li=
sts advisories, I was wondering if it is intentionally configured this way?=
</div><div><br></div><div>I understand that the page and the feed are not t=
he primary sources for this information but the debian-security-announce ma=
iling list is, but especially the feed is likely something=C2=A0through whi=
ch its consumers expect to see relatively up to date info. I gather the web=
site is built every 4 hours, so as it stands it could be that the info is 4=
 hours + 24 hours + (whatever the feed client&#39;s own delay happens to be=
 at that point) old when it is delivered to the user.</div><div><br></div><=
div>This could be alleviated client side by forcing the fetch ignoring the =
cache-control/expires, but not all clients have an option to do that. For e=
xample, the Slack RSS app does not,=C2=A0<a href=3D"https://slack.com/help/=
articles/218688467-Add-RSS-feeds-to-Slack">https://slack.com/help/articles/=
218688467-Add-RSS-feeds-to-Slack</a></div><div><br></div><div>So, maybe con=
sider if the max-age/expires for these pages could be shortened?</div><div>=
<br></div>$ date<br>Fri Jul 24 10:23:40 AM EEST 2026<br>$ curl -sI <a href=
=3D"https://www.debian.org/security/">https://www.debian.org/security/</a> =
| grep -E &#39;cache-control|expires&#39;<br>cache-control: max-age=3D86400=
<br>expires: Sat, 25 Jul 2026 07:23:46 GMT<br>$ curl -sI <a href=3D"https:/=
/www.debian.org/security/dsa">https://www.debian.org/security/dsa</a> | gre=
p -E &#39;cache-control|expires&#39;<br>cache-control: max-age=3D86400<br>e=
xpires: Sat, 25 Jul 2026 07:23:51 GMT<br><div><br></div><div>Cheers, Ville<=
/div></div>

--000000000000ddf1ab0657566b7f--