Page MenuHomePhabricator

Warn users about CloudFlare magic (particularly, Rocket Loader) in the documentation
Closed, ResolvedPublic

Description

Problem: When using CloudFlare as a CDN for a Phabricator installation, CloudFlare magic (including the 'Rocket Loader' and auto-minifiers) can break Phabricator in minor ways.

This manifests in odd ways, and importantly it doesn't always seem to break, presumably based on the Moon Phase and I guess whatever CloudFlare and Phabricator are doing on any day. I had an install (haskell.org) where things worked OK, so I made my own. I later switched Haskell.org to a different service (with no magic) and kept on my merry way. But on my personal install things later randomly broke, and I didn't notice this (probably) for several weeks, since I mostly use Phabricator for repository hosting.

Symptoms: Bits and pieces of the UI stop working, for example, 'Description Preview' no longer works, and tapping the '+' symbol at the top of the page doesn't create a dropdown to create a task or event, but forwards to a completely new page with the options to create a task, etc (so it degrades gracefully at least).

Also, minifiers etc are useless since Phabricator does that by itself it seems.

Steps to reproduce

  1. Put CloudFlare in front of your install as described in the users guide, including for the files domain (which will be where some of the external JavaScript is served from.)
  2. Go to the CloudFlare panel, and go to the 'Speed' tab.
  3. Enable options like the Rocket loader and JavaScript minifier, and see if things break (a cache purge should cause this to occur instantly). The Rocket Loader is the primary offender IIRC.

Solution: Put a big ol'

IMPORTANT: Disable arcane CloudFlare wizardry in 3 easy steps...

in the users guide.

Can I offer a patch for this: Probably.

Caveat Emptor: I fixed this a week or two ago and forgot to report this. I'll retest it of course, but didn't want to forget.

Event Timeline

thoughtpolice claimed this task.
thoughtpolice updated the task description. (Show Details)
thoughtpolice added a project: Documentation.
thoughtpolice added a subscriber: thoughtpolice.

Someone else ran into issues with Rocket Loader too, although everything broke completely for them in Chrome (although fine in Safari).

Hitting this means you have your primary install behind CloudFlare, right? Not just the file domain? Do you have any particular reasons for doing that? I don't normally expect installs to put both domains behind CloudFlare.

This is so purely a CloudFlare problem that I hesitate to spend any time on it beyond adding a note to the documentation. If we had limitless time and resources we could:

  • Report the issues to CloudFlare and get them fixed.
  • Add data-cfasync="false" to every script tag to disable Rocket Loader.
  • Make a request to ourselves during setup and look at the response to see if Rocket Loader is enabled (see T2226) then warn users about it.
epriestley renamed this task from Warn users about CloudFlare magic in the documentation to Warn users about CloudFlare magic (particularly, Rocket Loader) in the documentation.Nov 5 2015, 2:13 PM

Someone else ran into issues with Rocket Loader too, although everything broke completely for them in Chrome (although fine in Safari).

Hitting this means you have your primary install behind CloudFlare, right? Not just the file domain? Do you have any particular reasons for doing that? I don't normally expect installs to put both domains behind CloudFlare.

Mostly because CloudFlare will easily generate SSL certificates for all of our domains, and also upgrade them appropriately, re: things like SHA-2 certificates, SSL vulnerabilities, etc. It also gives anti-DDoS, and stats, are a nice "thing to have", as the Haskell.org installation is completely public (I imagine for private installs this isn't really any kind of threat or concern at all).

Of course, putting your main domain behind CloudFlare also breaks other things, like the notification server and desktop UI. Granted, that's strictly a WebSockets problem, and CF will eventually offer WebSocket proxying to their customers (so this is more of an annoyance than a game breaker). Maybe that should be mentioned for now, too...

Also, thinking about it - CloudFlare *also* breaks particular scenarios like if you have the proxy in front of your domain, *and* it hosts your repository, the configured Phabricator URI no longer works; you can't git clone https://secure.mydomain.com/..., iff secure.mydomain.com is behind *any* proxy, not just CloudFlare - and this is exactly what Differential tries to do for Repository Automation. Shell into a machine, git clone from the original Phabricator URI, and this hangs forever (because apparently CloudFlare and other services don't like to just kill invalid connections?)

This is so purely a CloudFlare problem that I hesitate to spend any time on it beyond adding a note to the documentation. If we had limitless time and resources we could:

  • Report the issues to CloudFlare and get them fixed.
  • Add data-cfasync="false" to every script tag to disable Rocket Loader.
  • Make a request to ourselves during setup and look at the response to see if Rocket Loader is enabled (see T2226) then warn users about it.

Right, I have no intention of there being any real 'fix' beyond just "Turn off Rocket Loader" in the docs. Anything else is way too much of a moving target to make sense at all. That's why I just suggest a patch to the docs and nothing more.