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".
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?
When I make a request to a Google Api font (e.g. https://fonts.googleapis.com/css?family=Roboto:400), the last-modified header is always changing to the current time.
Caching doesn't work as a result and the file has to be downloaded every load. Is there a reason for this? Should I download the file and host it on my server?
Should I download the file and host it on my server?
Absolutely not, because the content of the CSS files is dynamic and has different content for every user agent. This is because not all browsers support all font formats. Some require WOFF/WOFF2, others require EOT, TTF or SVG. By downloading and serving the file statically you will break font support for all other browsers.
Interestingly though, I do not see a last-modified header at all:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: text/css
Alt-Svc: clear
Alternate-Protocol: 443:quic,p=0
X-XSS-Protection: 1; mode=block
Server: GSE
Expires: Mon, 14 Dec 2015 09:14:21 GMT
Timing-Allow-Origin: *
Cache-Control: private, max-age=86400
Date: Mon, 14 Dec 2015 09:14:21 GMT
Content-Length: 222
Connection: close
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
The Expires header indeed is the same as the Date - so it expires at the time the ressource was loaded. The max-age option of Cache-Control though has higher precedence. So the file should be cached by the browser for 1 day.
I am working on a web application which has user management in place. I find a concerning issue in firefox related to Work Offline. Following are the steps describing the scenario:
User logs in to the application
User performs some action and logs out of the application
If the user now enables Work Offline mode in firefox, he/she can use browser back to access the last page. However, this page is supposed to be secure.
In my opinion this is a data security issue as any other user can apply this technique to fetch valuable information of the last user.
I have used cache control headers to communicate to the browser that HTML content should not be cached. Following are the response headers used:
HTTP/1.1 200 OK
Date: Tue, 05 May 2015 10:39:30 GMT
Server: Apache/2.4.9 (Unix) OpenSSL/0.9.8za
Cache-Control: no-cache, no-store
Expires: Wed, 31 Dec 1969 23:59:59 GMT
Content-Type: text/html;charset=UTF-8
Content-Language: en
Vary: Accept-Encoding
Content-Encoding: gzip
X-Frame-Options: SAMEORIGIN
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
I have used
Cache-Control: no-cache, no-store
Expires: Wed, 31 Dec 1969 23:59:59 GMT
I have noted this vulnerability in applications like Facebook. Is this resolvable? Thank you.
In my MVC3 project I have the following class-level attributes set on some of my controllers:
[OutputCache(Location = System.Web.UI.OutputCacheLocation.Server, Duration = 14400, VaryByParam = "*")]
Duration = four hours.
I used VaryByParam = "*" as there are differing parameters for the controller's action methods, instead of VaryByParam = "none" - Is this the correct use?
In IIS, on the server level and in all the web.config files for my sites, I set the static caching to eight days.
Observing the headers in Fiddler, when I go to a search result page, I see the following:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Expires: -1
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 3.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Thu, 15 Aug 2013 17:21:32 GMT
Content-Length: 148842
For my site scripts js files:
HTTP/1.1 200 OK
Cache-Control: max-age=691200
Content-Type: application/x-javascript
Last-Modified: Thu, 15 Aug 2013 05:35:35 GMT
Accept-Ranges: bytes
ETag: "10906a447999ce1:0"
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Thu, 15 Aug 2013 17:21:32 GMT
Content-Length: 2999
And for css:
HTTP/1.1 304 Not Modified
Cache-Control: max-age=691200
Last-Modified: Wed, 07 Aug 2013 21:31:28 GMT
Accept-Ranges: bytes
ETag: "f08ce079b593ce1:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Thu, 15 Aug 2013 17:21:33 GMT
Using Google's PageSpeed affiliate (http://www.webpagetest.org/) I was able to get up to around 90/100 on my pages - page load time is about 4 seconds, the report shows .47s optimized - see the confusing results here . When I playback the video on WebPageTest of Original vs. Optimized, my original finishes in 2.5s (and has a lower speed index) and optimized in 4.7s.
Google's PageSpeed Insights suggests to optimize CSS delivery. I am already serving up CSS asynchronously.
As I am hosting on AWS, I cranked up the juice on the instance to one of their most powerful server instances. Page load times were about the same as my regular instance.
So I am confused by the first result up top: Cache-Control: no-cache . Have I not implemented caching correctly, and if not, what am I missing?
Good Day.
I'm trying to figure out a caching issue. We are currently using a CMS with built in caching. We can then delete the cached copy via the control panel and the uncached page will be served until we cache that page again.
Long story short, we know that a either a proxy server or load balancer was put in place, and we think that it is caching the pages as well as the CMS. Our specific issue is that when we un-cache the page in the CMS, it's taking 15 minutes (timed) to show up un-cached (even after using different browser, clearing the browser cache, etc.), when prior to the network appliance being introduced, the un-cached page would show up immediately. Unfortunately we don't have any historical response headers saved anywhere.
When we believe that the page is being cached by the proxy/lb, the Response header is returning:
HTTP/1.1 304 Not Modified
Server: Apache/2.0.59 (Unix) JRun/4.0 mod_ssl/2.0.59 OpenSSL/0.9.8k PHP/5.2.6
Last-Modified: Fri, 03 Aug 2012 13:29:12 GMT
Etag: "92fe-18f7-837ada00"
Accept-Ranges: bytes
Keep-Alive: timeout=5, max=100
Content-Type: text/html
Content-Encoding: gzip
Connection: Keep-Alive
Date: Mon, 06 Aug 2012 13:49:40 GMT
X-Cntnt-Length: 6391
When it's not being cached by the CMS, the response headers are:
HTTP/1.0 200 OK
Date: Mon, 06 Aug 2012 14:03:59 GMT
Server: Apache/2.0.59 (Unix) JRun/4.0 mod_ssl/2.0.59 OpenSSL/0.9.8k PHP/5.2.6
X-Powered-By: PHP/5.2.6
Set-Cookie: blah-blah-blah
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Mon, 06 Aug 2012 14:04:04 GMT
Pragma: no-cache
Connection: close
Content-Type: text/html
I guess my question is, can Apache2 be configured to return both HTTP 1.0 and 1.1 ?
I know the Etag indicates a cached page, and believe it's not available in HTTP/1.0.
Thanks for any insights.