Information about cache hits about http-cache

[06chaynes]

Fixed in PR #11

[stoically]

That confirmed again that caching is a beast. 😅 You seem to be right tho, I'm running a test against a wiremock server and it only sees two requests for my scenario. So all seems fine and the issue could be closed from my perspective. 👍

[06chaynes]

One thing I've considered adding is a custom header, perhaps optional, that has some hit/miss info. I'm not sure if there's a standard way of handling that, but I'm pretty sure I've seen things like "x-cache" and "x-served-by" out in the wild before.

Adding those custom headers would likely be the easiest way to track this but I'm open to suggestions.

Edit: ah yeah, I do see this https://lyte.id.au/2014/08/28/x-cache-and-x-cache-lookupheaders/

[06chaynes]

Started working on an implementation here: https://github.com/06chaynes/http-cache/blob/x-cache-headers/http-cache/src/lib.rs

[06chaynes]

For quick reference what I have atm is:

x-cache header: Did this proxy serve the result from cache (HIT for yes, MISS for no)

x-cache-lookup header: Did the proxy have a cacheable response to the request (HIT for yes, MISS for no)

[stoically]

That's great. Exposing it as headers does indeed make sense. I wonder, does your branch also consider the case were your request contains the cache bypassing headers as mentioned in the blog article? Can't seem to see it. Just asking since if it doesn't, then x-cache-lookup wouldn't serve a purpose, right?

[06chaynes]

I added this in somewhat hastily but I think I have the various situations covered in the logic. I did extend a few tests, including one to check for this particular situation. That test can be found here: https://github.com/06chaynes/http-cache/blob/668e42bce73dcf3a6a20d0fe58eab7799fd65db6/http-cache-tests/src/client_surf.rs#L104-141

I do a cold pass, check to make sure both headers were MISS, then a hot pass to make sure the lookup was a HIT but the return was a MISS (as I am forcing the NoCache mode in this test)

Further testing is likely (absolutely) needed

Thinking on it I do need to at least check the behavior when no-cache was specified in the response in Default mode. I think it might return two misses with the current logic, rather than a lookup hit.

It would be much easier to drop the lookup header entirely, but it does seem like it could useful in certain situations. It could also be that I'm imagining vague scenarios that aren't really real world occurrences and I'm just making more work for myself. So there's that

[06chaynes]

The good news this has led to several bug fixes, the bad news is this has led to several bug fixes

For one it turns out I wasn't properly handling a situation where the conditional response was a 200, and was returning the cached response instead. This meant that I wasn't properly respecting the no-cache directive in the response. I think I have that fixed now though, at least my test seem to be giving the expected output for this scenario.

[06chaynes]

Dang I had a lot more wrong than I had realized, fun times. Anyways I think what I have now is really close, and the amount of logic issues this helped find was worth it alone. Sometimes you just need some tedious (but valuable) tests to tell you what's up (let's hope those are correct as well!)

[stoically]

Thanks for putting in the effort. And yeah, those tests look extensive now. They also helped me to understand the x-cache MISS / x-cache-lookup HIT scenario better: basically if the conditional request gets presented a 200 by the remote but there was also something in the cache for that request. Makes sense. Works well for me now!

Something I'm a bit unclear about still: In my use case I'm doing a HEAD request to the remote first to check for a content-type. Is that request also cached as basis for the conditional request or is me doing a HEAD first and then a GET basically triggering 3 requests?

[06chaynes]

Since I include the method as part of the cached record’s key "method:url" the responses for GET and HEAD requests are stored separately and both should be subject to the same set of rules.

So the first HEAD and GET requests to a resource should result in two requests, while subsequent requests would follow the revalidation logic each with their own policy. So if the next HEAD request is made and the cached record is fresh it shouldn’t result in a request, unless revalidation was determined to be required whereas a revalidation request would be sent.

So you could potentially have a revalidation request sent for both depending on the directives, cache mode, age, etc. I don’t think it would result in a third request though because if the server determines the response to be stale it should return the new body with a 200 status, which would update the record in cache for that method-resource combo and return the new response.

I think this is the case anyways!

[06chaynes]

Good to hear! I should have a new version published sometime today. The bump of http-cache-semantics to v1.0.0 also bumped the MSRV up to 1.56.1, so considering if I should go ahead and change editions before I publish since that's the case.