Recently I started noticing my JS and CSS files are not getting cached in chrome and always reloaded from server.
But images and fonts are getting loaded from cache.
Below is the server response for javascript file. Did something change in chrome behavior? this is not happening in FF or IE!
Please help!
HTTP/1.1 200 OK
Accept-Ranges: bytes
ETag: "282766-1400285984000"
Date: Wed, 18 Nov 2015 18:27:05 GMT
Cache-Control: public, max-age=31536000
Last-Modified: Sat, 17 May 2014 00:19:44 GMT
Content-Type: application/javascript
Vary: Accept-Encoding
Content-Encoding: gzip
Connection: keep-alive
Transfer-Encoding: chunked
On a mac using this version of chrome: Version 54.0.2840.87 (64-bit) I have found that javascript files are not cached if the site you are accessing is untrusted (ie: https to a site/localhost using a self signed certificate)
You have set your cache to maximum (even for javascript files):
Cache-Control: public, max-age=31536000
365 days in seconds = 31,536,000 seconds
1 month in seconds = 2,629,743 seconds
1 week in seconds = 604,800 seconds
1 day in seconds = 86,400 seconds
Chrome is working with resources another way, when you have opened developer tools. (Both can be changed in settings.)
Please share what server are you using to be able to help with specific configuration...
Related
I'm trying to get Chrome to cache my Javascript (the HTML includes a version number as a cache buster). So the idea is that if the version does not change I shouldn't need to reload 1MiB of Javascript but Chrome always seems to reload it anyway. I think I have the server returning the correct headers.
My html looks like:
<script type="application/javascript" async src="/index.js?version=123"></script>
Response Headers
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: public
Content-Encoding: gzip
Content-Language: en-US
Content-Type: application/javascript
Last-Modified: Wed, 23 Jan 2019 15:09:36 GMT
Vary: Origin
Vary: Accept-Encoding
Date: Thu, 24 Jan 2019 00:52:23 GMT
Transfer-Encoding: chunked
I have the "disable Cache" un-selected in the Network tab and in the devTools settings I've un-selected "Disable cache (when devTools is running)
I can see that my fonts are cached in the network tab of devTools but my index.js still loads all 1MiB
It seems to be because I'm using https but my dev box server doesn't have a certificate. If I disable https and use http it does cache the Javascript.
Using JavaScript, I'm calling a rest API that returns the following headers:
Cache-Control:max-age=60
Content-Length:20
Content-Type:application/json; charset=utf-8
Date:Mon, 15 Aug 2016 21:01:56 GMT
Server:Microsoft-IIS/10.0
Vary:Accept-Language
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
This get cached by Chrome/Firefox/Safari correctly on subsequent calls, but in Edge nothing gets cached. If I stop sending the Vary:Accept-Language header, then it gets cached, but the result is that if a different language is passed to Accept-Language then it returns the (wrong) cached content.
Am I missing something to make Edge cache it?
I am actually getting an Ajax Response Text from a PHP Server. Suppose the response text comprises of 20 characters.
(e.g. echo "asdhfgyd dhrjtjsjtjr";)
This equals roughly (20/1024) KB.
I'm using a mobile web application to get this reponse text using standard Ajax XMLHttpRequest. However when i measure the data usage by the mobile app due to only that one single ajax response text, it uses nearly 3 KB. This is what i'm not understanding, what is causing this additional data usage, can you please help me out on this.
Additionaly: I confirm that this is the only part of the app that makes internet usage, the others are offline features.
The data you see in the response text is only the body of the response. The other bytes will most likely have been taken up by the headers.
For example here is a response I would expect to receive when calling an API:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?XFxwc2ZcSG9tZVxEb2N1bWVudHNcR2l0SHViXFNvdXJjZVxDaGVyaXNoQXF00XJpc2guQXBpXGFwaVxjaGlsZFxsaXN0?=
X-Powered-By: ASP.NET
Date: Fri, 13 Mar 2015 09:02:35 GMT
Content-Length: 577
[{"result":"FooBar"}]
The Chrome Network Tab in the Web Developer Tools shows that a bunch of my AJAX requests are taking 16027.8 days to complete. This is... not how long they are taking.
I can replicate this on multiple machines, and in both development and production environments. This happens for all Dojo AJAX requests that are happening onload. It doesn't happen for other webapp or 3rd party requests (like signin AJAX or facebook).
What is going on? Is our server somehow screwing this up? Is it a bug in chrome dev tools (it almost certainly is, right?), and if so, is there anything that can be done about it? It makes the visual waterfall pretty useless, as you can imagine.
Edit: Upon new information, this seems to be a common problem with IBM Websphere Commerce sites. What about the server or code could be causing this? Look here for examples:
http://www.ikea.com/us/en/catalog/categories/departments/kitchen/#
http://www.lavieenrose.com/webapp/wcs/stores/servlet/LVER_10052_10001_-1
http://www.ferragamo.com/shop/en/usa
Edit 2: This issue is fixed in the newest version of Chrome.
This issue is not related to web framework or server. Issue affects Chrome browser version 31.0.1650.57.
Now issue is fixed and will be delivered with next stable channel update. Fix diff
If you need fix urgently, you can update to dev channel version. Instructions
See this issue for more details.
Very odd. Able to recreate on Chrome 31.0.1650.57 on OSX Mavericks as well. Tested w/ ikea link, noticed Chrome reported 16028.7 days, 41ms latency for resource /us/en/iows/tealium.
Charles proxy shows these headers:
HTTP/1.1 304 Not Modified
Content-Type: application/json
Last-Modified: Mon, 18 Nov 2013 18:34:51 GMT
Cache-Control: public, max-age=7200
Date: Sat, 23 Nov 2013 00:32:26 GMT
Connection: keep-alive
Vary: Accept-Encoding
The proxy app (Charles) reports no such odd time - it shows 40ms.
The lavieenrose.com link caused Chrome to report time of 16028.7 days as well... that seems to be in common.
Charles shows:
HTTP/1.1 200 OK
Date: Sat, 23 Nov 2013 00:46:37 GMT
Server: IBM_HTTP_Server
Last-Modified: Tue, 19 Jun 2012 13:05:34 GMT
ETag: "5c487f-1a15-4c2d2f01a0380"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1738
Content-Type: application/x-javascript
My conclusion is this isn't a server response or headers issue. I think this is a Chromium or WebKit dev tools issue.
Here's HEAD of the dev tools JS object that represents the http request which rendered by the Network tab:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/front_end/NetworkRequest.js
I'm wondering about the math in set endTime():
set endTime(x)
{
if (this.timing && this.timing.requestTime) {
// Check against accurate responseReceivedTime.
this._endTime = Math.max(x, this.responseReceivedTime);
} else {
// Prefer endTime since it might be from the network stack.
this._endTime = x;
if (this._responseReceivedTime > x)
this._responseReceivedTime = x;
}
},
No answers just yet, but perhaps someone with more insight into what WebKit/Chromium DevTools may see this...
(Note: This is a follow up to my question Can jQuery.getJSON put a domain's cookies in the header of the request it makes? and covers the XSS case of Setting a cookie in an AJAX request?)
I've been told I'm unable to set cookies to be read by other domains that are not subdomains of the current domain using $.cookie(..., ..., {domain: ...}). But in a comment on a response to my last question, #zanlok said "The server's reply, however, can definitely set a cookie" and it got two upvotes.
So I thought I'd try using a service which was created for the explicit purpose of setting cookies called Freebase's "touch" API. The call looks like:
$.getJSON("http://api.sandbox-freebase.com/api/service/touch",
{}, // URL parameters
afterCookieIsSetCallback); // Callback function
Looking in FireBug at the response header it's like this:
Date Wed, 24 Nov 2010 03:35:28 GMT
Server Apache
X-Metaweb-Cost [...]
Etag [...]
Expires Wed, 24 Nov 2010 03:35:29 GMT
Cache-Control no-store
Vary Accept-Encoding
Content-Encoding gzip
Set-Cookie mwLastWriteTime=1290569730|10325_9202a8c04000641f80000000199eff96|sandbox; expires=Thu, 25-Nov-2010 03:35:28 GMT; Path=/
Last-Modified Wed, 24 Nov 2010 03:35:28 GMT
Content-Length 134
Content-Type text/plain; charset=utf-8
X-Cache MISS from cache01.sandbox.sjc1.metaweb.com
Connection keep-alive
X-Metaweb-TID cache;cache01.sandbox.sjc1:8101;2010-11-24T03:35:28Z;0001
So there's definitely a Set-Cookie in there, and the script runs the response handler. Yet the cookie is not present in the request headers for later JSON requests this script makes to .sandbox-freebase.com.
(By contrast, simply typing the touch api URL into the address bar and loading it that way does set the cookie for future requests. That applies even in other tabs.)
This seems to be a deviation from a prior "expected behavior", because there was a toolkit published by MetaWeb circa "2007-2009" which seemed to think such an approach could work:
http://www.google.com/codesearch/p?hl=en#v099O4eZ5cA/trunk/src/freebase/api.js&q=touch%20package:http://mjt%5C.googlecode%5C.com&l=340
Without knowing much about it, I'm wondering if it was a recent change that Firefox adopted and then WebKit followed suit. Perhaps the one mentioned here:
http://trac.webkit.org/browser/trunk/WebCore/xml/XMLHttpRequest.cpp#L856
So is there any canonical documentation on this particular issue?
The AJAX call you are making, is making a request to a domain outside of the domain of the top level url(the url in the address bar). This results in it being a 3rd party cookie, by default Internet explorer won't persist a 3rd party cookie. Meaning that the cookie will come back in the Set-Cookie header on the first request, but subsequent requests that you make to that server will not have that cookie sent in the request.
Like you said, if you go directly to the url in your browser it works. This is because in this case it's a first party cookie.
In order for IE to accept 3rd party cookie's the server that is sending the SET-COOKIE header on it's response, must also have a P3P Policy Header set.
Here is an example, when you navigate to CNN, you will notice one of the requests it makes is to a domain name of b.scorecardresearch.com, scorecardresearch is dropping a tracking cookie, but this cookie is considered a 3rd party cookie. So in order to make it work they had to also in include a p3p header, see headers below:
HTTP/1.1 200 OK
Content-Length: 43
Content-Type: image/gif
Date: Thu, 02 Dec 2010 19:57:16 GMT
Connection: keep-alive
Set-Cookie: UID=133a68a4-63.217.184.91-1288107038; expires=Sat, 01-Dec-2012 19:57:16 GMT; path=/; domain=.scorecardresearch.com
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID OUR IND COM STA OTC"
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
Cache-Control: private, no-cache, no-cache=Set-Cookie, no-store, proxy-revalidate
Server: CS
If you were to copy this header and add it to the response, you would notice that the cookie's start working,
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID OUR IND COM STA OTC"
It's best that you craft a P3P header specific for your business, but the above should work for testing purposes.
If I correctly understand you, you are wondering why the server sends Set-Cookie only on the first request. If that is true, then it's by design - take a look here:
http://en.wikipedia.org/wiki/HTTP_cookie
Set-Cookie is like a setter - the server sends it for the browser to cache it locally. It can send every time, but there is no need to do that, so it will send it again only if it needs to change the value stored locally.
Browser, on the other hand, will send Cookie header every time with the contents set by the last issued Set-Cookie from the server.