

Context-aware HTTP caching (with Varnish) - asm89
http://asm89.github.com/2012/09/26/context-aware-http-caching.html?hn

======
ericcholis
It's worth noting that sometimes you only have content that differs for your
"logged in" users. Or, content that is the same with the exception of actions
that a user has taken on your site. Say, in the case of a shopping cart.

In that use case, you might find that one cache covers everything except their
shopping cart preview. This is where ESI (Edge Side Includes) come in. I've
never used it in practice, but the idea is similar to server side includes of
yesteryear. Here's a good article:

[http://blog.redfin.com/devblog/2010/05/esi_and_caching_trick...](http://blog.redfin.com/devblog/2010/05/esi_and_caching_trickery_in_varnish.html)

~~~
asm89
Yes, edge side includes are very interesting indeed! We used that for
scenarios like you describe, but there are actually some things you should
take into consideration when using them. Maybe I can dedicate a blog post to
that! :)

~~~
ericcholis
Please do, I'd love to learn from somebody else's experience with them

------
asm89
This is the first blog post I wrote and actually published. Any comments on
content, but also writing style etc are very welcome!

~~~
mmcnickle
I thought it was a great introduction to the topic. I found the jump to pre-
authentication a little jarring, perhaps adding an explanation as to why
caching logged-in users is a problem would help.

In the later examples, I don't think it's very clear that you're using the
timestamps to show which responses are fresh and which are cached. Coloring
the fresh/cached responses differently in the output might help.

Look forward to your next post.

~~~
asm89
Hm, I'm not sure how to introduce the pre-authentication bit even further.
Maybe it isn't the best subtitle.

I agree that colouring the output could make things more clear. I'll keep it
in mind for future articles!

------
ruben_varnish
This article brought back to memory the first paywall like functionality that
was implemented in Varnish, since it was done using the cURL VMOD (and the
reason why it was developed by Varnish Software in the first place).

"Development of this VMOD has been sponsored by the Norwegian company Aspiro
Music AS for usage on their WiMP music streaming service." from
<[https://github.com/varnish/libvmod-
curl#readme>](https://github.com/varnish/libvmod-curl#readme>);

------
purephase
This is great thanks. We use Varnish with our current site iteration and it is
a life saver. It keeps us running without any significant re-architecting on
the backend.

Currently, new directions do not include Varnish but I was starting to re-
consider that position and this article was a nice reminder. Thanks!

~~~
asm89
I think it also depends on how you use Varnish. A lot of web applications can
benefit from the reverse proxy capabilities of Varnish, but if you make
Varnish part of your application stack from day one you can do things like I
describe here. :)

------
Lennie
It reminds me of the recent Varnish Paywall article:

[http://highscalability.com/blog/2012/9/12/using-varnish-
for-...](http://highscalability.com/blog/2012/9/12/using-varnish-for-paywalls-
moving-logic-to-the-edge.html)

