I have set up a page rule:
www.intmath.com/* Cache everything
I have checked max-age is > 0 (cache-control:public, max-age=14400), and “expires” is in the future. There does not appear to be a cookie in the response.
All other file types appear to be caching correctly and returning a HIT. Can anyone help to spot why the PHP-based pages are not being cached?
This is the response in Chrome:
- alt-svc:quic=":443"; ma=2592000; v=“35,37,38,39”
- cache-control:public, max-age=14400
- content-type:text/html; charset=utf-8
- date:Thu, 10 Jan 2019 02:45:21 GMT
- expect-ct:max-age=604800, report-uri=“https://report-uri.Cloudflare.com/cdn-cgi/beacon/expect-ct”
- expires:Thu, 10 Jan 2019 06:45:21 GMT
- set-cookie:ph=0; path=/; domain=intmath.com
Thanks in advance.
Is there a unique query string at the end of the URL?
No, no query string involved.
Maybe there is set-cookie so they don’t cache?
Thank you both, sdayman and user605. My issue is resolved, now and things are nice and fast.
For anyone else who is confused by “response contains a cookie” and how it results in CF-Cache-Status:MISS, this is what I’ve learned:
(1) A request can contain cookies, and they are shown in the request headers as “cookie” (which makes sense)
(2) However, a response header can contain “set-cookie”, which actually means it contains a cookie, even though it appears to just be a directive to set one (which doesn’t make as much sense)
Removing the PHP-based setting of a cookie solved it.
@mbourne, on which Cloudflare plan is that domain?
Thanks for the feedback, though in that case it is relatively unlikely the cookie was the reason.
Unless you have specifically configured it (which you can do only on the higher plans) cookies wont affect caching.
Thanks for responding, Sandro. Well, removing the “set cookie” was the only change I made before I started getting HITs.
I understand that and it would seem logical that this is the reason, but, for example, set-cookie is sent from the server to the client, so if that made a difference it would mean the request already hit the server which would render Cloudflare’s caching pointless.
The feature is was referring is “Bypass Cache On Cookie” and achieves that very result, bypassing the cache when the client (not the server) sends a particular cookie, but that feature is available only on business plans and needs to be configured.
For these reasons I somewhat doubt that it got fixed only because of that (missing) response header, but I do understand your perspective.
Ah - I see what you mean now. So my conclusion was wrong - the “set-cookie” in the headers I posted before is just that - a directive to set a cookie, not an actual cookie in the header. Is that correct?
Set-Cookie is the actual cookie, but it is not the cookie sent from the browser to the server but the other way round, from the server to the browser when the cookie actually gets set.
This topic was automatically closed after 30 days. New replies are no longer allowed.