[feature request] Transparent DNSLINK

[mkg20001]

It would be useful if there would be a "transparent DNSLINK" mode that would serve from the local node gateway without redirecting to localhost.

[lidel]

@mkg20001 do you mean the situation we have on ipfs.io where there is a public gateway AND dnslink on the same hostname? If that is what you had in mind, check #518 which should make it possible.

If it is something else, could you elaborate on it bit more, give a real life example etc please?

[mkg20001]

What I mean is for example a user accesses https://somesite.com which has a DNSLINK.
Usually the user would get redirected to http://<local-gateway>/ipns/somesite.com

Would it be possible to make it so the addon intercepts the request, does not redirect it but simply overrides the response with the one for the url the user would get redirected to? (Basically so https://somesite.com is shown in the URL bar, yet the requests get sent to http://<local-gateway>)

[lidel]

Sadly no, not with current APIs. It is not possible to inject payload into live HTTP sessions. We can either redirect or cancel HTTP requests.

What you are proposing is basically a duplicate of #164 where we track efforts to get ipfs:// be a native handler, not just a redirect to http://
Having that at some point in the future, opening http://foo.bar would detect dnslink and redirect to ip(f|n)s://foo.bar (without mutating paths)

(Feel free to reopen if I misunderstood the case tho)

[mkg20001]

(without mutating paths)

If this means URL bar stays unchanged, yet it loads from local gateway then I think this can be closed.

[ivan386]

You can set local gateway as proxy for URL?

[lidel]

Key limitation is that browser extension can't act as a Proxy because it can't spoof payloads of HTTP responses (at this time). When it comes to HTTP it can only redirect to a different URL, so an external app needs to act as a proxy.
There may be a custom protocol handler API added to browsers in future, but that won't be http:// in the location bar anymore.

Digression:
If we re-frame this feature as "make go-ipfs' HTTP gateway act as a regular HTTP proxy" and even if go-ipfs could pretend to be a real HTTP Proxy, this abstraction breaks on sites with TLS, especially ones with HSTS.

I think the way dnslink will work in future in browser extension will be an honest redirect from https://foo.bar to ipfs://foo.bar