Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recover from dead Public Gateways #640

Closed
lidel opened this issue Dec 15, 2018 · 0 comments · Fixed by #783 or #797
Closed

Recover from dead Public Gateways #640

lidel opened this issue Dec 15, 2018 · 0 comments · Fixed by #783 or #797
Labels
good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature status/ready Ready to be worked

Comments

@lidel
Copy link
Member

lidel commented Dec 15, 2018

Extracted from #639

By default Companion will redirect IPFS paths to local gateway, so even if remote HTTP server is down, content will load just fine over IPFS.

What if user does not have locally running IPFS node tho?

We are able to detect HTTP errors in WebExtensions/API/webRequest/onErrorOccurred:

Fired when a request could not be processed due to an error: for example, a lack of Internet connectivity.

The error is passed to the listener as the error property of the details object.

Note that this event is not fired for HTTP errors (4XX or 5XX responses): these will go through the normal stages of a request, calling any event listeners, and setting details.statusCode to report the error.

A rough idea would be to do what we already do for websites with DNSLink:

  • detect the tab failed to load IPFS-like path
  • open failed path at a public gateway in a new tab

Caveats:

  • we are unable to do a HTTP redirect from onErrorOccurred so we recover in a new tab, which means this will only work for the main request (URL in location bar), won't fix images embedded from a gateway that went offline.

Prior art:

@lidel lidel added kind/enhancement A net-new feature or improvement to an existing feature help wanted Seeking public contribution on this issue good first issue Good issue for new contributors labels Dec 15, 2018
@lidel lidel added the status/ready Ready to be worked label Dec 25, 2018
lidel pushed a commit that referenced this issue Oct 17, 2019
This closes #640, enabling dead public gateways to be redirected
to the default public gateway.  This includes DNSLink websites that went offline.

Added as an experimental option enabled by default.
lidel added a commit that referenced this issue Oct 17, 2019
This change builds on top of #783 and:

-  adds support for recovery from DNS lookup failures
-  enables recovery for all HTTP Codes >= 400 
-  recovers `.eth` DNS failures bu reopening website on EthDNS gateway at `.eth.link`
-  simplifies some code paths and adds more tests

Motivation:

When a third-party IPFS gateway is discontinued or censored at DNS level, the IPFS Companion should retry request using currently active gateway set by the user (public or local).

We also want to recover in situation when website with DNSLink has a valid DNS `TXT` record, but HTTP behind `A` record is down or unreachable.

*Note*: right now the only real use for DNS recovery is support of .eth TLD via .eth.link gateway, however in the future this could provide means of working around DNS-based censorship (eg. by executing DNSLink lookups over libp2p as a fallback).

closes #678, closes #640
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature status/ready Ready to be worked
Projects
None yet
1 participant