Disable redirect on X-Ipfs-Path without DNSLink on the root document

[lidel]

https://fleek.co is an example of interesting misconfiguration (at least today 2022-02-17):

• fleek.co has no DNSLink
• HTTP response includes x-ipfs-path to immutable snapshot

$ ipfs resolve -r /ipns/fleek.co
Error: could not resolve name: "fleek.co" is missing a DNSLink record (https://docs.ipfs.io/concepts/dnslink/)

$ curl -Is https://fleek.co/ | grep x-ipfs-path 
x-ipfs-path: /ipfs/bafybeidwgtlx54aifd5ynwwvlozr2fuw5xrmbu3ivnwmnoxi4ewdnxty5y/

Problem

Companion will use x-ipfs-path as fallback:

ipfs-companion/add-on/src/lib/ipfs-request.js

Lines 310 to 312 in eacee6c

	// Detect X-Ipfs-Path Header and upgrade transport to IPFS:
	// 1. Check if DNSLink exists and redirect to it.
	// 2. If there is no DNSLink, validate path from the header and redirect

This means opening https://fleek.co with ipfs-companion will redirect user to http://bafybeidwgtlx54aifd5ynwwvlozr2fuw5xrmbu3ivnwmnoxi4ewdnxty5y.ipfs.localhost:8080

Solution

• We should modify the redirect logic, so it does not redirect the root document in presence of immutable x-ipfs-path, as that makes it hard for user to bookmark, access the latest version in the future, and could introduce regressions (only websites with valid DNSLink should be redirected).
• My suggestion is to consider redirecting the root document (one from address bar) if resource URL is following Gateway conventions described in https://docs.ipfs.tech/how-to/address-ipfs-on-web/ – this way misconfigured websites won't get mangled.
• Update: for proper detection heuristics see diagram introduced in feat: add /how-to/detect-ipfs-on-web ipfs-docs#1295. The caveat here is to disable automatic redirect of top-level document if the URL is not a public gateway URL, the response has x-ipfs-path, but the domain has no DNSLink set up.

[lidel]

I may look into this as an excuse to fix MV2 build.
cc @meandavejustice – just FYI in case this edge case comes up in MV3 work