Closed lidel closed 1 month ago
Early idea: service-worker-gateway should pass the original URL to verified-fetch('https://specs-ipfs-tech.ipns.inbrowser.dev/ipns/ipns-record/')
so it has all information to make the right decision. Ir follows our design of shifting all conformance work to verified-fetch, when possible.
Once verified-fetch knows it is subdomain URL request, it will be able to not trigger /ipns/{id}
resolution because it will know the content path is /ipns/specs.ipfs.tech/ipns/ipns-record/
@2color @SgtPooki thoughts?
@lidel yep, we should pass everything to verified-fetch and I believe we already are. However, there are some "gateway" things happening at sw level in order to receive/route requests.. we need to make sure it's not getting in the way
@lidel I believe the changes in https://github.com/ipfs/helia-verified-fetch/compare/main...84-fix-infinite-querying-bug-reproducible-on-some-gateway-conformance-tests-that-were-disabled-in-httpsgithubcomipfshelia-verified-fetchpull81, fix this. Specifically https://github.com/ipfs/helia-verified-fetch/commit/1b96aa2147de00e02ffcf58045ea499b9ebaa5e3
Example: https://specs-ipfs-tech.ipns.inbrowser.dev/ipns/ipns-record/
The
/ipns/
makes verified-fetch attempt to do DNSLink lookup foripns-record
hostname.This should not happen because we are already on subdomain gateway.