Open lidel opened 5 months ago
Based on testing on the SW Gateway deployed to both localhost
and inbrowser.dev
, it seems that the Chrome blocks requests to localhost in a service worker. It seems that localhost is not treated as secure context when the request originates from a service worker.
@lidel also tried setting the local gateway in the config of inbrowser.dev on Firefox and saw the same behaviour, i.e. requests to localhost from the service worker are blocked (and not showing up).
Next step: set up a simple reproduction to demonstrate that requests from a service worker to localhost are blocked to ensure that it's not related to our set up
Triage notes based on slack discussion:
allowLocal
and allowInsecure
settings (code) are the underlying reason (both false
by default)
true
for now if a localhost
gateway URL is provided in the configDescoping from Camp milestone due to limtied utility (see Brave issue in https://github.com/ipfs/service-worker-gateway/pull/303#pullrequestreview-2148664363).
Right now, the app default to a single public gateway at trustless-gateway.link
This ok, but makes perf. testing tied to remote backend which is provided on best-effort basis.
Suggested improvement
Default to local gateway, if present
Probe well-known localhost URL for presence of trustless gateway, and prepend it to the list.
A good test is
http://127.0.0.1:8080/ipfs/bafkqablimvwgy3y?format=raw
and confirming the response ishello
bytes andContent-Type: application/vnd.ipld.raw
.An easy win for IPFS Camp, we should probe for
8080
/8081
(kubo/desktop). We could also probe8090
(rainbow).This is a first step towards adding resiliency. In the future, we could do similar probing for gateways from https://ipfs.github.io/public-gateway-checker/ but focusing on localhost detection is a priority atm.
This way, service-worker-gateway would have a path to be fully independent of public infra for block retrieval if the user has IPFS Desktop installed.
Optional sidequest: enable
/routing/v1
in IPFS Desktop by defaultSimilar, we could expose
/routing/v1
from Kubo in the next version of IPFS Desktop, and service-worker-gateway that confirmed local gateway exists, could then probe if/routing/v1
exists.The caveat here is that this should be used in addition to the public one because Kubo will filter out peers it can't use (so no
/http
ones for now), limiting its utility to bitswap over wss and webtransport.