Broken dweb.link page with EOF tries to open after toggling to install IPFS Companion in French

[stephendonner]

Description

Broken dweb.link page with EOF tries to open after toggling to install IPFS Companion in French

Steps to Reproduce

1. set OS region and language to France and French, respectively
2. new profile
3. launch Brave
4. open brave://settings/ipfs and toggle IPFS Companion to on/enabled
5. wait

Actual result:

https://dweb.link/ipfs/bafkqaaa/ opens in a new tab, with cannot detect content-type: EOF

Expected result:

Should install IPFS Companion successfully, with this page: ipfs://bafkqaaa/ in a new tab

Reproduces how often:

100%-ish

Brave version (brave://version info)

Brave	1.28.34 Chromium: 91.0.4472.124 (Build officiel) nightly (x86_64)
Révision	7345a6d1bfcaff81162a957e9b7d52649fe2ac38-refs/branch-heads/4472_114@{#6}
Système d'exploitation	macOS Version 11.4 (assemblage 20F71)

[stephendonner]

Found while testing #15586

[lidel]

Seems that dweb.link got updated to go-ipfs 0.9 and there is something different about handling of CIDs with identity multihash (like bafkqaaa), will look into this ASAP.

[lidel]

• There is a regression in mimetype sniffing library used by go-ipfs gateway, it changed the behavior when an empty byte array is processed. Unfortunately, that is exactly what bafkqaaa returns.
  • Upstream issue: CID bafkqaaa causes error: cannot detect content-type: EOF ipfs/kubo#8230
  • Quick fix is to replace bafkqaaa with something that returns unambiguous plain text. Submitted Companion with a fix (fix: onboarding flow in Brave ipfs/ipfs-companion#1011) to Chrome Web Store will post update when it gets approved.
  • There will be a patch go-ipfs release (0.9.1) that restores old behavior for bafkqaaa, but the bug from this issue will be fixed as soon Companion v2.19.1 ships.

[lidel]

@stephendonner Companion v2.19.1 just got approved, it includes a fix that should solve this without waiting for go-ipfs.
Mind re-testing and confirming the issue is gone?

[stephendonner]

@stephendonner Companion v2.19.1 just got approved, it includes a fix that should solve this without waiting for go-ipfs.
Mind re-testing and confirming the issue is gone?

Looks good using https://github.com/ipfs/ipfs-companion/releases/tag/v2.19.1 with

Brave	1.28.37 Chromium: 91.0.4472.124 (Official Build) nightly (x86_64)
Revision	7345a6d1bfcaff81162a957e9b7d52649fe2ac38-refs/branch-heads/4472_114@{#6}
OS	macOS Version 11.4 (Build 20F71)

example	example	example

[lidel]

Awesome!
I believe we can close this as solved: Companion will no longer use the problematic CID, so we don't need to wait for upstream fix.