Unexpected automatic (local) caching of requests without query strings

First of all, I’m not sure if this is really a bug or intentional behavior, but here’s a test anyway: https://gist.github.com/apottere/93e89c7645c1b2e9f97402b10507d574

We decided to switch from Apache HC to OkHttpClient in our rest APIs to take advantage of better pooling/connection re-use. We’re using the Spring Boot starter to create a RestTemplate with which we call backend REST APIs (java -> java). Everything worked great out-of-the-box, until we noticed that one of our services wasn’t getting called at all.

We did some digging and realized that it’s the only service that uses ETag and Last-Modified to support caching of requests with conditional gets, but it does not set any other cache-control headers. We found that our clients were no longer sending more than one request to the API because of this block of code.

The provided test shows that a request for a URL - given a previous response for that url with ETag and Last-Moidified headers returned - will hit that block of code, and one of two things will happen:

1. If the request has no query parameters, it will return the cached response without contacting the server
2. If the request has at least one query parameter, it will send a request to the server with a conditional get.

With respect to the comment on the offending block of code, it could be reasonable that a browser cache pages without query parameters for some time if they’ve sent a Last-Modified header, but it seems completely unexpected for that to be default functionality in a REST client.

Would it be possible to make this behavior opt-in instead of opt-out?

[yschimke]

Won’t fix.

[apottere]

AFAICT that’s the only section of the http caching RFC that uses the language MAY, so it doesn’t seem too unreasonable to want a toggle for turning that functionality on and off.