I've been at this for a few days now and am becoming more and more frustrated. I'm getting inconsistent offline functionality results across Chrome, FF, and I've just started using Safari.
I'm developing a sandbox app using Asp .Net MVC 3. Below is the structure of my application:
Controllers/CarController
Views/Car/Edit
Views/Car/EditOffline
Views/Car/Index
Out of the 3 views, Index is the only that has the manifest attribute defined. Index is the view that is initially requested. Below is the contents of my manifest:
CACHE MANIFEST
FALLBACK:
Car/Edit Car/EditOffline
#Version 1
Upon the first request of Index, the browser creates 3 entries in the Application Cache. They are:
localhost/Sandbox/Car, type = master
localhost/Sandbox/Car/EditOffline, type = fallback
localhost/Sandbox/Offline., type = manifest
The way I've been simulating offline behavior for all 3 browsers is by explicitly stopping IIS. After, Index has been requested. I shut down IIS and make a request to the Edit action. The result is is EditOffline gets served up. Now, when I the Index view again, I get a 404 error, but why? I thought the browser would've have served up the cached version of that page? When I re-requeset the Edit view (while still offline), I also get a 404 error, but why? The browser served the EditOffline view previously so why do I get a 404 now? In FF, I've gotten it to work as expected a few times, but I made no code changes. I explicitly deleted the offline cache, restarted the server, re-requested the index view and it magically worked.
It looks like your initial request is for http://localhost/Sandbox/Car, is that the URL you then get a 404 on? The manifest works by URL but it knows nothing about default pages or any other server configuration. So http://localhost/Sandbox/Car is a different page to http://localhost/Sandbox/Car/Index as far as the application cache is concerned. The view involved is largely irrelevant to the caching other than that you've included a reference to the manifest file in it.
Related
I have developed cloud application in ASP.NET. After every deployment, the portal either shows white screen or shows older version of the application.
Any suggestions would be highly appreciated.
I have already tried:
1) Updating JS version in each deployment (white screen issue was resolved by this)
2) Recycling Application Pool
3) IIS manager->http response header->set common headers->enable web content
4) Restarting IIS(8.5) after each deployment
However, none of these have worked. The application works fine in incognito mode of Chrome browser but not the regular one.
However, none of these have worked. The application works fine in incognito mode of Chrome browser but not the regular one.
As far as I know, if your brower has accessed your web application once, it will store the cache in client side.
If you modify the content and add the response header, it will not re-send the request to the server, it will use the cache page.
To aovid this, the only way is clear the browser's cache or use Ctrl+F5 to refresh the page.
Then if your reponse haeder contains the no-cache next time, the browser will not store the cache again.
I've added Roxy Fileman to my project and tied it in to CKEditor. It's a standard Durandal project with an MVC controller for routing and a web api controller for ajax/json data calls.
A typical working URL for a web api call in my app is http://localhost:63093/api/DurandalApi/getAssessmentQuestionnairePushMenu?id=1
When I try and upload a file from within CKEditor, I get:
Request URL:http://localhost:63093/fileman/index.html?type=image&CKEditor=ckeditor&CKEditorFuncNum=1&langCode=en
Request Method:POST
Status Code:405 Method Not Allowed
Remote Address:[::1]:63093
If, however, I directly go to http://localhost:63093/fileman/index.html?type=image&CKEditor=ckeditor&CKEditorFuncNum=1&langCode=en in my browser, the file upload works perfectly and I can then browse to the image from FileMan inside CKEditor.
The network tab in chrome dev tools indicates that the successful upload is done using this URL: http://localhost:63093/fileman/asp_net/main.ashx?a=UPLOAD which is significantly different to the one that CKEditor attampts to use, but that may be because in the second example, index.html is already loaded?
I'm not completely up to speed with what's going on, but the fact that the same URL works perfectly outside of Durandal if I go directly to the URL seems to indicate the FileMan plugin is working just fine and all permissions are set accordingly. Furthermore the CKEditor config is also fine as it can see the images I upload in the directory, but for some reason it's unable to "post" from within CKEditor (which is embedded in a standard Durandal view).
I'm trying to read up on routing to see if I need to do some kind of exception mapping in Durandal to tell it to let the 3rd party .ashx handler deal with the POST request and I'm not even sure if this problem is indicative of Durandal getting in the way or something else. Any suggestions gratefully received!
Ah. All has become clear. This is a half and half answer really as it doesn't really solve the problem, but equally the problem doesn't really exist!
The issue is that Roxy Fileman does NOT use the CK Editor inbuilt "upload" tab that is in the popup. It expects the user to "browse server" only and use the "add file" link in Roxy instead.
I was confused by the instructions, but now I understand!
I have a weird problem, javascript files are cached in IIS,
What I have done till now
Disabled caching on my website in IIS
Disable cache on chrome dev tools
Adding timespan at url in page to prevent any chaching
Doubled check to see if the files on disk are updated and they were updated
But my scripts and css not updating from latest version on disk, until I do IISReset
Your attempt to break the cache is short circuited by the fact you are getting the cached version of the content page with the old timestamp, meaning you never request the JavaScript page with the new timestamp until something else forces the content page to reload.
You can check this by using the same cache breaking scheme on the content page itself in addition to the JavaScript page.
This is not a recommended solution as you will bypass cache altogether for the content page.
Every answer I've seen for this problem has worked sometimes and other times not. If I get a solution, I'll post it.
This is basically identical to this SO questions which has not been answered: Offline Web App not caching on Firefox but ok on Chrome
I'm experiencing the same problem and I'll provide a bit more information because it might help someone trying to figure out the arcane mysteries and traps of trying to implement cache manifest.
The problem: hit page reload/refresh and the page should reload from the offline cache, but it doesn't.
It works fine in Chrome 23: when I disconnect from the internet and refresh the page, it loads fine and the console shows Application Cache NoUpdate event.
However, Firefox 15.0.1 shows me my 404 page.
Troubleshooting (Firefox): Go to Firebug and click on DOM, then applicationCache. The status shows 0, which means uncached (the page has not been stored offline).
Troubleshooting (Firefox): Go to Firefox Options -> Advanced and look at Offline Web Content and User Data. It shows that my domain is using 1.4MB of data for offline use. (This is a good place to check for whether your page has been cached).
Troubleshooting (Firefox): Open a new tab and go to about:cache. Here you should see a heading for Offline cache device. Here you can see the Cache Directory, which is where your offline cache files are saved. If you click on List Cache Entries you'll see the files in your offline cache manifest.
There are 2 things that I find strange here: 1) is that when I click on any of the files on the list it goes to a blank page that says "Cache entry information The cache entry you selected is not available." However, the files do exist and are not blank in the Cache Directory 2) Although all of the files from the cache manifest are listed, the page that I'm calling is not listed here (in Chrome DevTools it shows up in the manifest as Master: it is cached automatically even though it's not explicitly listed in the cache manifest file).
Here's what I see when I'm online: With a cold (empty) cache, when I load the page the console shows the checking, downloading, progress, and cached events, but the cache status is uncached. Basically, the cache files are downloaded, but they cannot be accessed. Firebug DOM applicationCache says: 0 items in offline cache (this contradicts what is shown in about:cache and Options -> Advanced). The status is 1, which means idle. When I look at the Net tab in Firebug when online, it shows a GET request for the page with a 200 OK response. The Expires setting shows Wed Dec 31 1969, which I think means that the page will always be fetched. The other files show a 304 Not Modified response, which means they are being loaded from the browser cache, not the offline cache (the analogous response from Chrome for these files is 200 OK (from cache), which means they are loaded from the offline cache, not the browser cache).
When I'm offline: With the "uncached" cache the GET request fails and it loads the offline fallback 404 page with a 200 OK (BFCache) response.
It seems the offline cache is downloaded because it physically exists on disk and progress events are shown in the console, but Firefox never fires the cached event, so some of the resources have not downloaded successfully. The files are all png, js, or php format, so no crazy file formats. Chrome downloads the exact same files into the cache without a problem. I've also tried mobile Safari and it successfully reloads the page from the offline cache.
Are there any known issues with Firefox not caching certain file types? I use the .html.php extension on some of my files. I also generate the manifest dynamically using a php file, so it is only getting files that exist and it hashes them to detect changes and update the manifest.
Next Steps: I will try a bare-bones manifest to see if I can get it to work, then add files one by one to see which file triggers the error. Perhaps Firefox doesn't like the fact that I'm dynamically generating the cache manifest instead of manually updating a static file?
I've learned a lot about the arcane intricacies of cache manifest, but I'm more of a hacker than a computer expert. Has anyone else experienced this quirkiness with Firefox?
The beginning of the page:
<!DOCTYPE html>
<html manifest="/directory/manifest.php">
and then the manifest.php is just
header('Content-Type: text/cache-manifest');
echo "CACHE MANIFEST\n";
etc. etc. It uses RecursiveDirectoryIterator to get all the files in the directory (except the cache itself, which is included by default).
I’m investigating a bug in my MVC3/.NET 4 site which runs on IIS7.5 with integrated pipeline that only manifests itself when accessed using IE6.
The process in pseudo is:
Browser requests Page A; server sets
a Session[] value and responds with
the page.
Enter data onto Page A and
http post the form back.
Server tries to get value out of Session[]
previously set in (1) but returns
null >> but only in IE6, 8(.
In IE7, IE8, IE9, Firefox 3.6, Safari 5.0.3, Chrome 10 the same code works without change.
In my global.asax code I put a Session_Start handler in and noticed some strange behaviour.
In IE6 this handler is fired upon every request made BUT the Session.SessionID value remains the same. All the other browsers mentioned above only have this handler fire the first time they make a request. So for IE6 even though the session ID is the same each time it is called it would seem that the fact that it is “start”ing a new session seems to have the effect of clearing the data for the Session ID and starting it again hence the null value.
One theory I had was that because some items on the page (images etc…) would be accessed with HTTP whilst the page itself is HTTPS could be why IE6 is causing this behaviour (new session per protocol perhaps?) but I turned off the code that forced HTTPS to be used on the page in question, so all requests would be HTTP. Unfortunately the same behaviour is still observed on IE6.
After a lot of Googling I found things that said stuff like underscores in the domain can cause this (no underscores present in mine), ensure IE6 is accepting cookies (my test VM was set like to accept all session cookies).
Finally in a last ditch attempt:
I turned every privacy and security setting I could find in IE6 to as low as it would let me
I added my test site (http://<my machine name>/MyApp) to the list of trusted sites
Clear temporary internet files and cookies
Still I get the same issue. I have thought of a way to fix it that involves not using Session for this case but I would rather not make changes due to IE6 when it works in all of the other browsers including decendant versions of IE.
Edit: Some further testing on another page and when accessed via IE6 the session value is correctly retrieved after being stored by access to another page. More specically:
Working Page - Search:
Do a search, results are display and
criteria are stored in session.
Click on one of the results to view it, details page gets criteria in order to build querystring for breadcrumb trail link.
Failing Page - 2 stage login:
Go to 1st stage login page, enter username and password, assuming correct store encrypted http only cookie value with username in.
Redirect to 2nd stage login page, store 3 index values (List<int>) into a "secret" word in Session
Enter 3 characters from a secret word and post back.
Access session to get 3 index values - get nothing.
The reason for the failure is evident due to the observations made in the more generic description above. This is just getting weirder by the minute (and more frustrating).