Hacker News Reader

Comment by WimLeers | Hacker News Reader

> What if the cache can parse cookies and vary the cached response by the value of a specific cookie, not the entire header?

> This is caching that Varnish and other “normal” HTTP caches (including CloudFlare) could not have done.

This is false. I'm not at all very familiar with Varnish, but I know this is easily possible, and has been used for many, many years.

E.g. for Drupal + Varnish, i.e. to only keep Drupal's session cookie, I found these examples, in less than a minute of googling:

- https://www.varnish-cache.org/trac/wiki/VarnishAndDrupal

- https://www.lullabot.com/blog/article/configuring-varnish-hi... (grep for "inclusion")

Everything in this article has been well-known for at least half a decade, yet is being presented as major technical breakthroughs. Too much marketing, IMO.

View on HN

The first example looks nothing like parsing a specific cookie. It merely sanitizes the cookie headers a little, but it doesn't extract out a specific cookie to use as cache key.

And both examples you link to remove cookies. That's not what we're after. We're after the extraction of a specific cookie without removing anything.

It's also not marketing for a commercial product. The research is for an open source project, and the code is public and open source. The entire point of the blog post is to call for research participants who could not only test our ideas, but who could also point out anything we might have missed.

> The first example looks nothing like parsing a specific cookie. It merely sanitizes the cookie headers a little, but it doesn't extract out a specific cookie to use as cache key.

You say you don't parse a specific cookie, but doesn't extract a specific cookie as a cache key? The blog post says the opposite:

> We modified Passenger to parse cookies, and to vary turbocache responses based on the value of this user_id cookie. We invoke Passenger like this: passenger start --vary-turbocache-by-cookie user_id

In other words: parse the user_id cookie.

The mentioned commit even adds a ~250 LoC file (ext/common/ServerKit/CookieUtils.h) to do cookie parsing: https://github.com/phusion/passenger/commit/a760649cd79fde43...

---

Anyway, what you're getting at is that Phusion only parses a certain value from the cookie and then uses it as a custom Vary header, whereas the examples I linked to clean up the Cookie header and then varies on that cleaned up Cookie header. That boils down to exactly the same thing.

P.S.: downvoting? Not very nice.

I am from Phusion. No idea who downmodded you, but this happens often on HN.

But what you mentioned is not the same thing. In the examples you linked to, Google Analytics and other cookies are removed, leaving only a single cookie. But that's not what we're after. We want to vary by a specific cookie, without removing the other cookies.

For example, Rails stores the session data in a session cookie. We advocate introducing a user_id cookie in addition to the session cookie. Using your approach, the session data would be removed, which breaks the application. Our approach leaves all original cookie data intact while still varying on a specific cookie.

Furthermore, another idea that we've described in the blog post is to vary based some user property, e.g. the user's permission level, in order to increase the cardinality of cache entries. This is not something you can do with only Varnish: it requires cooperation from the app.

Yes, and we (CloudFlare) offer different caching based on cookies.

Can you link to the relevant documentation?

All I can find is in this whitepaper, and it doesn't go into detail: https://www.cloudflare.com/static/media/pdf/cloudflare-white...

Reply on news.ycombinator.com