I have a large json data object (over 300K uncompressed, 40K gzipped) which is used on every page of my internal system. I want to fetch it every 15 minutes. In this time user will probably visit tens of pages of my system.
The HTTP Response headers in Firebug look like:
Cache-Control max-age=899, public
Connection Keep-Alive
Content-Encoding gzip
Content-Length 44017
Content-Type text/html; charset=iso-8859-2
Date Tue, 04 Dec 2012 16:21:45 GMT
Expires Tue, 04 Dec 12 17:36:45 +0100
Keep-Alive timeout=15, max=99
Last-Modified Tue, 04 Dec 12 17:21:45 +0100
Pragma no-cache
Server Apache
Set-Cookie user_auth=xxx; expires=Wed, 12-Dec-2012 16:21:45 GMT; path=/; domain=example.com
Vary Accept-Encoding
X-Genaration-Time 0.13282179832458 sec.
X-Genarator vCRM 3.1 (c) Veracomp S.A.
X-Powered-By PHP/5.3.3-7+squeeze14
The cache headers are set to 15 minutes in future, but neither Chrome nor Firefox caches it.
The Firebug says this about cache:
Data Size 44017
Device disk
Expires Thu Jan 01 1970 01:00:00 GMT+0100
Fetch Count 5
Last Fetched Tue Dec 04 2012 17:21:45 GMT+0100
Last Modified Tue Dec 04 2012 17:21:45 GMT+0100
It seams the Expires header is ignored, but why?
This sould not mattery, but I better write, that the content type is text/html, so the server can gzip it, but in reality the content is JSON.
I am using Prototype.js to request this. I set the request header:
Cache-control: max-age=900
Prototype.js does not add any cache buster parameter to the url.
I am using PHP with Zend_Framework to set serve the response.
What am I doing wrong?
Problem solved.
As #Victor pointed out, I had the "Pragma: no-cache" header set. The header was somehow set by PHP. I worked with our webserver admin and we had managed to unset the header with Apache.
Still it was not enough. Our framework sets cookies with every page refresh and I could not turn it of. Browsers did not want to cache the requests which set cookies. We had to unset the Set-Cookie headers too.
Finally this two unsets allowed us to enable cache:
<LocationMatch "(?i)/url/we/want/to/be/cached/.+">
Header unset Pragma
Header unset Set-Cookie
</LocationMatch>
Related
I'm setting some cookies and appropriate cache-headers (to not cache) while responding a requested .gif file. According to Cloudflare documentation:
If the Cache-Control header is set to "private", "no-store", "no-cache", or "max-age=0", or if there is a cookie in the response, then Cloudflare will not cache the resource.
I know that there's a default caching of .gif files but I can see 'CF-Cache-Status:MISS' in response-header. So, the issue is not caching but that the cookie is not being forwarded to client from my backend server.
Response Header sent by my backend server:
Cache-Control:no-cache, no-store, must-revalidate
Content-Type:image/gif
Content-Length:12345
Date:Wed, 12 Jul 2017 13:50:29 GMT
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Pragma:no-cache
Set-Cookie:user=randomuser; Max-Age=7776000; Expires=Tue, 10-Oct-2017 13:38:45 GMT
Response Header sent by Cloudflare:
Cache-Control:no-cache, no-store, must-revalidate
CF-Cache-Status:MISS
CF-RAY:xxxxxxxxxxxxx-XXX
Connection:keep-alive
Content-Type:image/gif
Content-Length:12345
Date:Wed, 12 Jul 2017 13:50:29 GMT
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Pragma:no-cache
Server:cloudflare-nginx
Vary:Accept-Encoding
As can be seen the 'Set-Cookie' header is not forwarded to my clients by Cloudflare.
Although this issue got resolved when I created a page rule and set Bypass Cache for the resource-url.
Can anyone guide me what am I missing or additional headers to send from my backend server so that 'Set-Cookie' is also forwarded through Cloudflare?
I’m using a custom framework for bundling stylesheets and scripts. (I.e., these are dynamically generated responses, not static files.)
The response for the initial request, when the response is being generated for the very first time, includes these headers:
HTTP/1.1 200 OK
Cache-Control: public, no-transform, max-age=31536000
Content-Type: text/css; charset=utf-8
Content-Encoding: gzip
Last-Modified: Mon, 25 Aug 2014 18:15:50 GMT
Vary: Accept-Encoding
Date: Tue, 09 Sep 2014 16:19:36 GMT
Content-Length: 3126
Now that the response above has been generated and cached by the server, subsequent requests for the same stylesheet are responded to with these headers:
HTTP/1.1 200 OK
Cache-Control: public, no-transform, max-age=31536000
Content-Type: text/css; charset=utf-8
Content-Encoding: gzip
Last-Modified: Mon, 25 Aug 2014 18:15:50 GMT
Date: Tue, 09 Sep 2014 16:20:00 GMT
Content-Length: 3126
Ignoring the new Date value, the headers are identical with the obvious exception of the missing Vary header.
One nasty consequence that I’ve seen in the wild is that if the very first response generated for a given asset is not compressed (due to the corresponding client not supporting compression), then the server caches that non-compressed response and serves it for all subsequent requests to all clients.
Any idea how to have the server retain the Vary header for cached responses?
I’m using HttpCacheability.Public for these responses. I can avoid the issue by using HttpCacheability.Private instead, but I’d prefer to allow the server and proxies to cache responses.
Some reading has led me to believe that IIS can’t do “kernel caching” if you vary by encoding. But I’m not sure if that means I can’t cache on the server at all or if it just prevents a special kind of server-side caching.
Update:
I was originally using the following to set the Vary header:
response.AppendHeader("Vary", "Accept-Encoding");
I tried a different method of specifying it:
response.Cache.SetVaryByCustom("Accept-Encoding");
That caused Vary to never be emitted. Not even on the very first response.
As a last resort, I’m also considering using:
response.Cache.SetNoServerCaching();
That causes the Cache-Control header to still specify public (so that proxies can still cache), but prevents the server from caching.
In line with the update I made to the question, I tried yet another way of specifying the Vary header:
response.Cache.VaryByHeaders["Accept-Encoding"] = true;
…And it fixed the problem. Responses now retain the Vary header across requests from multiple clients and are also cached by the server.
Images loading from akamai not caching in the browser.
when looking through developer window i see this in the header:
Accept-Ranges bytes
Access-Control-Allow-Cred... true
Access-Control-Allow-Orig... *
Access-Control-Request-He... X-Requested-With,Content-Type,Accept,Origin
*
Cache-Control max-age=0, no-cache, no-store
*
Connection Keep-Alive
Content-Length 114069
Content-Type image/jpeg
Date Tue, 02 Jul 2013 14:20:52 GMT
Etag "01bd6c5172ce1:0"
Expires Tue, 02 Jul 2013 14:20:52 GMT
Last-Modified Wed, 26 Jun 2013 00:11:58 GMT
Pragma no-cache
Server Microsoft-IIS/7.5
Set-Cookie BNI__BARRACUDA_LB_COOKIE=00000000000000000000000097f7ab4200005000; Path=/;
HttpOnly
*X-CFLO-Cache-Result* TCP_NC_MISS
X-Powered-By ASP.NET
What can i do to forces Akamai Servers to change the images header so it can be cached in the browser.
Generally Akamai preserve Cache-Control header. If you don't setup Cache-Control your application/web server, is very recommendation that you do. But, if you want create specific policies using Akamai, you will need to enable the "Set Browser Cache Control Headers".
I pushed some changes to one of our images to web server, but I found it's not updated on IE and firefox web browsers due to browser caching, since I saw the browsers didn't even request for image from server.
I have two choice. One is to update the image file name and re-deploy. The other is to let our users' browsers think the image exipires.
I haven't set anything in header or in code, here is the response:
Content-Length 32042
Content-Type image/png
Last-Modified Wed, 09 Nov 2011 18:41:50 GMT
Accept-Ranges bytes
Server Microsoft-IIS/6.0
X-Powered-By ASP.NET
Date Fri, 09 Dec 2011 01:26:03 GMT
Connection keep-alive
So I am wondering how soon it can expire?
Ideally, if your last-modified time stamp changes, everything should take of by itself. You can set up cache-control http://blogs.msdn.com/b/rahulso/archive/2006/02/02/suppress-caching-of-certain-mime-types-like-gif-jpg-etc.aspx to avoid it.
I'm using valid expires and no-cache headers for my static files and they stay cached for as long as I keep browsing, but when I close my browser and use it back after a while I see the static files loading again, even when not refreshing with ctrl (+ shift) + r
I'm using Firefox, cache size set to 250MB and I don't let it remove any private or cached data.
Headers:
Accept-Ranges: bytes
Cache-Control: max-age=29030400, public
Content-Length: 142061
Content-Type: image/png
Date: Tue, 08 Dec 2009 19:18:43 GMT
Expires: Tue, 09 Nov 2010 19:18:43 GMT
Last-Modified: Sun, 18 Jan 2009 18:33:48 GMT
Server: Apache/2.2.14 (EL)
Which version of Firefox? Is the server sending Etags for the static files? You can view details about Firefox cache by going to the address about:cache and poking around. That will give you an idea of what Firefox is caching.
Update: After looking at your header tags, it seems as if the max-age value is set to a date that is way in the past and that is overriding the the value being set in the Expires header. See the HTTP 1.1 protocol definition at: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3.
If a response includes both an Expires
header and a max-age directive, the
max-age directive overrides the
Expires header, even if the Expires
header is more restrictive. This rule
allows an origin server to provide,
for a given response, a longer
expiration time to an HTTP/1.1 (or
later) cache than to an HTTP/1.0
cache. This might be useful if certain
HTTP/1.0 caches improperly calculate
ages or expiration times, perhaps due
to desynchronized clocks.
You will have to modify your Cache-Control header being sent by the server.