Hacker News Reader

Comment by igrigorik | Hacker News Reader

Do you rewrite the hosts on all third party sites to be the site domain? I'm still not following this setup.

Silk is an entirely different setup. Silk (a) manually sets their SPDY gateway as a browser proxy, which is a system level setting, and (b) silk does not tunnel HTTPS requests. CloudFlare obviously doesn't have control over my browsers proxy settings, so if the page I'm loading is abc.com/page, and that page has a request to twitter.com/widget.js, then the browser should open a connection directly to twitter.com to fetch that resource.

P.S. SPDY does allow tunneling HTTPS, but once again, that requires a system level proxy setup.

View on HN

To use cloudflare's "rocket loader", the host domain dns record must point to cloudflare instead of the origin server. If abc.com were using cloudflare, a user's request to abc.com/page would first hit cloudflare's server. Cloudflare would then proxy the request to abc's origin server, rewrite 3rd party urls, and return the modified content to the user.

I'm not sure how well cloudflare handles http vary headers, e.g. 3rd party resources that serve different content depending on cookies or user agent. An example could be google web fonts which serves different css and fonts to different browsers.

Looking through CF's own site, plus a few of their "case study" links, I don't see the domain rewriting happening on these scripts. And as you indicated, with additional complication of user cookies / HTTP vary, I'm not sure that's necessarily a good idea either -- if either of those in place, all of your cache optimizations go out the door. Best gotcha example: ads.

Seems like there is a bit of false advertising going on here.

I haven't seen explicit documentation about the rewriting behavior, but I assumed they were rewriting on based on the before and after waterfall charts in this blog post[1]. I agree it's not a great idea. Cloudflare actually recommends blacklisting problematic scripts [2], which partially defeats the feature's usefulness.

  [1] http://blog.cloudflare.com/56590463
  [2] http://www.cloudflare.com/wiki/Rocket_Loader

That doesn't seem like a big deal. If you have requirements that every request hit your server then, duh, you can't have a caching proxy in front of your pages.

I think very few ads work that way, though. It's almost always a javascript include (often from a 3rd party ad server).

I'm saying the oppposite. I have no reason to proxy twitter.js or other ads scripts on my site. If CF is taking the step to rewrite those to the same domain, then they also have to guard for respecting all the cache implications of that.

Reply on news.ycombinator.com