You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 8, 2023. It is now read-only.
As transition solution for sites switching from normal HTTP to IPFS and not wanting to stay under own domain it would be great to have IP/HTTP endpoint that returns 301 Moved Permanently to correct ipfs.io/ipns/....
Example of operation:
GET /blog/index.html HTTP/1.1
Host: www.example.org
HTTP/1.1 301 Moved Permanently
Location: https://ipfs.io/ipns/www.example.org/blog/index.html
It is nice as browser plug-in then can redirect that to local gateway.
Problem with it is that it requires additional IPv4 address but as it is used only very rarely performance nor latency isn't an issue. It would require only one or two additional address (two just for fallback if one goes down for maintenance).
It would also allow sites to migrate to IPFS and tools do not have to know about it. Current strategy is setting A records but this can be problematic (infrastructure changes, endpoint version changes).
The text was updated successfully, but these errors were encountered:
Kubuxu
changed the title
Redirect endpoint
Redirect endpoint as transition strategy
Jan 14, 2016
I think that what you described here is already possible via dnslink and gateway API.
Browser plugins can query DNS API (provided by go-ipfs) and redirect to IPFS if a site has dnslink record present.
See ipfs/ipfs-companion#44 if you are interested in details / progress of Firefox implementation.
As transition solution for sites switching from normal HTTP to IPFS and not wanting to stay under own domain it would be great to have IP/HTTP endpoint that returns
301 Moved Permanently
to correctipfs.io/ipns/...
.Example of operation:
It is nice as browser plug-in then can redirect that to local gateway.
Problem with it is that it requires additional IPv4 address but as it is used only very rarely performance nor latency isn't an issue. It would require only one or two additional address (two just for fallback if one goes down for maintenance).
It would also allow sites to migrate to IPFS and tools do not have to know about it. Current strategy is setting A records but this can be problematic (infrastructure changes, endpoint version changes).
The text was updated successfully, but these errors were encountered: