Add catch-all for non-existent paths handled by Service Worker

lidel commented 1 year ago

just a quick brain-dump, apologies if this was already discussed

If someone copies URL for a path that is handled by the service worker BEFORE SW is registered, they will get HTTP 404.

By adding _redirects file with a catch-all rule for everything under the path dedicated to SW. See https://docs.ipfs.tech/how-to/websites-on-ipfs/redirects-and-custom-404s/#catch-all-and-pwa-spa-support

The only caveat is that _redirects work only on Subdomain and DNSLink Origins (they do not work on Path gateways), but as long you request {cid-of-helia-service-worker-gateway}.ipfs.dweb.link/helia-sw/ipfs/{cid-to-load-via-sw} it will work fine.

SgtPooki commented 1 year ago

We did discuss this, but it's great to have a tracking issue for this, thanks :)

SgtPooki commented 1 year ago

a quick fix I was thinking of that would solve this situation for non-gateway situations would be to change the service-worker handle query paths.

i.e. instead of mysite.com/helia-sw/ip(n|f)s/blah do mysite.com/?helia-sw=/ip(n|f)s/blah

This would have all requests land on the main page (where SW is registered).

if SW isn't registered, when it's registered, we can re-send the request so the SW can capture it.
If the SW is registered, it should be captured.

Any thoughts on adding this approach to the _redirects? I imagine the _redirects approach will only work when the fleek-hosted site is loaded on a gateway.

lidel commented 1 year ago

I think the URL query param trick is a cool way for making the demo work, but not a silver bullet for things that involve a foreign fetch (hotlinking, or trying to download in contexts other than web browser).

Some thoughts below, but probably a bit too far ahead (matter only once we start integrating this into boxo/gateway library). I think it's fine to do ?helia-sw= for now and even put it in _redirects if it makes your MVP work easier.

[..] for non-gateway situations would be to change the service-worker handle query paths.

What are the non-gateway use cases that you aim for?

The way I was thinking about "production" use of this, is to follow existing path gateway convention, as it enables us to leverage multiple levels of fallback and "always works":

have example.net/ipfs/ redirected to local gateway if user has their own node and something like IPFS Companion
have example.net/ipfs/ handled by service worker (if present and registered)
have example.net/ipfs/* return 302 to https://ipfs.io/ipfs/*, so if there is no service worker, the content still loads, even when the link was copied and fetched via curl

SgtPooki commented 1 year ago

trying to download in contexts other than web browser

I think that's out of scope for a service worker anyway isn't it? Can you help me understand how that applies here?

What are the non-gateway use cases that you aim for?

Users who want gateway type functionality for only their content. i.e. they want to load ipfs content as a gateway would, but don't want to conform to the gateway spec (for testing new spec, experimenting, business-specific logic, etc..)

I was thinking of this demo as a reasonable example of using a service worker for loading ipfs content. It's generic enough to work as a gateway-fallback or specific client-side loading of IPFS content outside of gateway contexts.

Sure, for gateway support, using _redirects is great, but that file is going to be ignored outside of ipfs-gateway contexts, correct?

ipfs / service-worker-gateway

Add catch-all for non-existent paths handled by Service Worker #5