Test if local Gateway port is a real Gateway

[tennox]

tl;dr

• ipfs-companion should not only check if RPC API port provides /api/v0, but also do similar test on the local Gateway port.
• we could reuse gateway test from ipfs-webui (ask gateway for known, inlined CID for quick response) and disable IPFS integrations like redirects when local gateway is not present

---

Original report:

Describe the bug I was debugging an (alleged, not reproducible) vuepress bug for some hours, which resulted in the realisation that the bug would only appear while the IPFS companion addon was enabled in my browser. :sweat_smile:

To Reproduce I'm really not sure how to properly reproduce this behaviour :disappointed: - but maybe...

1. git clone https://github.com/tennox/vuepress-root-bug-repro demo && cd demo && yarn
2. yarn start
3. Open http://localhost:8080 in a browser with this addon installed
4. See empty page
5. Check devtools network tab, see failing requests:
6. copy the cURL for that request, execute it and see it works without problems || 404: curl 'http://localhost:8080/@vite/client' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0' -H 'Accept: */*' -H 'Accept-Language: en-GB,en;q=0.7,de;q=0.3' -H 'Accept-Encoding: gzip, deflate' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: http://localhost:8080/' -H 'Sec-Fetch-Dest: script' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: same-origin' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache'

Expected behavior Not altering localhost:8080 traffic

Desktop (please complete the following information):

• OS: elementary OS 5.1.7 Hera
• Browser: Firefox developer 97.0b4 (64-bit)
• Companion Version: 2.19.1

[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 seven 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.

[lidel]

@tennox Your vue local dev server runs on the port which is the default Gateway port in ipfs-companion.

You need to either change the port used by vue, or your IPFS node.

If you change vue port, the problem will go away.

If you change the Gateway port in your IPFS node, you also need to change RPC port in Companion settings:

[tennox]

Thanks for the attempt to explain me how to fix it.

However, I know that this is the case, and I'm well aware how to fix work around the issue - but I don't agree that this is not an issue, as it took me many hours to find out what is happening. Using port 8080 is quite a common thing, and I would argue that very few people would expect the addon to interfere in such a subtle way (either don't modify or block or at least some warning in the console that the addon is interfering with the traffic would be 'solutions' for this issue)

In any case, I don't expect this to be fixed for free, but I feel misunderstood.

[lidel]

Thank you for the feedback. You are right, I misunderstood your ask here.

Agree we could improve devexp. At the very minimum, Companion could detect that local Gateway port is occupied by something other than IPFS Gateway and disable redirects when that is the case + display warning to user via browser action menu. We already do similar detection in ipfs-webui to determine if gateway links should use a local path/subdomain gateway or a public one.

Updated title and description.