Trials and tribulations when using the "baked in" caching

[Jokinen]

I read through some discussion/issues to do with caching with undici. It's clear that there's interest around the topic and that steps have been taken to tackle caching. I attempted to use the baked in caching to replace an in-memory-cache we had setup for another http client we are migrating away from.

This comment contains an example of how the cache can be used (it has been floated elsewhere as well): #2760 (comment)

There are other promising discussions of a similar nature, but the work is still ongoing in all of them (AFAIK).

I used the example from the comment as inspiration. I had to be more careful with what classes I used. I had to use undici.Request and undici.Response when interacting with the cache, and node:intenals.Request/Response in other cases. Otherwise instanceof checks failed. Perhaps something to do with my project environment. I also assume that the example is not a great starting point for userland, but I gave it go because I wanted to understand what it exists for.

Ultimately I had to abandon this route for caching as the implementation (I assume correctly) does not allow GET requests to be cached as I am trying to cache POST requests.

One interesting tidbit is that the error message from this line doesn't appear to be accurate:

undici/lib/web/cache/cache.js

Lines 279 to 284 in 8a9db10

	if (!urlIsHttpHttpsScheme(innerRequest.url) || innerRequest.method !== 'GET') {
	throw webidl.errors.exception({
	header: prefix,
	message: 'Expected an http/s scheme when method is not GET'
	})
	}

The if statement seems to bar any GET request. So a more accurate error message would be that the request has to be http AND it has to be GET. This is quite a small detail.