Describe the bug
Multiple issues across the JS ecosystem when new protocols are added.
|
export const names: Record<string, Protocol> = {} |
|
export const codes: Record<number, Protocol> = {} |
|
|
|
export const table: Array<[number, number, string, boolean?, boolean?]> = [ |
|
[4, 32, 'ip4'], |
|
[6, 16, 'tcp'], |
|
[33, 16, 'dccp'], |
|
[41, 128, 'ip6'], |
|
[42, V, 'ip6zone'], |
|
[43, 8, 'ipcidr'], |
|
[53, V, 'dns', true], |
|
[54, V, 'dns4', true], |
|
[55, V, 'dns6', true], |
|
[56, V, 'dnsaddr', true], |
|
[132, 16, 'sctp'], |
|
[273, 16, 'udp'], |
|
[275, 0, 'p2p-webrtc-star'], |
|
[276, 0, 'p2p-webrtc-direct'], |
|
[277, 0, 'p2p-stardust'], |
|
[280, 0, 'webrtc'], |
|
[290, 0, 'p2p-circuit'], |
|
[301, 0, 'udt'], |
|
[302, 0, 'utp'], |
|
[400, V, 'unix', false, true], |
|
// `ipfs` is added before `p2p` for legacy support. |
|
// All text representations will default to `p2p`, but `ipfs` will |
|
// still be supported |
|
[421, V, 'ipfs'], |
|
// `p2p` is the preferred name for 421, and is now the default |
|
[421, V, 'p2p'], |
|
[443, 0, 'https'], |
|
[444, 96, 'onion'], |
|
[445, 296, 'onion3'], |
|
[446, V, 'garlic64'], |
|
[448, 0, 'tls'], |
|
[460, 0, 'quic'], |
|
[461, 0, 'quic-v1'], |
|
[465, 0, 'webtransport'], |
|
[466, V, 'certhash'], |
|
[477, 0, 'ws'], |
|
[478, 0, 'wss'], |
|
[479, 0, 'p2p-websocket-star'], |
|
[480, 0, 'http'], |
|
[777, V, 'memory'] |
|
] |
|
|
|
// populate tables |
|
table.forEach(row => { |
|
const proto = createProtocol(...row) |
|
codes[proto.code] = proto |
|
names[proto.name] = proto |
|
}) |
To Reproduce
Steps to reproduce the behavior:
- pull down repo ipfs/ipfs-webui
git checkout ea89e7f
rm patches/multiaddr+8.1.2.patch
npm install
- start
ipfs daemon using kubo 0.18.1 or later in another terminal
- Note the port number in the line
API server listening on /ip4/127.0.0.1/tcp/<kuboPort>
- run
KUBO_PORT_2033_TEST=<kuboPort> npm run test:unit -- src/bundles/identity.test.js
- Note the error "no protocol with name: quic-v1"
Expected behavior
Looking up unknown protocols does not propagate errors, nor cause requests to fail. We should fallback to supported/known protocols
Additional context
Potential Solutions
- Pull out protocols-table.js into it's own package. Keep it at
v1.0.x, there are NO breaking changes, only protocols added. Any JS package stays up to date by depending directly on the table
- Stop throwing errors from
|
export function getProtocol (proto: number | string): Protocol { |
|
if (typeof proto === 'number') { |
|
if (codes[proto] != null) { |
|
return codes[proto] |
|
} |
|
|
|
throw new Error(`no protocol with code: ${proto}`) |
|
} else if (typeof proto === 'string') { |
|
if (names[proto] != null) { |
|
return names[proto] |
|
} |
|
|
|
throw new Error(`no protocol with name: ${proto}`) |
|
} |
|
|
|
throw new Error(`invalid protocol id type: ${typeof proto}`) |
|
} |
, because different packages in the ecosystem are not handling this properly.
- backport any protocol-table changes for all multiaddr versions (No one wants to do this)
Describe the bug
Multiple issues across the JS ecosystem when new protocols are added.
js-multiaddr/src/protocols-table.ts
Lines 4 to 55 in 6cfb7ad
To Reproduce
Steps to reproduce the behavior:
git checkout ea89e7frm patches/multiaddr+8.1.2.patchnpm installipfs daemonusing kubo 0.18.1 or later in another terminalAPI server listening on /ip4/127.0.0.1/tcp/<kuboPort>KUBO_PORT_2033_TEST=<kuboPort> npm run test:unit -- src/bundles/identity.test.jsExpected behavior
Looking up unknown protocols does not propagate errors, nor cause requests to fail. We should fallback to supported/known protocols
Additional context
Potential Solutions
v1.0.x, there are NO breaking changes, only protocols added. Any JS package stays up to date by depending directly on the tablejs-multiaddr/src/protocols-table.ts
Lines 79 to 95 in 6cfb7ad