So I understand how a manifest file works and I am getting all the resource I need from the network tab in Chrome's developer console. When I turn off my server and run the webpage offline it works. But after the first refresh the page has the error HTTP Error 404. The requested resource is not found. I check what file was missing and it was the text/html that was the webpage and when I check the header
Request URL:https://offline1.exactbid.net/
Request Method:GET
Status Code:404 Not Found
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:offline1.exactbid.net
Referer:https://offline1.exactbid.net/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36
Response Headersview source
Connection:close
Content-Length:315
Content-Type:text/html; charset=us-ascii
Date:Fri, 28 Jun 2013 23:09:27 GMT
Server:Microsoft-HTTPAPI/2
UPDATE
So it seems that after I refresh the page everything I had in the appcache disappeared. Does it have to do with the Cache-Control:max-age=0, I read some stuff online and it says that it is similar to no-cache. is that correct?
It seems that when I try to start the page offline it says that the cache is obsolete
OK after experimenting I figure the what but not the why. I was using ASP. net for the web page and I did not have a site master page so I was declaring it in my default.aspx directly. But after I changed my code to have a site master page and declares the manifest file there it fixed the problem. When I am offline and refresh the manifest download fails (suppose to happen) and does not label the appcache as obsolete. I hope this helps someone. If someone knows the why I would mark that as the answer until then this is it
Related
In a commercial web application that uses POST requests frequently, it was necessary to perform history.go(-1) to trigger back navigation. As may others has experienced, I am getting -
Confirm Form Resubmission ERR_CACHE_MISS
error in Chrome. However, same works just fine in Firefox (this is no a duplicate, please read on).
It is true that using POST requests to render content is the reason leading to above problem (without using Post/Redirect/Get design pattern).
However, while looking for an alternative solution, it was observed that in certain web sites / apps it is possible to navigate back in Chrome (cache hit) where as in some sites it fails. I have inspected all the HTTP headers from successful sites and it looks like HTTP headers are not making any difference.
Could it possibly be the browser acting differently based on the SSL certificate used by the web application or what could be the reason for back navigation working in certain web sites?
Example working web applications :
http://gmail.com/ - Enter some random email. Click next. Enter incorrect password multiple times and use browser back button to navigate back.
https://support.hostgator.com/ - Enter some random text in search box (do this several times). Use browser back button to navigate back.
POST request used in failing web application :
POST /post3.jsp HTTP/1.1
Host: 192.168.1.111
Connection: keep-alive
Content-Length: 18
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: https://192.168.1.111
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.99 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: https://192.168.1.111/post2.jsp
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Identified that in Chrome back navigation fails in above work flow, unless SSL Certificate used in HTTPS communication is a valid, trusted certificate.
If you are using a self signed certificate, add the CA certificate as a Trusted Root Certification Authorities and everything should work as expected.
I am working on a JavaScript application, where I want to read data from an XML file and post them into a HTML file.
My code is producing the following error:
Request URL:http://myServer/dirs/dir/scripts/xml_data.xml
Request Method:POST
Status Code:405 Method Not Allowed
Request Headersview source
Accept:*/*
Accept-Encoding:gzip, deflate
Accept-Language:en,en-US;q=0.8,da;q=0.6
Connection:keep-alive
Content-Length:13
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Host:myServer
Origin:http://myServer
Referer:http://myServer/dirs/dir/inWork.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36
X-Requested-With:XMLHttpRequest
Form Dataview sourceview URL encoded
node:xnode-24
Response Headersview source
Allow:GET, HEAD, OPTIONS, TRACE
Cache-Control:private
Content-Length:5309
Content-Type:text/html; charset=utf-8
Date:Thu, 12 Feb 2015 21:06:08 GMT
Server:Microsoft-IIS/8.0
X-Powered-By:ASP.NET
Based on this posting I created a new 'Handler Mapping' and I also adjusted the 'Handler Mapping' for 'StaticFile' to allow the methods: GET,HEAD,POST,DEBUG,PUT,DELETE.
The IIS server was restarted but still the error message appears and the only methods allowed are: GET, HEAD, OPTIONS, TRACE.
So, there is some configuration file or 'Handler Mapping' overriding my settings, or I simply did not consider.
Any suggestions on how to tell the IIS to accept my settings for this XMLHttpRequest?
Today I was investigating on something with Fiddler, when I noticed that, when I launch Google Chrome, I have always 3 HEAD requests to some domains which seem to be randomly chosen.
Here is a sample :
HEAD http://fkgrekxzgo/ HTTP/1.1
Host: fkgrekxzgo
Proxy-Connection: keep-alive
Content-Length: 0
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
Accept-Encoding: gzip,deflate,sdch
Do you have any idea of why Google Chrome behaves this way ?
Thanks guys
This is Chrome checking to see if your ISP converts non-resolving domains into your.isp.com/search?q=randomnonresolvingdomain
See https://mikewest.org/2012/02/chrome-connects-to-three-random-domains-at-startup
This algorithm seems unusable with forward proxy servers. Browser definitely asks for random page and proxy definitely returns some page -- error (50x), masked error (50x or 40x) or nice "you are lost" page with HTTP code 200 .
I have an offline-enabled website that uses a cache manifest. I'm finding with Chrome that it is serving an older version of my stylesheet, even if I do a "Empty Cache and Hard Reload"
If I append ?foo=bar to the URL of the page or the CSS, the new version of the CSS is delivered.
My manifest is dynamically generated at /Manifest/Index (e.g. )
If I open the page in Chrome and check out Fiddler, I see a single request is made to the web server, as expected:
# Result Protocol Host URL Body Caching Content-Type Process Comments Custom
6 200 HTTP 10.6.4.67 /Manifest/Index 2,476 no-cache Expires: -1 text/cache-manifest; charset=utf-8 chrome:5484
Here is the header detail for /Manifest/Index
GET /Manifest/Index HTTP/1.1
Host: 10.6.4.67
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko)
Chrome/23.0.1271.97 Safari/537.11
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
HTTP/1.1 200 OK
Date: Thu, 10 Jan 2013 17:59:42 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
X-AspNetMvc-Version: 4.0
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Content-Type: text/cache-manifest; charset=utf-8
Content-Length: 2476
Can anyone tell me why on earth a CSS file reference in this cache-manifest isn't updating unless I append a cache-busting querystring variable to the CSS? Especially even if I empty Chrome's cache??!
More info:
If I update the cache-manifest, I can open up Chrome's console and see the App Cache events fire:
Document was loaded from Application Cache with manifest /Manifest/Index
Application Cache Checking event
Application Cache Downloading event
Application Cache Progress event (0 of 61) http://x.x.x.x/Content/themes/base/jquery.ui.progressbar.css
Application Cache Progress event (1 of 61) http://x.x.x.x/Content/themes/base/jquery.ui.accordion.css
Snip
Application Cache Progress event (54 of 61) http://x.x.x.x/Content/Site.css
I do notice that some of the items in this list, like Site.css, are underlined. Why is that?
Thanks,
Chris
Clear your appcache in Chrome using: chrome://appcache-internals/ and remove it there.
Also you need to rebuild your manifest file each time you change the files contained in it for the new copied to be downloaded.
This is accomplished by using a random number in your manifest and generating it when files are edited.
For example in node.js
function generateCacheManifest(...) {
manifest = 'CACHE MANIFEST';
manifest += '#version ' + Math.random();
...
}
Yes the random number can be in a comment. The point is that Chrome will check the cache manifest and when it sees that nothing has changed it will not fetch the updated files.
Change a file, change your manifest, it's that simple.
I see quite a lot posts with regards to this topic but still can't find a solution for my case.
I want to leverage the caching of the images for our web site (hosted in IIS 7.5). I did configure the caching through "http response headers" menu in IIS management console and it works for images with "absolute" src like <img src="images/logo.png" alt="Logo"> but it doesn't work for images with JSON source e.g. <img alt="Image" src="http://myhost.com/site/Services/Service.svc/images/im0002/thumb" > that is set dynamically in the ajax callback.
Detailed request/response headers:
Request URL:http://myhost.com/site/Services/Service.svc/images/im0002/thumb
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:/
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Host:myhost
Referer:http://myhost/site/Default.aspx
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11
Response Headersview source
Content-Length:1392
Content-Type:image/jpeg
Date:Fri, 27 Jul 2012 07:37:25 GMT
Server:Microsoft-IIS/7.5
X-Powered-By:ASP.NET
Any information about how to fix that is highly appreciated.
Convert your image into Base64 or anything similar. It will be a string by then, no longer a url.