Live data from Hacker News

Researching a new form of HTTP caching optimization

blog.phusion.nl

31–40 of 50 posts

Re: Researching a new form of HTTP caching optimization

#31
I've left some comments on the Disqus thread on the blog, but I'll reiterate my concern about the security of the cookie being set.

The cookie being set is unsigned according to the documentation[0] on rails, so a user could modify it and send it back to get a different cached response. Say that they saw that the user level was being set in there (like in the blog post) and they change the value to the 'staff' value to get the staff cached response. Probably not a good idea!

With that said, I don't think that this technique is adequate right now when you have user access level concerns and you're relying on that piece of unsigned information to not be tampered with.

[0] http://api.rubyonrails.org/classes/ActionDispatch/Cookies.ht...

Re: Researching a new form of HTTP caching optimization

#32
post #11

Earlier quoted context omitted.

Varnish also supports custom cache keys via the VCL function `vcl_hash` as documented in https://www.varnish-software.com/static/book/VCL_functions.h... I couldn't (quickly) find documentation on how to get the value of a specific cookie, but the server could send a user ID in a header or something Varnish can easily access to be used in the above function.

You will probably have to write a VCL plugin if you want to parse the cookie, but that's not a huge hassle.

You can handle cookies in pure VCL – the code's not particularly elegant but it's manageable for light usage:

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

Re: Researching a new form of HTTP caching optimization

#34

> the Varnish HTTP cache has been used very successfully to speed up WordPress. But Varnish doesn’t help a lot with logged-in traffic > This is caching that Varnish and other “normal” HTTP caches (including CloudFlare) could not have done Varnish supports the ESI (Edge-Side Includes) standard, which allows it to cache fragments of a page, and for the cache server to build them again. It also allows you to completely…

Good to know. Using edge side includes may be easier than trying to change the app to a semi single page app. But that only solves half of the problem. The other half is varying the response based on the value of a specific cookie. I've updated the blog post with information regarding edge side include.

I understand that you want to offer something that 'beats' varnish, and it shines through in the article.

But I don't think it matters if your cache is better than every other cache. Rather, as long as you offer a convenient, easily implemented cache, built into the webserver, that's great in itself. We're using Passenger on all our production servers and are most satisfied, because of its ease of use.

Perhaps you could just write "this could be accomplished with Varnish, which has a lot of benefits for advanced cases, but we think our cache will be useful for those that prefer not to manage a separate caching tier."

Re: Researching a new form of HTTP caching optimization

#35

Earlier quoted context omitted.

Good to know. Using edge side includes may be easier than trying to change the app to a semi single page app. But that only solves half of the problem. The other half is varying the response based on the value of a specific cookie. I've updated the blog post with information regarding edge side include.

I understand that you want to offer something that 'beats' varnish, and it shines through in the article. But I don't think it matters if your cache is better than every other cache. Rather, as long as you offer a convenient, easily implemented cache, built into the webserver, that's great in itself. We're using Passenger on all our production servers and are most satisfied, because of its ease of use. Perhaps you co…

> I understand that you want to offer something that 'beats' varnish, and it shines through in the article.

I am the author of the article. No, the point is not to "beat" Varnish. It is an article describing various ideas and a call for help. See https://news.ycombinator.com/item?id=8844905

Perhaps the writing style gave a competitive impression, so I've updated the article to mention that we're not out to beat Varnish, but to research the possibilities.

Knowing that Varnish can accomplish some of the things is good, because that way we can draw from an existing pool of experience.

Re: Researching a new form of HTTP caching optimization

#36

Earlier quoted context omitted.

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

Re: Researching a new form of HTTP caching optimization

#37

Sorry to barge on this thread - but does have a reasonable varnish config that works for a wordpress site behind https nginx and W3 Total Cache ? It seems strangely hard to configure something like this.

I used (and modified) one based on Dreamhost's https://github.com/dreamhost/varnish-vcl-collection/blob/mas... but there's a bunch of others on Github if you search for them. Note that this isn't a shortcut so you don't have to learn VCL... and that the way I did it was to put Varnish on port 80 and the web server on another port. I've seen other configs where a load balancer asks Varnish when it knows varnish should have the answer and otherwise sends traffic directly to the web server. And sometimes your config will vary based on asset type or domain name -- e.g. static.example.org assets might be cacheable forever while your site's pages might only require a 2 minute cache. You can invalidate cached-forever pages with commands for Varnish or by varying the URL using a "cache buster" hash or string in the asset filename. Oh and don't forget to set the storage type Varnish uses to malloc instead of file.

Re: Researching a new form of HTTP caching optimization

#38

I almost always configure Varnish not to cache on Vary Cookie and pair that with some simple changes on the back-end to keep most my pages cacheable. One, don't blindly set Vary Cookie on every single page. Two, when a page only needs minor variation like a username; store the username in a cookie and use JavaScript to display it on the page.

Yeah, the biggest advantage ESI offers is not requiring JS. If that's important to you, configure it and do extra rendering on the server-side. If not... :)

Re: Researching a new form of HTTP caching optimization

#39
post #32
post #11

Earlier quoted context omitted.

You will probably have to write a VCL plugin if you want to parse the cookie, but that's not a huge hassle.

You can handle cookies in pure VCL – the code's not particularly elegant but it's manageable for light usage: https://www.varnish-cache.org/trac/wiki/VCLExampleRemovingSo...

I'm not sure whether I would call "munging the cookie header with regexps" "cookie handling" ;).

Re: Researching a new form of HTTP caching optimization

#40
post #39
post #32

Earlier quoted context omitted.

You can handle cookies in pure VCL – the code's not particularly elegant but it's manageable for light usage: https://www.varnish-cache.org/trac/wiki/VCLExampleRemovingSo...

I'm not sure whether I would call "munging the cookie header with regexps" "cookie handling" ;).

Agreed – it's possible and for simple tasks such as stripping an analytics cookie it's workable but for anything more serious you'd want something like https://github.com/lkarsten/libvmod-cookie
Post reply on HN