4 ms·

dynamic with caching (e.g. Varnish) is like static from security and response time perspective..but static has the advantage of local distributed fronts (cloudf

dynamic with caching (e.g. Varnish) is like static from security and response time perspective..but static has the advantage of local distributed fronts (cloudfront)... If we think, 99% of all blogs will be read less than 1000 times per day, the performance consideration does not matter.

jacquesm 12y ago
I don't agree at all that 'dynamic with caching' is like static from a security perspective. It's very easy to bust the cache (simply affix a random bit of nonsense to the end of the urls) and force dynamic execution of every request you make, opening you up to all the security issues that a direct dynamic front-end would give.
- dreamfactory2 12y ago
  That's just a question of cache config surely.
  - jacquesm 12y ago
    Only if you have prior knowledge of what URLs are possible. If you don't then the front-end cache will have to play it safe and will have to pass the request to the backend if it does not know the URL. Any kind of variability in the request that causes a conversation between the front-end and the back-end and the cache can be busted, or is a potential DOS vector. Please show me a caching front-end with a dynamic back-end that you control and that you think is protected against cache busting and we'll discuss that off-line. I'd hate to expose you to some joker taking you down just to make the point. A cache can even become it's own enemy, for instance, if it passes requests on to the backend server if the GET contains url parameters and these make the request unique in the eyes of the cache but not unique in the eyes of the back-end then the cache could easily eat up a ton of memory even though from the back-ends perspective the same page got hit over and over again. Caching is tricky.
    - dreamfactory2 12y ago
      That's what wildcards are for surely. We cover the same cases in MVC routers.

jacquesm 12y ago

I don't agree at all that 'dynamic with caching' is like static from a security perspective. It's very easy to bust the cache (simply affix a random bit of nonsense to the end of the urls) and force dynamic execution of every request you make, opening you up to all the security issues that a direct dynamic front-end would give.

dreamfactory2 12y ago
That's just a question of cache config surely.
- jacquesm 12y ago
  Only if you have prior knowledge of what URLs are possible. If you don't then the front-end cache will have to play it safe and will have to pass the request to the backend if it does not know the URL. Any kind of variability in the request that causes a conversation between the front-end and the back-end and the cache can be busted, or is a potential DOS vector. Please show me a caching front-end with a dynamic back-end that you control and that you think is protected against cache busting and we'll discuss that off-line. I'd hate to expose you to some joker taking you down just to make the point. A cache can even become it's own enemy, for instance, if it passes requests on to the backend server if the GET contains url parameters and these make the request unique in the eyes of the cache but not unique in the eyes of the back-end then the cache could easily eat up a ton of memory even though from the back-ends perspective the same page got hit over and over again. Caching is tricky.
  - dreamfactory2 12y ago
    That's what wildcards are for surely. We cover the same cases in MVC routers.