Customize cache key generation

[sagikazarmark]

Q	A
Bug?	no
New Feature?	yes
Version	1.2

Actual Behavior

The cache key is currently generated based on the following details:

• hash algo
• request method
• URI
• request body

Expected Behavior

One should be able to customize this behaviour.

Example: Separate cache entry per authorization header.

Possible Solutions

Introduce a CacheKeyGenerator interface which would receive the request as a parameter.
It should be an optional parameter of the plugin, falling back to the current implementation.

[dbu]

👍
I think the key generator should also have the possibility to say a request is not cacheable. Maybe by throwing a specific exception, as that is nicer than returning null to indicate we don't want the request to be cached.

[Nyholm]

👍

I think the key generator should also have the possibility to say a request is not cacheable.

Maybe... or we put that functionality in another class.

[dbu]

Maybe... or we put that functionality in another class.

also thought about that, but the drawback is that the cache key generator will notice when things are missing / not good to do a cache key and could abort. but yeah, there is the risk of abusing this to just decide on cacheability of a request...

[sagikazarmark]

I agree with @Nyholm, it's a separate responsibility. The CacheKeyGenerator can throw an exception though which can result in cacheability to be impossible, but that decision needs to be made elsewhere.

Actually I forsee that we are going to move the entire caching stuff to the message package and just wrap it in the plugin. Not sure if it makes sense, but we are putting tons of effort into it, would be nice to see if the caching logic can be used elsewhere or not.