Go-ipfs: bafy addresses ...

[michel47]

Version information:

go-ipfs version: 0.5.1
Repo version: 9
System version: amd64/linux
Golang version: go1.13.10

Description:

After switching to ipfs 0.5 and fixing a few API changes, I still have problem with some of multihashes due to the fact that old path http://localhost:8080/ipfs/:mhash58 get systematically redirected to http://:bafy32.ipfs.localhost:8080/

and this breaks w/ https://gateway.ipfs.io/ipfs/mAXAAMxItChgBcBEU7+JFmSW5JqeOINP+HJJInW4UG7QSDWJnLW1lYnViLndlYnAYtMYBCgIIAQ/bg-mebub.webp

The error I get is

bafyaamysfufbqalqceko7ysftes3sjvhryqnh7q4sjej23qudo2bedlcm4ww2zlcovrc453fmjybrnggaefaecab.ipfs.localhost’s server IP address could not be found.

would it be because of the length of the "bafy" multihash ?
because https://ipfs.io/ipfs/z8bvj226WBEd2XS2mnGgjd9FrrAb1mWfd is working fine
and so does : http://bafybcfhp4jczsjnze2ty4igt7yojese5nykbxna.ipfs.localhost:8080/

if I access /ipfs/mAXAAMxItChgBcBEU7+JFmSW5JqeOINP+HJJInW4UG7QSDWJnLW1lYnViLndlYnAYtMYBCgIIAQ/bg-mebub.webp
the via an old 0.4 server (like cloudflare's one) : it does works (probably because it doesn't switch to the "subdomained" address)

To Summarize

# this works :
xdg-open http://localhost:8080/ipfs/$(echo "is this working w/ IPFS 0.5 ? YES" | ipfs add -Q --hash identity)
# this doesn't :
xdg-open http://localhost:8080/ipfs/$(echo "is this working with IPFS 0.5 ? NO" | ipfs add -Q --hash identity)

Can we have a conditional redirect if bafy hash > 63char then don't redirect ?

[welcome[bot]]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[Stebalien]

Thanks for the report. This looks like a duplicate of #7318.

This will be mostly fixed by https://github.com/ipfs/go-ipfs/pull/7358 but long CIDs will still cause problems on gateways using HTTPS because the solution involves multiple subdomains.

Locally, you can use 127.0.0.1 instead of localhost to disable this or configure your node to disable this feature:

{
   ...
  "Gateway": {
    "PublicGateways": {
      "localhost": {
        "Paths": ["/ipfs", "/ipns"],
        "UseSubdomains": false
      }
    }
  }
}

[ribasushi]

@michel47 out of curiosity - what software / series of steps created these CIDs? I am specifically wondering what is out there in the wild that makes 408-byte long identity CIDs like your example of https://cid.ipfs.io/#bafyaamysfufbqalqceko7ysftes3sjvhryqnh7q4sjej23qudo2bedlcm4ww2zlcovrc453fmjybrnggaefaecab

[Stebalien]

He used ipfs add --inline --inline-length=....

[michel47]

Thanks @stebalien, I was not aware of the --inline option, and yes it is practically what I was doing as I am using a program call wrapid which create a "dag-object" wrapper to tag an immutable hash with a name (same as ipfs add -w --hash SHA1) but with a identity hashing such that the wrapper is in the URL.

what the wapid basically does is

label=label678
bafy=bafkrcfemdrgiu6s3qog46qnt4r7aifddskrxh6i
csize=$(ipfs files stat --size=1 /ipfs/$bafy)
echo "{'data':'CAE=','links':[{'Cid':{'/':'$bafy'},'Name':'$label','Size':$csize}]}" | sed -e "s/'/\"/g" | ipfs dag put -f protobuf --hash identity

note: sha1 is used as it is the smallest hash allowed thus minimizing the size of the "inline" object ...
so the length of the object is basically length(label)+36 bytes

{"data":"CAE=","links":[{"Name":"label678","Size":57,"Cid":{"/":"bafkrcfemdrgiu6s3qog46qnt4r7aifddskrxh6i"}}]}

[Stebalien]

Whatever you do, please do not use sha1. It's supported for compatibility with git but it's not secure against some forms of attacks and will likely be disabled/restricted in the future.