Force HTTPS for path-based requests to dweb.link

[Marcin Rataj]

Background

I believe that if dweb.link aims to replace ipfs.io as the default gateway,
we should also support path-based addressing.

Problem

Right now unencrypted requests for dweb.link/ipfs/* work, but do not redirect to HTTPS:

• http://dweb.link/ipfs/bafybeicgmdpvw4duutrmdxl4a7gc52sxyuk7nz5gby77afwdteh3jc5bqa/wiki/Mars.html

Explicit request over HTTPS produces certificate error:

• https://dweb.link/ipfs/bafybeicgmdpvw4duutrmdxl4a7gc52sxyuk7nz5gby77afwdteh3jc5bqa/wiki/Mars.html?argTest#hashTest

  

Fix

This looks like a bug, so I think we want to redirect to HTTPS and add HSTS header.
(Possibly reusing fixes from #391 & #477 to dweb.link itself).

[Marcin Rataj]

Update:

I think what we want for dweb.link is to always redirect to subdomain version.

That removes the risk of website under /ipfs/<cid-A> accessing cookies and localStorage of website under <cid-B>.ipfs.dweb.link

So we want http://dweb.link/ipfs/bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html to return HTTP 301 to https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.dweb.link/wiki/Vincent_van_Gogh.html

[Michael Burns]

New CIDs are correctly being redirected: https://dweb.link/ipfs/bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html

It doesn't work with legacy (Qm...) CIDs (example: https://dweb.link/ipfs/QmczMzVBGXmUeyUprcGnac63gKDfMVNUY4cQ8V6xQEBN52/ )

[Marcin Rataj]

@mburns but it can be fixed, right? (https://github.com/protocol/bifrost-infra/issues/572#issuecomment-622374027)
Update: nvm, just seen you are already on this in https://github.com/protocol/bifrost-infra/pull/722#issuecomment-622587035 ❤️