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'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 'cache-control|expires'<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 'cache-control|expires'<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--