Re: svn commit: r1936555 - in subversion/site/staging: . blog docs docs/community-guide docs/release-notes pronunciation security style
Branko Čibej <[email protected]> Wed, 29 Jul 2026 20:28:45 +0200
| Newsgroups | gmane.comp.version-control.subversion.devel |
|---|---|
| Organization | The Apache Software Foundation |
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------4CouTPZTWRlZEBJ9Rpzi2cv0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------4CouTPZTWRlZEBJ9Rpzi2cv0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 29. 7. 2026 20:13, Nathan Hartman wrote:<br> </div> <blockquote type="cite" cite="mid:CAJT2EHpPuCisTn01EjK+njHdEBpzBWjOYANLaEwoajVTSwPb=Q@mail.gmail.com"> <pre wrap="" class="moz-quote-pre">On Wed, Jul 29, 2026 at 9:46 AM Branko Čibej <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote: (snip long earlier quoted text) </pre> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">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 </pre> </blockquote> <pre wrap="" class="moz-quote-pre"> 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?</pre> </blockquote> <br> <br> 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.<br> <br> IMO the right approach would be to explain this particular "error" to Infra and ask them to do something about cache control.<br> <br> -- Brane<br> <br> </body> </html> --------------4CouTPZTWRlZEBJ9Rpzi2cv0--