Reconcile IPFS absolute addresses with standard URL resolution

[flyingzumwalt]

Background

@Gozala (2017-02-01)

In cases of directories ipfs node generates links that are somewhat incompatible with ipns://${cid_v1_base16} approach in that they point to /ipns/${cid_v0_base58}/path/with-in that according to standard URL resolution rules would resolve to ipns://ipns/${cid_v0_base58}/path/with-in while ipns / ipfs protocol handlers could define alternative resolution algorithm to handle that properly, I would instead recommend changing links generated by ipfs node to be relative instead, reason is most other software (including js libs that maybe used on page) would resolve it according to standard rules and there for get different results.

@jbenet (2017-02-05)

• The directory auto-generated URLs should definitely be relative. I don't recall why they're not, hopefully it's just a mistake to fix. (cc @lgierth -- any idea?)
• That said, the redirection of {ipns | ipfs } ipld}://{ipfs | ipfs | ipld}/${rest} -> {ipns | ipfs | ipld}://${rest} should be there, because it probably will happen in other cases.
  This is a well established pattern due to:
  • how our http-to-ipfs gateway works
  • how filesystems work
  • assumptions data have at a very low level -- that ipfs, ipns, and ipld are always accessible at an absolute path.
  • this is required to accomplish important low-level things / expectations in content that does not care about the web specifically (meaning it's meant to work in both web, fs, all the blockchains, git, ipfs, and other contexts).
  • i understand that's not how the web has worked so far. that's ok, we can work around it by adding this redirect.

@Gozala (2017-02-06)

It’s just http server redirects a non / ended paths, which is totally fine. The problem is that for protocol that proxies to the http server will follow that redirect and there for end-up serving from localhost. After thinking more about it, I think that should not be too hard to handle by looking at the http headers before serving response and if it’s redirect do a resolution in protocol handler. Although again it would be nicer to have a more direct way to talk to ipfs node to do path resolutions.

[flyingzumwalt]

@lgierth please help us understand how this relates to #8

[ghost]

Closing this, it's been concluded in ipfs/specs#152 (comment)