On Wed, Jul 29, 2026 at 2:28 PM Branko Čibej <[email protected]> wrote: > > On 29. 7. 2026 20:13, Nathan Hartman wrote: > > On Wed, Jul 29, 2026 at 9:46 AM Branko Čibej <[email protected]> wrote: > (snip long earlier quoted text) > > Changing this in the source code just smells wrong to me. I had a quick look > and it appears that none of the HTML responses from apache.org have any cache > control headers set. However, the response for our 'style/site.css' does have > both ETag and Last-Modified (about 3 hours ago on the main site, apparently). > Still, since there's no Cache-Control max_age or similar, any browser can > decide to cache the page as long as it likes. > > The correct way to fix this is to set cache-control headers appropriately, > but this should be done by Infra, not us. > > -- Brane > > This sounds like the correct solution to me. > > I'm happy to ask Infra; what max age should we ask for? Is there some > customary value for this? > > > > I think this is something Infra should figure out. From the headers I saw, > there are clearly caching proxies between the origin and the browser, so > cache control of responses is not a straight-forward choice. The settings are > already different for static resources vs. generated ones. Caching is a > balancing act between reducing load on the origin servers, reducing latency > for users and keeping the info up to date. Only Infra knows all the pieces > that are involved. > > IMO the right approach would be to explain this particular "error" to Infra > and ask them to do something about cache control. > > -- Brane >
Filed INFRA-28199: Cache control headers for subversion.apache.org website https://issues.apache.org/jira/browse/INFRA-28199 Thanks, Nathan
