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

Step 4. of https://w3c.github.io/ServiceWorker/#cache-put says:

> If innerRequest’s [url](https://fetch.spec.whatwg.org/#concept-request-url)'s [scheme](https://url.spec.whatwg.org/#concept-url-scheme) is not one of "http" and "https", or innerRequest’s [method](https://fetch.spec.whatwg.org/#concept-request-method) is not `GET`, return [a promise rejected with](https://webidl.spec.whatwg.org/#a-promise-rejected-with) a TypeError.

This means that you can't put request urls with different schemes, for example `ipfs://` in the cache, even if you have a valid constructed response for this request.

I have a program that retrieves data and caches it over both `http://` and `ipfs://`. For `ipfs://` urls, I re-write the url to fetch via a local `http://` gateway. Because I want the cache entry to be gateway-independent, I would like to store the original `ipfs://` url in the cache. However, as the spec says, I cannot do this. So the obvious solution is to just work around that by re-writing the cache url to use `http://` instead.

I do a similar thing for requests with the `Range:` header set where a partial response (status code 206) is returned. The cache normally rejects these (step 6.) so I instead resolve the response array buffer and fabricate a new response, inserting it into the cache with a `bytes=X-Y` query pair.

In summary, I think the Cache API would be much improved by removing some of these limitations so that I and others don't have to ship work-arounds to them.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1643

You are receiving this because you are subscribed to this thread.

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