[WimLeers]

> 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.

[FooBarWidget]

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.