Re: [w3c/ServiceWorker] The unnecessary limitations of the Cache.put API leads to users inventing work-arounds (Issue #1643)

I have come to this issue searching for rationale behind not allowing HTTP method(s) other than GET (and HEAD) in request-response pairs to cache. But for a non-HTTP protocol like IPFS, what would the meaning of the e.g. `header` property on `Request` and `Response` be? Or `method`? I don't think it makes sense for the Cache API to allow something not derived from HTTP, for the reason mentioned (and related reasons).

What you're looking for is a custom cache, using a composite index modeled by a "IPFS.Request" class of your choosing, into a set of "IPFS.Response" records that conform to whatever and however resources can be represented as obtained over IPFS.

You can write an "IPFS.Cache" class that implements the `Cache` interface well enough for you to be able to use it in place of [platform] `Cache` objects.

Alternatively, if IPFS _can_ carry/work over HTTP, then I'd argue you should retain `http://` in your URLs, and bolt IPFS-specific things on top of `Cache` so it's oblivious to IPFS, while at the same time allowing extension.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1643#issuecomment-2302759062
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1643/2302759062@github.com>