Re: svn commit: r1936555 - in subversion/site/staging: . blog docs docs/community-guide docs/release-notes pronunciation security style

On Wed, Jul 29, 2026 at 2:28=E2=80=AFPM Branko =C4=8Cibej <[email protected]=
> wrote:
>
> On 29. 7. 2026 20:13, Nathan Hartman wrote:
>
> On Wed, Jul 29, 2026 at 9:46=E2=80=AFAM Branko =C4=8Cibej <[email protected]=
rg> wrote:
> (snip long earlier quoted text)
>
> Changing this in the source code just smells wrong to me. I had a quick l=
ook 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 a=
re 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 Inf=
ra 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