#741 Add filtering options and logic to caching

[twinetek]

Closes #741

• Caching based on response status #741

Proposed Changes

• Added an array of HttpStatusCode to FileCacheOptions and CacheOptions to act as a whitelist of status codes.
• Before adding the response to the cache, check to see if the response status code is in the whitelist.
• If the whitelist is null, assume all status codes are to be cached
• Tests. to be added (Would like some guidance on where to put these. I suspect OutputCacheMiddlewareTests. I've also never used XUnit so there's going to be a bit of a learning curve.)
• Looking for guidance. I believe this is where and how this cache filtering would be added, but I am new to the project and getting back into coding after several years. I've also never submitted a pull request to someone else's project before so I'm hoping I'm doing this correctly.

[raman-m]

Hello, Cliff!
Welcome to the world of Ocelot, and thank you for opening this PR and making an effort to follow our development process.

• Tests. to be added (Would like some guidance on where to put these. I suspect OutputCacheMiddlewareTests. I've also never used XUnit so there's going to be a bit of a learning curve.)

Well... correct, OutputCacheMiddlewareTests contains our unit tests for the OutputCacheMiddleware class. You can use MSTest classes and engine, and I hope both frameworks (xUnit and MSTest) can be combined in a single testing class.

commit 159da67

Please avoid using CacheManager in our tests, as this library will be deprecated in the next .NET 10 release due to issue #2334. Since release 24.0, we've removed the integration testing project and moved all integration tests to the Ocelot.AcceptanceTests project, where we combine both integration, acceptance and API testing. All caching acceptance tests should be kept in the Caching folder, so please move the "real cache" acceptance tests there.

• Looking for guidance. I believe this is where and how this cache filtering would be added, but I am new to the project and getting back into coding after several years. I've also never submitted a pull request to someone else's project before so I'm hoping I'm doing this correctly.

Sure, our team will provide guidance, but please be patient as I'm currently swamped with the hot v24.1 release we're aiming to finish this week. Also, please include acceptance tests as they are an important part of the development process alongside integration/unit tests, and I'll arrange for the team to carry out code reviews. Good luck with the delivery! 😉

[coveralls]

coverage: 92.947% (+0.009%) from 92.938%
when pulling 14a63b1 on twinetek:allow-cache-filtering-based-on-reseponse-statuscode
into 1fdf6c2 on ThreeMammals:develop.

[twinetek]

Raman,
Thanks. I'll try to find some time tonight to make those changes. I'm not in a rush, so any guidance as you or your team can provide at your convenience is just fine. Thank you for your patience!

[raman-m]

We overlooked an important detail: the global configuration, which was improved in the latest PR #2331. The current design adds a StatusCodes option, listing allowed or included codes. For users, listing all codes for a route is challenging, and doing the same in the global StatusCodes config is also cumbersome. What if we also took an exclusion scenario into account? When a user wants to exclude just a few statuses, the configuration becomes much simpler.
In the original #741 feature, the following configuration was discussed or proposed 👇

"CacheOptions": {
  "TtlSeconds": 0,
  "Region": "",
  "StatusCodes": [400, 404, 405, 410] // excluded or included?
}

I think this currently only covers the excluding scenario. We should reconsider your initial implementation to handle the including scenario as well. We also need to implement the excluding scenario explicitly. I suggest introducing groups of codes like 2xx, 3xx, 4xx, and 5xx, where having a single 200 code in the array would represent all 2xx statuses. Finally, we should add a management Boolean option to enable or disable the status codes feature on the fly, so that global status checks can be turned off for specific routes, and vice versa, re-enabled for certain routes even when globally disabled.

More technical details will follow.
Should I ask the team for a code review? Our review process isn't quick and could take a few weeks.