IPFS Companion going on local gateway, but with wrong schema when in video

[simonfoilen]

Browser Setup

• OS: Linux Ubuntu 20.04.1 LTS
• Browser: Chrome Version 87.0.4280.88 (Official Build) (64-bit)
• IPFS Companion Version: 2.16.0
• IPFS Companion has been reset to default preferences

What is working (direct link to the video)

Steps:

• Going on https://www.foilen.com/handbrake-installer-sur-windows
• Clicking on "Téléchargez la vidéo" (below the video)
  • It requests https://cdn.foilen.com/foilen/HandBrake%20-%20Installer%20sur%20Windows.mp4 and gets https://tor.cdn.foilen.com/foilen/HandBrake - Installer sur Windows.mp4
  • It requests https://tor.cdn.foilen.com/foilen/HandBrake%20-%20Installer%20sur%20Windows.mp4 and gets http://localhost:8080/ipfs/QmdQUxS4Q4UEMWR3KCGv3PtcnAu8MJGSSwbhw6LuwwPgUv/foilen/HandBrake%20-%20Installer%20sur%20Windows.mp4
  • It requests http://localhost:8080/ipfs/QmdQUxS4Q4UEMWR3KCGv3PtcnAu8MJGSSwbhw6LuwwPgUv/foilen/HandBrake%20-%20Installer%20sur%20Windows.mp4 and gets http://bafybeig73kmxcne2tcuqgbzvzrgefjqynmvhocuuvan6bpm6n7dmeosu34.ipfs.localhost:8080/foilen/HandBrake%20-%20Installer%20sur%20Windows.mp4
  • [OK] It requests http://bafybeig73kmxcne2tcuqgbzvzrgefjqynmvhocuuvan6bpm6n7dmeosu34.ipfs.localhost:8080/foilen/HandBrake%20-%20Installer%20sur%20Windows.mp4 and gets the data

What is not working (when in a video tag)

Steps:

• Going on https://www.foilen.com/handbrake-installer-sur-windows
• Clicking on the play button in the top-left corner of the video
  • It requests https://cdn.foilen.com/foilen/HandBrake%20-%20Installer%20sur%20Windows.mp4 and gets https://tor.cdn.foilen.com/foilen/HandBrake - Installer sur Windows.mp4
  • It requests https://tor.cdn.foilen.com/foilen/HandBrake%20-%20Installer%20sur%20Windows.mp4 and gets http://127.0.0.1:8080/ipfs/QmdQUxS4Q4UEMWR3KCGv3PtcnAu8MJGSSwbhw6LuwwPgUv/foilen/HandBrake%20-%20Installer%20sur%20Windows.mp4
  • [WRONG SCHEMA AND NOT GETING THE DATA] It requests https://127.0.0.1:8080/ipfs/QmdQUxS4Q4UEMWR3KCGv3PtcnAu8MJGSSwbhw6LuwwPgUv/foilen/HandBrake%20-%20Installer%20sur%20Windows.mp4

What is strange is that on the second call, it gets the right url to use, but on the third one, it decided to modify the url to HTTPS instead of keeping the HTTP.

thanks

[jessicaschilling]

@lidel Is this something you might be able to investigate when you're back? Thank you!

[lidel]

Thank you for detailed bug report @provirus 👍

I was able to reproduce the bug and confirm it is limited to Chromium-based browsers.
The problem happens when x-ipfs-path header triggers redirect of a video src in Chromium.

Firefox 84.0.2 💚

Chromium 88.0.4315.5 💔

Further look into Chromium behavior revealed that our extension correctly redirects to http://, however Chromium seems to ignore scheme change for subresource and makes the final request with https://

---

Initial thoughts

• My intuition is that there is a bug in redirects made from blocking webRequest.onHeadersReceived API in Chromium.
  • Bad news: it is very unlikely that Google will fix it, because they want to remove this API anyway: What to do about Manifest V3 #666
  • There is a chance we might be able to fix this as a side effect of our collab with Igalia on unifying localhost behavior as trusted/secure context, but that would be incidental and has low probability.
• Realistically, we may need to disable x-ipfs-path-based subresource redirect in webRequest.onHeadersReceived in Chromium, unless a creative hack can be found to salvage this type of requests.

Workaround

@provirus let us know if any of below is feasible.

For users

If you want a quick fix as a Companion user, either toggle IPFS for this specific website via main menu:

or go to Companion Preferences and disable header detection globally:

For website admin

If you are the owner of https://cdn.foilen.com:

• consider removing x-ipfs-path for now, to fix the immediate problem for all Companion users
• add DNSLink for fra.cdn.foilen.com (it is missing for fra subdomain, only cdn.foilen.com has valid one)

[simonfoilen]

Hi,
thanks for testing it.

If you want a quick fix as a Companion user, either toggle IPFS for this specific website via main menu

That is what I did in the meantime.

I reenabled it for fun and actually, it is now working correctly. I am checking the versions:

• Browser: Chrome Version 87.0.4280.141 (Official Build) (64-bit)
• IPFS Companion Version: 2.17.1

So, both versions changed and now all is good. I must be lucky :)

add DNSLink for fra.cdn.foilen.com (it is missing for fra subdomain, only cdn.foilen.com has valid one)

Actually, I didn't put one since all of them are all serving /ipns/cdn.foilen.com . There is no need for regional difference when on IPFS.

---

Thinking about it, maybe the fix is because now it can use the DNSLink for cdn.foilen.com instead of waiting for the X-Ipfs-Path since cdn.foilen.com is not returning any X-Ipfs-Path (the regional ones are returning X-Ipfs-Path) , but the url that it downloads is http://127.0.0.1:8080/ipns/cdn.foilen.com/foilen/HandBrake%20-%20Transcoder%20une%20video.mp4 (so the one with the cdn.foilen.com domain)
I am talking about the root cause of that other issue about resolving DNSLink: #953

thanks again

[lidel]

add DNSLink for fra.cdn.foilen.com (it is missing for fra subdomain, only cdn.foilen.com has valid one)

Actually, I didn't put one since all of them are all serving /ipns/cdn.foilen.com . There is no need for regional difference when on IPFS.

If you expose x-ipfs-path header, a DNSLink should also be there. It would not hurt :)
FYSA DNSLink-based redirects happen before header-based redirects, so this issue would probably not happen in the first place.

Anyway, glad this helped.

[simonfoilen]

added it to my regional host names as well then. That could also be good if someone bookmarked the redirection.
Thanks for the suggestion :)