Closed BrettJaner closed 3 years ago
Hey @aliostad, would you like me to take a stab at the PR for this? I was thinking we'd just need to modify the CachingHandler.ResponseValidator
to return ResponseValidationResult.MustRevalidate
when the no-cache header is provided in the Request?
Sure, by all means. Only that if you could create a feature branch so I could bring to the branch and then merge. I hate master merges as sometimes I had backout stuff.
So do you need to create me a feature branch for which I will submit my PR against? I guess I'm under the impression that it shouldn't matter what branch I develop on in my fork and I don't have access to create a branch in your repo. Please correct me if I'm wrong.
As long as it is not the master, please.
Your fix was published in version 2.8.2. Thanks for your efforts and spotting his bug.
No problem. Thank you for your guidance in my HTTP caching exploration.
When the no-cache header is included in the request, CacheCow.Client still serves the response from cache. The expected behavior should be that the cached resource is revalidated with the origin server. Here's sample repro:
Output
----- GET /my-number ----- Cache-Control: public, max-age=3600 ETag: "tlifxqsNyCzxIJnRwtQKuZToQQw" Date: Mon, 26 Apr 2021 21:17:20 GMT x-cachecow-client: 2.8.1.0;did-not-exist=true
----- GET /my-number ----- Cache-Control: public, max-age=3600 ETag: "tlifxqsNyCzxIJnRwtQKuZToQQw" Date: Mon, 26 Apr 2021 21:17:20 GMT x-cachecow-client: 2.8.1.0;did-not-exist=false;retrieved-from-cache=true
----- GET /my-number (with no-cache) ----- Cache-Control: public, max-age=3600 ETag: "tlifxqsNyCzxIJnRwtQKuZToQQw" Date: Mon, 26 Apr 2021 21:17:20 GMT x-cachecow-client: 2.8.1.0;did-not-exist=false;retrieved-from-cache=true