Dat kan. Uw applicatie is zelf verantwoordelijk voor het zetten van correcte caching headers. In praktijk betekent dat, dat tenzij het de frontproxy cache expliciet verboden wordt (mbv Cache-Control HTTP headers) deze alles zal proberen te cachen. Lees vooral de Gouden Frontproxy Regels over HTTP/1.1 caching! Uw applicatie kan invloed op de cache uitoefenen dmv Expires, Last-Modified en Cache-Control headers. Indien deze niet gezet wordt houdt de proxy cache op de meeste pagina's een relatief korte expiry tijd van 30 seconden aan.

Zie nogmaals de Gouden Frontproxy Regels Vermoedelijk is dit een caching probleem, veroorzaakt door het niet zetten van de juiste caching headers. Het kan zijn dat op de pagina in kwestie geen cache-control header stond. Het is echter ook mogelijk dat er met cookies iets mis gaat. Het volgende scenario is mogelijk:

• Stel u gebruikt tomcat sessies op cachebare objecten (denk bv aan plaatjes die uit de database komen). Tomcat implementeert dit door een Set-Cookie header mee te geven.
• Omdat het een cachebaar object was, zal de Set-Cookie in de frontproxy cache terechtkomen en krijgen meerdere mensen dus hetzelfde cookie.
• Stel nu dat een van deze mensen gaat inloggen. Afhankelijk van hoe uw applicatie gebouwd is wordt er niet een nieuw cookie gegenereerd, maar worden er extra rechten aan het bestaande cookie gehangen.
• Hierna gaat iemand anders die hetzelfde cookie had naar uw site, en daar is het opeens alsof hij ingelogged is als de andere gebruiker en ziet dus diens prive sessie.

De oplossing is ervoor te zorgen dat op cachebare objecten geen cookies gezet worden, en er tegelijk voor te zorgen dat dingen waar wel een cookie op gezet wordt, dat later als basis voor authenticatie moet dienen, ervoor te zorgen dat dit ook prive blijft, door de juiste Cache-Control headers te zetten.

In dit punt (het cachen van Set-Cookie headers) ligt een belangrijk verschil tussen apache en squid als frontproxy: apache doet het wel en squid doet het niet. Wat squid doet is tegen de RFC in: deze cached het object, maar sloopt de Set-Cookie header eruit alvorens het object naar de client te sturen.

Ja, op verzoek kan dat. Wij raden het echter ten sterkste af. Als de cache uitgezet wordt, komt alle load bij tomcat terecht en die is er niet op gebouwd om onder zware load te blijven functioneren. Een beter alternatief (als er bv geen tijd is om eea goed te regelen) is ervoor te zorgen dat alle plaatjes cachebaar zijn, en in de rest caching te verbieden. Als de plaatjes door de frontproxy gecached mogen worden, kan meestal 95% van de hits door de frontproxy afgehandeld worden.