Get execution context OR server-side conditional refresh

[juantxorena]

I'm trying to implement server-side conditional refresh. The docs only talk about client-side, i.e. a client requesting a remote server.

In my case, I'm implementing the server, which offers an API and does some database queries, some of which are expensive and the data they retrieve changes rarely. So my idea is to cache the database results (and invalidate them when needed), calculate an etag (or last modified or something), and store it in the cache as per the docs. When a client requests something, I would check if the cache has the same tag, and if it does, then return a 304, by implementing a custom policy for output cache as explained in the asp.net docs.

However it doesn't seem possible to do it, since I cannot access the execution context from outside of the delegate, so if I call a GetOrSet, I would only get the value itself, without knowing if it was from the cache or not. Related to this last point, there's this discussion, which might be useful, but it's not ideal, since I'm retrieving a potentially large object (maybe from redis) for nothing.

Another solution could be to get the object and calculate the etag or something everytime, but of course, this is also far from ideal.

What I think it makes more sense for this case, and probably for many other situations, is to be able to retrieve the "metadata" of a cache key without retrieving it, to check things like Etag, LastModified, StaleValue, Duration, and things of the sort, so it could be used for this kind of things.

Is there any better way of doing what I want to do? Does it make sense at all (I'm a newbie in cache stuff)? Would it make sense to implement the GetMetadata function that I'm suggesting?

[jodydonetti]

Hi @juantxorena , sorry for the delay, I'm recently onto something quite massive and delicate.

I'm trying to implement server-side conditional refresh. The docs only talk about client-side, i.e. a client requesting a remote server.

This is interesting! Meanwhile, have you been able to come up with something?
I'm definitely interested to know.

However it doesn't seem possible to do it, since I cannot access the execution context from outside of the delegate

Yes, because the execution context exists only when the factory is being executed, therefore it's not accessible from outside the factory itself.

What I think it makes more sense for this case, and probably for many other situations, is to be able to retrieve the "metadata" of a cache key without retrieving it
[...]
Would it make sense to implement the GetMetadata function that I'm suggesting?

Eh, this is not possible since for both L1 (MemoryCache) and L2 (IDistributedCache) I can only work with their available api surface area, meaning their methods (basically single GET/SET/REMOVE, and that's it).

Is there any better way of doing what I want to do?

I should think about it more probably, but maybe using 2 cache entries per-content?
One cache entry with the data (bigger), and another with only the metadata (smaller).
The request would check the etag in the metadata, and when the metadata expires, it will load the data again (and save it in its own cache entry) and calculate the metadata.
Again, not 100% sure about the approach, just 1am throwing an idea to play with 😅

NB: watch out though for a potential DDoS venue. What I mean is that if every time you receive a request with an ETag different than the one in the cache you go to the database (or whatever it isin your case), somebody can just make a loop requesting random ETags and your database will burn down.
It's the same issue as NOT caching nulls, you are opening yourself for a DDoS attack.

Does it make sense at all (I'm a newbie in cache stuff)?

We are all newbie about something 🙂

Hope this helps, let me know!

[juantxorena]

Thanks for the answer, and sorry too for the delay.

This is interesting! Meanwhile, have you been able to come up with something?
I'm definitely interested to know.

This topic is also low prio for me, so I didn't check almost nothing about this. My first attempt failed, however, because I misunderstood the point of custom policies for output cache. Apparently they are only about what to cache, not how and where, so I cannot use it as I thought.

I should think about it more probably, but maybe using 2 cache entries per-content?
One cache entry with the data (bigger), and another with only the metadata (smaller).
The request would check the etag in the metadata, and when the metadata expires, it will load the data again (and save it in its own cache entry) and calculate the metadata.
Again, not 100% sure about the approach, just 1am throwing an idea to play with 😅

I thought about having a cache for cache, i.e. a cache for storing the metadata of cache values, but other than it being a rather ugly hack, it looks very error prone with invalidations and stuff (especially automatic invalidations). Maybe it will be easier with the incoming cache tagging, but it would be still a hack.

NB: watch out though for a potential DDoS venue. What I mean is that if every time you receive a request with an ETag different than the one in the cache you go to the database (or whatever it isin your case), somebody can just make a loop requesting random ETags and your database will burn down.
It's the same issue as NOT caching nulls, you are opening yourself for a DDoS attack.

About the DDoS, that's true, I didn't thought about it, mainly because I'm the one developing the server side and one of the clients side (the main one), so I know I'm not going to DDoS myself. However, wouldn't this problem affect any other caching strategy too? Even if I just read the cache and send it, without any 304 thing, the server would be ddosed anyway. I haven't look into it, but I assume that the http pipeline has some protection for this in some middleware, so I assume it would came into effect for this situation too (and if it doesn't have, we would be vulnerable anyway, so no difference here).

I still think it would be a good idea to be able to retrieve the cache metadata anyway, for this situation or any other (I've seen requested the ability to know if something is cached, or to know if a result came from cache or not), even if this isn't part of the IMemoryCache interface. We are using FusionCache and not any other implementation anyway. I had a quick look at the code and I think it's doable, but it's way above my current abilities and I have no time for this right now, but maybe it could be a nuget package like "FusionCache.Extensions" or something.

Finally, I'm not sure if this is a request, a rant, or just a collection of random thoughts. I've been following some issues in github about output caching and the incoming new IDistributedCache, and I think that there's some disconnect between both. Probably they are being developed by completely different teams, but it's very surprising to me that "Normal cache" and "Output cache" are completely different and have nothing in common in the .NET. I haven't checked the code, but maybe the output cache doesn't even use the IMemoryCache interface. I would have thought that they were very related, and "Output cache" was a special usecase of the general caching strategy, and therefore that FusionCache or any other implementation could have something to say about it, but I was wrong. I cannot even respond to API queries with a 304 without doing some dirty hacks, it supposed to be controlled automatically by the middleware and developers have little to say on this.

[jodydonetti]

About the DDoS, that's true, I didn't thought about it, mainly because I'm the one developing the server side and one of the clients side (the main one), so I know I'm not going to DDoS myself. However, wouldn't this problem affect any other caching strategy too? Even if I just read the cache and send it, without any 304 thing, the server would be ddosed anyway.

Any new request (eg: a new url) will require going to the database, yes, but not multiple request for the same url, which is the problem with not caching nulls.

I haven't look into it, but I assume that the http pipeline has some protection for this in some middleware, so I assume it would came into effect for this situation too (and if it doesn't have, we would be vulnerable anyway, so no difference here).

Finally, I'm not sure if this is a request, a rant, or just a collection of random thoughts. I've been following some issues in github about output caching and the incoming new IDistributedCache, and I think that there's some disconnect between both. Probably they are being developed by completely different teams,

Based on my understanding yes, that is the case: different teams.

I haven't checked the code, but maybe the output cache doesn't even use the IMemoryCache interface. I would have thought that they were very related, and "Output cache" was a special usecase of the general caching strategy,

This is correct in my way, we have to look at it as a special case of caching: having said that, I always wanted to create an implementation of it based on FusionCache. The problem was (past) that it required tagging (see here the interface I would need to implement).
Now that FusionCache is getting Tagging support, I'll be finally able to do that 😬

and therefore that FusionCache or any other implementation could have something to say about it, but I was wrong.

Wait, why do you say that? I'm interested.

I cannot even respond to API queries with a 304 without doing some dirty hacks, it supposed to be controlled automatically by the middleware and developers have little to say on this.

I'll have to look into it more then.

[juantxorena]

and therefore that FusionCache or any other implementation could have something to say about it, but I was wrong.

Wait, why do you say that? I'm interested.

What I meant was simply that since I thought that the output cache was just a special case of IMemoryCache, I could use FusionCache (or NCache or EasyCaching or whatever) to implement it and use all of their features, but I was wrong.

I cannot even respond to API queries with a 304 without doing some dirty hacks, it supposed to be controlled automatically by the middleware and developers have little to say on this.

I'll have to look into it more then.

In my case I was returning TypedResults in my API, e.g. like this:

            group.MapPost("/contractors", async Task<Results<Created<Guid>, BadRequest<IEnumerable<ValidationFailure>>>>
                ([FromBody] string contractor, [FromServices] IAdministrationService administrationService) =>
            {
                OneOf<Guid, IEnumerable<ValidationFailure>> result = await administrationService.AddContractor(contractor);
                return result.Match<Results<Created<Guid>, BadRequest<IEnumerable<ValidationFailure>>>>(
                    added => TypedResults.Created(null as string, added),
                    errors => TypedResults.BadRequest(errors)
                );
            });

but neither TypedResults nor IResult implement NotModified. It's easy enough to do something like Results.StatusCode(StatusCodes.Status304NotModified);, but the fact that 304 is not exposed anywhere suggests that it's not meant to be manually managed for some reason.

In any case I think this is out of the scope of FusionCache.