The unnecessary limitations of the Cache.put API leads to users inventing work-arounds

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

If innerRequest’s url's scheme is not one of "http" and "https", or innerRequest’s method is not GET, return 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.

No repository file or test is named. Start by reading the Cache.put algorithm in the linked Service Worker specification, especially steps 4 and 6, then review the issue's sole comment and the referenced Fetch and URL definitions. Done requires an agreed, precise scope for which limitations should change and corresponding specification updates.