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.
Related
I am not an expert on fiddler but trying to figure out what is wrong with my configuration.
I have a website on domain example.com which i am hosting on an iframe on another site which is on domain example.org.
example.com has login controls and on successful authentication i have to open a new tab. Chrome and Firefox are working fine, but IE behaves as if i clicked refresh button on Login click.
Traced with Fiddler, but i am not sure what should i be looking looking out for, please help.
Request Header:
POST https://example.com/Login/VerifyUserDetails HTTP/1.1 Accept: application/json, text/javascript, */*; q=0.01 Content-Type: application/json X-Requested-With: XMLHttpRequest Referer: https://example.com/ Accept-Language: en-US Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko Host: example.com Content-Length: 37 DNT: 1 Connection: Keep-Alive Cache-Control: no-cache
{"userEmail":"abc#gmail.com"}
Response Header:
HTTP/1.1 200 OK Cache-Control: public, no-store, max-age=0 Content-Length: 65 Content-Type: application/json; charset=utf-8 Expires: Wed, 29 Jun 2016 00:07:28 GMT Last-Modified: Wed, 29 Jun 2016 00:07:28 GMT Vary: * Server: Microsoft-IIS/7.5 X-UA-Compatible: IE=Edge X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Content-Security-Policy: frame-ancestors 'self' https://example.org*.example.com *.example.org; X-Powered-By: ARR/2.5 X-Powered-By: ASP.NET Date: Wed, 29 Jun 2016 00:07:38 GMT
{"IsADUser":false,"IsActiveUser":false,"PasswordSetError":""}
Please guide.
Although i think someone with expertise on this might find this interesting that the immediate next call after authentication is a redirect to which i see below response:
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
Turns out I need to add the domain that I am hosting in the iframe in IE trusted sites. It works. :) So, it was not a cross domain scripting issue, I am using the w3c recommended content security policy.
Just to add to it, I had to add p3p policy to the site. I had the domain in my IE trusted site list so it worked for me with above solution. But, one external user didn't have our domain in whitelist and he kept getting 401 errors.
I searched a lot and have to add a valid p3p token for it to work. Not any p3p policy, but a valid one unlike other suggestions that I found on the net.
I have an EXTJS application on http://extjs.domain1.com and serverside Laravel application on http://domain2.com.
I noticed that some browsers (like Safari or old IE) has set very strict cookies privacy settings by default. In the end, if browser don't accept cookies, my laravel_session cookie cannot be saved and the user cannot log in.
My idea is to display a proper information for the user, only if the cookies cant be saved in current browser. So, on my ExtJS's app launch, after it's initialized, I'm sending a custom Ajax GET request to the server (from domain1.com to domain2.com) and the server returns me a Set-Cookie header with sample cookie.
If the cookie is saved, it would mean that the browser's settings are OK (please correct me if I'm wrong).
Now, my cookie's name is Time.
The ajax response in firebug looks like this:
HTTP/1.1 200 OK
Date: Wed, 03 Feb 2016 12:19:32 GMT
Server: Apache
Set-Cookie: Time=1454511121; expires=Wed, 03-Feb-2016 14:54:11 GMT; Max-Age=9279; path=/; laravel_session=LONG---SESSION---KEY; expires=Wed, 03-Feb-2016 14:19:32 GMT; Max-Age=7200; path=/; httponly
Cache-Control: no-cache
Access-Control-Allow-Origin: http://extjs.domain1.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Origin, Content-Type
Access-Control-Allow-Credentials: true
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/json
I have tried many combinations.
Every time the
console.log(document.cookie)
returns an empty string.
The "Time" cookie is visible in firebug > Cookies and it is NOT httponly.
The "expires" of "Time" is greater than my current browser/computer date.
I tried setting "path" of cookie to '/' or empty string.
I tried setting the "domain" of cookie to ".domain1.com", "extjs.domain1.com".
What am I doing wrong? The document.cookie is always empty, but firefox shows me that there is a non-httponly cookie.
I noticed a little difference in chrome.
The response Set-Cookie looks like this:
Set-Cookie:Time=1454511121; expires=Wed, 03-Feb-2016 14:54:11 GMT; Max-Age=7715; path=/;
Set-Cookie:laravel_session=LONG---SESSION---KEY; expires=Wed, 03-Feb-2016 14:45:36 GMT; Max-Age=7200; path=/; httponly
There are two Set-Cookie headers, but I read that it should not be a problem.
In Chrome I can see the cookies in Dev tools > Network tab > xhr request > Cookies tab. I cannot see a cookie in Dev tools > Resources > Cookies > extjs.domain1.com
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...
I send ajax post request to server and respond with 302 redirect. All browsers follow this redirect except IE. I see in Network tab of IE dev tools that 302 response is received.
Also jQuery .fail(function(jqXHR, textStatus) {...}) callback return the following data in jqXHR:
[object Object]{readyState: 0, status: 0, statusText: "error"}
Which is strange because status is not 302.
Testing on IE 11.
EDIT
Response headers:
Response HTTP/1.1 302 Found
Date Tue, 27 Oct 2015 12:24:47 GMT
Server Apache/2.4.10 (Debian) PHP/5.6.7-1
X-Powered-By PHP/5.6.7-1
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
X-Redirect http://mysiteaddress.com/somepage/
Set-Cookie PHPSESSID=123; path=/; HttpOnly
Content-Length 0
Keep-Alive timeout=15, max=96
Connection Keep-Alive
Content-Type text/html; charset=UTF-8
EDIT2 I guess it's Yii2 framework-specific bug. Client script must handle X-REDIRECT header, but can't do this in IE. See: http://www.yiiframework.com/doc-2.0/yii-web-response.html#redirect()-detail.
It's Yii2 specific bug/behaviour when you use yii\web\Response::redirect() method.
Everything seem to work fine if you return code 200 instead of proper redirection code 302.
See:
http://www.yiiframework.com/doc-2.0/yii-web-response.html#redirect()-detail and
https://github.com/yiisoft/yii2/issues/9670
(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.