greatfire/redirect-when-blocked

Redirect your users to another URL if they can't reach your website

redirect-when-blocked's Issues

不加载网站本身，直接重定向到被选网站

您好，用deomo程序做了一个测试网站，在域名没有封锁的情况下，不加载网站本身内容，而是直接重定向到备用网站

请看上图，几秒后就会重定向了
对了，是php完全版的

Don't really know how to use it.

Don't know how to implement this, can you guys provide a more specific guide, thanks!

Is the script still functional?

Hi team,

I am greatly inspired by this project. Just wanted to know if this script is still functional?

ServiceWorker?

Does ServiceWorker buy us anything over AppCache?

Just came across http://jakearchibald.com/2014/offline-cookbook/ which says:

When AppCache arrived on the scene it gave us a couple of patterns to make content work offline. If those were the patterns you needed, congratulations, you won the AppCache lottery (the jackpot remains unclaimed), but the rest of us were left huddled in a corner rocking back & forth.

With ServiceWorker (intro) we gave up trying to solve offline, and gave developers the moving parts to go solve it themselves. It gives you control over caching and how requests are handled. That means you get to create your own patterns. Let's take a look at a few possible patterns in isolation, but in practice you'll likely use many of them in tandem depending on URL & context.

All code examples work today in Chrome 40 beta with the cache polyfill, unless otherwise noted. This stuff will land into the stable version January/February 2015 barring any emergencies, so it won't be long until millions of real users can benefit from this stuff.

For a working demo of some of these patterns, see Trained-to-thrill, and this video showing the performance impact.

(cookbook contents follow)

If so, I guess we can keep an eye on https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker_API#Browser_support for support in other browsers.

The redirection is very slow

Since we are not caching the website itself, we have to rely on the application cache "fallback" event. If the user has no Internet connection at all, this even is triggered immediately. In the case of DNS poisoning pointing the hostname at a non-responsive IP address, browsers apparently wait for a connection timeout before triggering the fallback event. The connection timeout seems to vary depending on the browser, OS and perhaps other variables such as the network connection itself. Sometimes it seems to be very fast, sometimes it takes more than a minute.

We need to research how browsers handle this and look for a solution.

cache problem

The .appcache file is served with a "Cache-Control: max-age=0" header so that browsers will always check whether there's a newer version. The .appcache file contains an md5 hash in a comment which is generated based on the file contents in the RWB directory. The effect should be that whenever RWB code or data changes, browsers update their app cache. However, there's a problem. The cached page is itself cached by the CDN. This means that in some instances the browser will reload the application cache but will replace it with a cached version (at the CDN level) of the older page. When the CDN version is replaced, the application cache no longer will refresh it.

Thinking about solutions..

Don't redirect if the whole internet connection is offline

If the site can't be reached, but that's because everything is unavailable (for instance because the client isn't connected to the internet), then you don't need to redirect.

You can check for navigator.onLine to see what the browser thinks, and maybe try loading a couple scripts to non-controversial domains to see if they load. One example might be
http://int.dpool.sina.com.cn/iplookup/iplookup.php?format=js

Support multiple redirection URLs

It should be possible to configure multiple redirection URLs. The site should redirect to the first among these that works.

1