Better control of caching logic by following headers and a manual option to turn of caching for a request #19
Conversation
…st and changed logic for Cache Expiration to include the `max-age` value if it's less than what we configured for the status code
|
I‘ll have a look at it. Thanks for your effort. |
|
Any ETA? Or Update? |
|
Ok I did have a look at this. Just two small comments, if you want to have a look at the review. |
|
How did you test this? |
|
Back then I used Wireguard to check for traffic and called REST API I was working on implementing - and saw it cached the response based on the given max-age - testing the manual turn off was easy, just saw it fire the request each time instead only when the cache expired. How so? Is there a problem? |
Not a problem. The thing is just, I generally understand what the code does, but is it bullet proof? We can only find out if we test it with unit tests. To be honest, I don't know if the rest of the code is well tested. I'd do some unit tests to prove that we didn't forget anything. I'm just sharing my thougts, I don't want to offend you :) |
|
You can find the changes in the latest 1.6.x pre release. Let me know if it works as expected. Then I release it as stable nuget. Thank you @ThaDaVos |
|
Curious, but when get we expect a stable 1.6.x release? I saw the nuget still shows |
This PR adds support for better control of what is cached and when - first of, using
HttpRequestMessage.Properties/Optionswith a specific key allows one to disable checking the cache for a request. It also follows theCache-Controlheaders from the server, including themax-ageif it's lower than the specified cache time.Issue: #18