bug in pathing redirection

[jbenet]

ipfs://ipfs/QmQKRDh2hB2nrP3LpwFMyj8zgi5pjDEQXcEzRLJYVZ45bk/erebor.jpg

goes to

http://127.0.0.1:8080/ipfs/ipfs/QmQKRDh2hB2nrP3LpwFMyj8zgi5pjDEQXcEzRLJYVZ45bk/erebor.jpg

it should go to

http://127.0.0.1:8080/ipfs/QmQKRDh2hB2nrP3LpwFMyj8zgi5pjDEQXcEzRLJYVZ45bk/erebor.jpg

[lidel]

IIRC current implementation is:

• fs: – assume full IPFS address (with explicit /pns/ or /ipfs prefix)
• ipfs: – assume IPFS resource (implicitly add /ipfs prefix)
• ipns: – assume IPNS resource (implicitly add /ipns prefix)

This raises questions:

• Should we change this behaviour and always assume full path is provided?
• Or should we just detect duplicate /ipfs/ and remove it silently?
• Potential problem:
  What about ipns://ipfs/QmQKRDh2hB2nrP3LpwFMyj8zgi5pjDEQXcEzRLJYVZ45bk/erebor.jpg ?
  What should happen then?

[Kubuxu]

We should accept as many formats and show only one. This way if user makes mistake while inputting he gets redirected to a correct one and when he wants to share (copy&paste) he shares the correct one.

Fixing ipns://ipfs/QmQKRDh2hB2nrP3LpwFMyj8zgi5pjDEQXcEzRLJYVZ45bk/erebor.jpg to canonical /ipfs/QmQKRDh2hB2nrP3LpwFMyj8zgi5pjDEQXcEzRLJYVZ45bk/erebor.jpg (which will be shown in browser probably with fs:/ prefix) makes sense from usability perspective.

[lidel]

Yeah, it should follow robustness principle and be liberal in what addon accepts for each protocol handler.

Marking as a bug to be fixed in next release.

[lidel]

Fix will be available in v1.4.2:

• if protocol prefix is present in path, leave it as-is
• if protocol prefix is missing, add default one from handler template