Differences

This shows you the differences between two versions of the page.

Link to this comparison view

faq_frontproxy-java [2019/05/28 10:47]
faq_frontproxy-java [2019/09/21 22:57] (current)
Line 1: Line 1:
 +=== Er blijven pagina'​s in de frontproxy cache hangen! ===
 +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 [[http://​hosting.omroep.nl/​sterretje-cluster:​appcluster-hosting_aanleveren-van-java-applicatie?​s[]=frontproxy#​gouden_frontproxy_regels_mbt_java_hosting|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.
 +=== Ik zie de prive sessie van iemand anders! ===
 +Zie nogmaals de
 +[[#Gouden Frontproxy Regels mbt Java hosting|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.
 +
 +=== Kan de frontproxy cache uitgezet worden? ===
 +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.