Manage caching options: `EnableHeadersHashing` vs `CleanableHashingRegexes`

[Taiizor]

New Feature: EnableHeadersHashing & CleanableHashingRegexes

This pull request introduces several enhancements to the caching mechanism by adding new configuration options and updating related tests. The main changes include the addition of headers hashing, cleanable hashing regexes, and their integration into the existing caching logic.

Hashing Behavior Configuration

• If EnableContentHashing is set to False and EnableHeadersHashing is set to False:

  • The output is written to Redis and remains consistent until its expiration time, even if the parameters change.
  • Hint: CleanableHashingRegexes is it doesnt make a difference.

• If EnableContentHashing is set to True and EnableHeadersHashing is set to False:

  • The output is written to Redis, but no data is ever retrieved from Redis.
  • Hint: CleanableHashingRegexes is not using. If used it will work.

• If EnableContentHashing is set to True and EnableHeadersHashing is set to True:

  • The output is written to Redis and remains consistent until its expiration time.
  • Hint: CleanableHashingRegexes is using. If its not used it will not work.

Example Usings

"FileCacheOptions": {
	"TtlSeconds": 600,
	"Region": "versatile",
	"EnableContentHashing": true,
	"EnableHeadersHashing": true,
	"Header": "AL-Caching-Control",
	"CleanableHashingRegexes": [
		"cf-ray=[a-f0-9]{16}-[A-Z]{1,3}", //CloudFlare CF-RAY
		"--[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}--|(--[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})" //GUID of Parameters
	]
}

Always Caching [EnableContentHashing False - EnableHeadersHashing False]

Nothing Caching [EnableContentHashing True - EnableHeadersHashing False]

Working Caching [EnableContentHashing True - EnableHeadersHashing True]

[Taiizor]

Let me briefly explain the changes:

When EnableHeadersHashing is enabled, it reads the request headers and adds them to the cache key. However, the parameters in the request headers include unique GUIDs every time. A different example of this issue is when a proxy like CloudFlare is used. These setups can also add their own header parameters with each request. To resolve such situations, CleanableHashingRegexes can be used as an additional solution.

Perhaps, on the Ocelot side, a default regex pattern could be added to CleanableHashingRegexes to remove parameter GUIDs. Similarly, the same solution could include a default regex pattern for CloudFlare.

Regex pattern for solving the parameter GUID issue: --[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}--|(--[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}) Regex pattern for solving the CloudFlare issue: cf-ray=[a-f0-9]{16}-[A-Z]{1,3}

public CacheOptions(int? ttlSeconds, string region, string header, bool? enableContentHashing, bool? enableHeadersHashing, List<string>? cleanableHashingRegexes)
{
	TtlSeconds = ttlSeconds ?? 0;
	Region = region;
	Header = header;
	EnableContentHashing = enableContentHashing ?? false;
	EnableHeadersHashing = enableHeadersHashing ?? false;
	CleanableHashingRegexes = cleanableHashingRegexes ?? new()
	{
		"cf-ray=[a-f0-9]{16}-[A-Z]{1,3}" //CloudFlare CF-RAY
		"--[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}--|(--[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})" //GUID of Parameters
	};
}

[raman-m]

What's your real full name? Please stop using any AI-powered code generation and text generation tools ❗ I would prefer to talk to a real human who speaks English.

P.S.

Thank you for creation the PR without fake changes. The PR has no EOL issues now.