Since the browser application cache appears not to support URL path
routes in a non-buggy way (see
https://github.com/meteor/meteor/pull/2926), applications using the
appcache package will want to use hash fragment routes instead.
This PR adds support to the spiderable package for hash fragment
routes. An original URL such as `http://example.com/#!a=1&b=2` will
be encoded by a search engine as an escaped fragment, decoded by the
spiderable package, passed through to the phantomjs process, and
appear to the phantom client as `#!a=1&b=2` in `window.location.hash`
(the same as when the original URL is opened in a regular browser).
Other approaches seemed to be heuristics that broke down in edge cases:
a timeout wasn't guaranteed if your JS was slow; page.load in PhantomJS
wasn't firing reliably because of long polling.
Until I made this I always got only ```<head/>``` with it's content, ```<body>``` was empty.
It seems setInterval script was finished earlier then url content was loaded to the page. Maybe because I have subscriptions with response time lower then 100ms so they were ready very quickly — database server in the same data center.
http://phantomjs.org/api/webpage/method/open.html
