HTTP Cache-Control header works only on localhost - ajax

Question

I'm trying to configure caching with Cache-Control for a REST endpoint in my webapp, it works locally, but when I deploy on our production server the browser just won't cache the responses.
The endpoint is queried via a parametrized ajax request (as shown below).
Some relevant notes :
I use a cache buster parameter (_) that is a unix timestamp generated at page load. It doesn't change across ajax requests.
localhost is on HTTP whereas production is on HTTPS. The certificate is valid and there are no related errors.
Both Firefox 59.0.2 and Chrome 66.0.3359.139 exhibit this behavior, so I assume this is something in the configuration.
Localhost
Request URL: http://localhost:8080/webapp/rest/events?_=1525720266960&start=2018-04-29&end=2018-06-10
Request Method: GET
Status Code: 200 OK
Referrer Policy: no-referrer-when-downgrade
=== Request ===
Accept: application/json, text/javascript, */*; q=0.01
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: JSESSIONID=<token>
Host: localhost:8080
Referer: http://localhost:8080/webapp/
X-Requested-With: XMLHttpRequest
=== Response ===
Cache-Control: no-transform, max-age=300, private
Connection: keep-alive
Content-Length: 5935
Content-Type: application/json
Following requests (for the same parameters) are effectively loaded from cache with the only difference being : Status Code: 200 OK (from disk cache)
Which seems fine, since I don't want to revalidate. The resource should only be fetched again, without validation, once it has gone stale after the duration of max-age specified by Cache-Control.
Production
Request URL: https://www.example.org/webapp/rest/events?_=1525720216575&start=2018-04-29&end=2018-06-10
Request Method: GET
Status Code: 200 OK
Referrer Policy: no-referrer-when-downgrade
=== Request ===
Accept: application/json, text/javascript, */*; q=0.01
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: JSESSIONID=<token>
Host: www.example.org
Referer: https://www.example.org/webapp/
X-Requested-With: XMLHttpRequest
=== Response ===
Cache-Control: no-transform, max-age=300, private
Connection: close
Content-Length: 5935
Content-Type: application/json
In this case, the response is never loaded from cache afterwards.
I've stripped some headers that I thought superfluous (Server, X-Powered-By, User-Agent, Date).
Question
What prevents the reponses to be cached by the browser when talking to the production server ?

Answer 1

2 days later I try again and caching works properly. (I swear I'm not insane)
Same request, same headers, same response.
I suspect that it falls into some kind of heuristic that overrides the response Cache-Control.
It certainly has to do with the fact that this endpoint did not specify Cache-Control before, so the browser overlooks the header since the heuristic favored refetching instead of caching, it can't go wrong about being more cautious.
RFC2616
13.2.2 Heuristic Expiration
Since origin servers do not always provide explicit expiration times,
HTTP caches typically assign heuristic expiration times, employing
algorithms that use other header values (such as the Last-Modified
time) to estimate a plausible expiration time. The HTTP/1.1
specification does not provide specific algorithms, but does impose
worst-case constraints on their results. Since heuristic expiration
times might compromise semantic transparency, they ought to used
cautiously, and we encourage origin servers to provide explicit
expiration times as much as possible.
All in all, this is the best explanation I have.