Problem Solved By The Feature

This is related to #1720 but would be a bit more generic
This is related to #1604 but the fix done there is not fixing the issue described here

We experienced problems using the ISR library since attackers tried to access a lot of urls. Since getCacheKey uses the req.url this will lead to a separate cache-entry for each request. Within short time it filled our cache with more than 15GB of data. We had to patch the library in order to use req.path for now.

E.g.

• Changing parameters: /my-route?1, /my-route?something=1, , /my-route?something=3 ...
• Calling 404 pages: /something-404 that would look exactly the same but are not

I'm aware that this might be the wanted behaviour because of pagination etc. But i want to have the control of modifying this and i am not sure if it's the best default. For simple pages req.path could be an alternative. Even with pagination one could simply iterate over pages and generate an immense amount of entries.

For the 404-Pages I found the solution to not cache it (revalidate: null). I will gladly add this as a hint to the documentation to protect other users. So i cannot cache the 404 page, but i also don't create a new entry for every 404-page called.

Solution

I would suggest a configuration that lets you specifying your cacheKey-Function. Ideally the interface would allow to pass in the req and then users could still allow certain params.

For the 404-problem i was first thinking of having a beforeAddingToCache-hook where i can decide from the given response-code if i want to cache it or not.

Alternatives Considered

I did not come up with any other ideas, but happy to discuss it here!

My current workaround:

• usage of patch-package (follow the usage there)
• My patch (wont fit your need, but shows where the problems are): create/adapt this [patches/@rx-angular+isr+17.1.0.patch](@rx-angular+isr+17.1.0.patch