: Eliminating 'cookie' from 'vary:' without breaking website functionality I read that some middle-man servers won't cache websites that have cookie set in the vary: header. For example, If my website

@Cooney921

Basically, you want to get to a point where your HTML page is the same for all users, regardless of their configuration. This is only really possible if you can apply all of the customisation with javascript.

To continue your example, let's say you allow users to customise the background colour of the page, and this choice is stored in a cookie. If you apply this colour change using javascript (which reads the cookie and then makes the necessary CSS change client side), your HTML page remains the same for all users, and you don't have any issues with this page being cached.

Using IP address would be a bad idea. You can't rely on each user having a different IP address, and you can't rely a user always having the same IP address. But regardless of these factors, caching the configuration by IP as you described wouldn't solve your problem.

I'm assuming by "middle-man cache" you're referring to HTTP proxies like Squid - caches between you and your users that you have no control over. (This is slightly different to something like Varnish, which you mentioned, which you'd install on your server and would have full control over.)

I went to a campus university which had around 10,000 students. All external web traffic went through a web cache in order in order to minimise unnecessary outside traffic. So this is an example of the type of cache I think your question refers to.

Let's say you've setup your site to cache configuration by IP address and removed the vary cookie header. A student at my old uni visits your site and sets the background colour to pink. Your server stores this configuration along with the users IP address (which would be the uni web cache IP), and sends back the modified HTML page with the pink colour applied. The uni web cache caches this pink page since its headers indicate it can do so. 5 minutes later student B visits your site. The uni cache would serve student A's pink page to student B, and crucially this request would never reach your server at all. Even if this second request did reach your servers, student B would have the same IP as student A, so your server would just send back the same pink page.

Now let's say you'd implemented this using javascript instead. Student A visits your site, sets the page to pink. Using JS, your page sets a cookie and applies the pink colour (client side). The uni web cache caches the HTML page. Student B visits your site, the uni cache serves the cached page, which would be the standard one. Student B would see the normal, non-pink page, since they wouldn't have the colour change cookie.

Of course, it's not always possible (or desirable) to do all customisation using javascript. Whether or not this will work for you will depend on your specific use case (which I assume is more complicated than setting a background colour).

To give another example, I worked on a site a few years ago which used Varnish. This was a high traffic site, so we wanted it to be as cache friendly as possible, but users who were logged in needed some extra functionality which was very specific to them. Logged in users represented a very small proportion of the site traffic (<1%). I wrote a custom PHP session handler which stored sessions in the database, but would only create them if they contained data. I configured Varnish to not serve cached pages if the request included the session cookie. This meant Varnish could handle the vast majority of traffic, but as soon as a user logged in, all their requests would go straight through to PHP.

Vote Up Vote Down