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
As noticed in #39, some gateways don't support requesting format=raw for URLs including a path.
Aparrently, trustless-gateway.link also doesn't support format=car for IPNS links (and according to the spec, only format=ipns-record has to be supported). For this reason, ls and info may fail for IPNS links in similar ways as outlined for #39.
It should be possible to circumvent this issue by resolving IPNS names to a CID before doing subsequent requests. However, a question remains, how to do this. IPNS names can be
true IPNS names (which can be resolved using a trustless gateway)
DNSLINK names (which can't be resolved in a trustless fashion, the resolution depends on DNS)
One option might be to issue a HEAD request to the /ipns/ API endpoint and inspect the X-Ipfs-Roots response header, which should include the CID for a given name. It's however unclear how to handle name changes and timeouts (e.g. the TTL value from the DNS entry).
As noticed in #39, some gateways don't support requesting
format=raw
for URLs including a path.Aparrently,
trustless-gateway.link
also doesn't supportformat=car
for IPNS links (and according to the spec, onlyformat=ipns-record
has to be supported). For this reason,ls
andinfo
may fail for IPNS links in similar ways as outlined for #39.E.g.:
This fails:
while the following succeeds (assuming a local kubo instance running):
The text was updated successfully, but these errors were encountered: