Open pietercolpaert opened 2 months ago
I also noticed the lack of http caching in the client and came here to write an issue, but it's already there! :partying_face:
It otherwise does not make sense to have HTTP caching that stores the full response, as it is never going to be used again.
When developing a client (in the sense of "something that uses whatever ldes-client
spits out"), caching the full http responses is actually very useful: during development one frequently resends exactly the same requests, because some other part of the code changed.
Also because the spec mentions http caching explicitly (in the first note of section 2), I expected the ldes-client
to respect the cache headers.
The ldes-client is going to respect caching headers on a second run if you pass a state file location though using -s. Does that fix your problem?
I didn't release the client implements its own caching, thanks!
Later it turned out that the endpoint that I was developing against doesn't return cache-control headers, so I think that was the root cause... :facepalm:
In rdf-derefence you can pass a custom fetch function: https://www.npmjs.com/package/rdf-dereference#input-using-a-custom-fetch-function
I wonder if there’s a way to implement regular HTTP caching, but only for the JSON-LD context documents if they need to be fetched externally. In the LDES client it otherwise does not make sense to have HTTP caching that stores the full response, as it is never going to be used again.