Open jeswr opened 6 months ago
The hardest part of this is what is considered an indentical request.
Overall, this would be a nice interceptor to add.
I'd suggest starting with an idempotent request by default and its request for fingerprint for checking identity, and verifying its response with a possible timeout to invalidate the cached responses.
Also some hooks similar to what we did for retry
interceptor so implementations can customize the behaviour for validating if two requests are identical.
In rfc 9111 it actually defines requests where the http cache should return the same cached response. This definition could be used.
Btw. How do you handle streams?
True, this can help provide some guidance for defaults: https://www.rfc-editor.org/rfc/rfc9111.html#name-storing-responses-in-caches
I'd just still be mindful of providing some control to the implementation.
Btw. How do you handle streams?
wdym?
With streams you can have multiple consumers consuming the response with different speeds. We should only do this for requests where the response body can be fully buffered into memory.
This would solve...
Performance and robustness issues associated with fetching the same HTTP resource in parallel in several places across a codebase.
The implementation should look like...
Using an interceptor, keep an internal record of pending requests, if an identical request is already pending re-use the response across the multiple pending requests
Additional context
Originally raised in https://github.com/nodejs/undici/issues/3221, related to https://github.com/nodejs/undici/issues/3231