cache-control max-age

[trx]

Hello Community,
A question abut the cache-control setting in the request/response headers. Do they have to match? I have set the max-age in the response (IIS config) to X days, but when the request header is showing max-age set to 0. Is that expected? I would think NOT.

Thank you in advance.

Regards,
TRX

[pmeenan]

I assume you mean the response header, not request, right? Any chance you have a link to a result with the headers? Sounds like the IIS setting isn't being applied for some reason.

[trx]

I have attached an image of what I mean.
Does both the response/request headers "max-age" must match?

This is a second hit on the same page.

[pmeenan]

Are you doing a force-refresh/reload of the page? They have different meanings on the request and response so no, they don't need to match.

[trx]

Thanks. So when I run a webpagetest, it always fails on the category of not setting any static files to have an expiration or max-age. I would of thought with my setting in IIS "Cache-Control: public, max-age=xyz", would do the trick, but I see that it is not the case. Any ideas on why this is happening or how to get this accomplished so webpagetest will mark it as NOT an F?

Regards,
TRX

[pmeenan]

Do you have a link to a test result? That will help in identifying the specific requests it is having a problem with and show the headers that WebPagetest is seeing.

Thanks,

-Pat

[trx]

Hello Pat,
I have re-tested and webpagetest.org grades it an A for http://www.qad.com.

Couple of questions:
1) Should the "max-age" in the request be zero, when hitting the same page a 2nd time with an f5/refresh?

NOTE: Please refer to the screen shot of the request header.

Thanks.

Regards,
TRX

[pmeenan]

Yes, in a forced refresh it is normal for the client to request max-age: 0

That is the browser's way of telling the server and any intermediate proxies that it needs the current version of the file and not to serve a version that was cached somewhere along the path. A reload of the page behaves very differently from actually navigating to a page for a second time. WebPagetest's repeat views are done by closing the browser and then loading the page again in a new instance (browsers have an in-memory cache that behaves differently from the normal caching as well which is why we close the browser out).

Thanks,

-Pat

[trx]

Thanks! What would be the best tool to find out and see that a specific image/static file is being served from the local cache?

Regards,
TRX

[pmeenan]

Run WebPagetest and look at the repeat view test result? You can also use HttpWatch (for IE) or Chrome's developer tools, both of which should tell you which resources came from local disk cache.