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.
Related
I'm using Internet Explorer 7 and Firefox/15.0.1. I developed a web application in J2EE.
In application,if i click any hyperlink it is sending only one request in Firefox,chrome.
I checked it using Firebug and the logs also.
The same way i tested in IE7,It is showing 2 times logs for a single request.
Is it a bug in IE7? How to fix it?
Every time IE7 sending two requests.. Any tool to track the HTTP request?
You can install IE Developer Toolbar to debug JavaScript in IE
Mainly the problem with two forms i'm using...
that is a form with in other form. which caused IE to show exotic behaviour.
HTML is not well formatted. I changed it. it is working as expected.
I have a problem with saving session data with IE9. When users login the session is saved correctly. Now, if they browse through the application, the application stores the pagehistory into the session data (I use this for the applications back button). Unfortunately IE9 does not always save this data into the session (sometimes it does and sometimes it does not). It works perfectly with other browsers.
If you are using PHP, try adding a header like:
//vfranchi - necessary to IE8, so it won't throw a warning
header('P3P:CP="This site does not contain a P3P policy."');
I think this is related to IE8 not saving cookie information when the site doesn't have a explicit privacy policy. I had the same problem and that fixed for me.
Remember this statement needs to be before any output just like session_start()
Solved it by switching off IE8 compatibility mode.
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.
I'm trying to enable HTTPS support in my app before the October deadline, but the JavaScript call FB.getLoginStatus never calls my callback.
I'm using OAuth2.0, and I added the channelUrl parameter.
This works fine in HTTP mode.
FireFox is reporting no security warnings during page load, all files appear to be correctly served via HTTPS, and all references in the html/js code appear to be updated to point to https:// instead of http:// (including the channelUrl file).
What else can cause the getLoginStatus to not return?
I have a strange caching issue going on with IE9. The other day I set up a new website on my IIS server that was NOT running HTTPS, unfortunately I accidentally setup a redirect to HTTPS if you entered in HTTP. So because I didn't have it setup, the webpage didn't load becasue no HTTPS was running. I subsequently fixed the issue in IIS, and when I hit the web page with browsers other than IE9 it seems to work fine. For some reason in IE9 it just wont load the webpage (I think it is still trying to hit it on HTTPS).
I have tried clearing all temp files/cookies etc.., rebooted and still no luck. The only way I have been able to get IE9 to hit the web page was by going into 'F12 Developer Tools' and turn on "Always refresh from server" under the 'Cache' menu option. As soon as I turn that on it starts working. I turn it off and I cannot hit the website again.
Is there some other cache for IE9 that I don't know about that doesn't get cleared through normally processes?
I have a problem similar with yours. I fixed it by adding a random number in URL. Just like this: .....Index.asp?random=3283237431, hope this can help you.