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).
Related
As I understand, this is how browser caching works. Assuming, a far future header has been set to let's say a year and foo.js is set to be cached. Here are some scenarios:
First visit to the page, server returns 200 and foo.js is cached for a year.
Next visit, browser checks the cache but has to check the server if foo.js has been modified. If not, server returns a 304 - Not Modified.
User is already on the page (and foo.js is in cache) clicks a link to go to another page, browser looks at the cached version of foo.js and serves it without doing a roundtrip to the server and returns a 200 (Cached).
User is already on the page (and foo.js is in cache) and for some reason hits F5/Reload, browser checks the cache but has to do a round trip to the server and check if foo.js has been modified. If not, server returns a 304.
As you can see, whenever a page is refreshed, it will always have to do a trip to the server to check if the file has been modified or not. I know this is not a lot and server will only return the header info but a round trip time in some cases are extremely important.
The question is, is there a way I can avoid this since I'm already setting the expiration for the files. I just want it to always fetch it from the cache until the expiration has expired or replace the file with something else (by versioning it).
From what I understand, pressing F5/Ctrl-R is browser specific action, thus leaving the control to browser.
What if the user clears the cache before clicking another action? So, even if there was HTTP specification to forcefully use cache in F5, there's no guarantee that you'll be able to achieve your need.
Simply configure and code to cache wherever maximum possible and leave the rest to user.
It looks like, when you navigate to a page (that is entering an address in URL bar or clicking a link), resources are fetched from cache without a HEAD request to server. But when you refresh the page it does the HEAD request ans so the RTT.
This looks more clear in Network tab of IE's Developer Tools. If you see the initator column, it says navigate for the first case and refresh for CTRL+R or F5.
You can override the F5 and CTRL+R behavior by adding an event listener on them and doing a window.location = window.location and prevent the default behavior by event.peventDefault or something similar. This will cause page navigation instead of refresh.
Also, I didn't test the case when the cached resource has actually changed on server. If that turns out to be a problem, you can solve it by version numbering of resources and generation of HTML with URLs pointing to the latest version of the resource (kind of like cache-manifest problem with HTML5 offline applications).
EDIT: This however doesn't solve the problem if user clicks on browser's refresh button; onbeforeunload event may help in that case.
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 have a number of sites using Kohana's session handler set to use database sessions. Everything works fine until I turn on Resource Tracking in Safari's Web Inspector. After enabling resource tracking, the page refreshes (normal), but then if I refresh the page twice I get logged out. From what I can tell, the session id/key changes therefore it has no session. Upon watching the storage/cookies area, I can see the session id cookie change immediately.
I haven't been able to reproduce similar behaviour in any other browser, including Chrome (Webkit).
Any ideas what might be causing this?
This appears to be fixed in Safari 5.1, so in other words, no longer an issue. Still love to know why it was happening (in case there's another issue), but for now it's resolved.
I'm working on a web application developed classic asp. It has logout button on the top menu which basically does the following actions
Session.Abandon()
Redirect to Index.asp, where users can login again.
After logging off users return to index.asp. But if users click back button the browser, they go to previous page. I don't want this to happen. I want a message saying that they are already logged off.I have implemented following steps
1.Add Response.Expires=-1 and Response.CacheControl="no-cache" at the top of each page.
2.On each page i'm checking session object to see it is not empty. If empty i'm creating a message saying that they are already logged off and need to log in again.
Now when users click back button after logging off, instead off showing logged out message, i get "Web page expired" message on IE8. I see the same behavior when users click back button on some page while logged in.
Any ideas how i can implement this better.
Thanks.
You can't stop users pressing back. A common scenario to work around this is that POSTs target a server page that displays no output but redirects to a new location instead (where the results can be seen).
There are additional non caching declarations that sometimes help:
Response.Expires = 0
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "no-cache"
I did read some time ago (hence inability to find link) that setting an expires to -1 can cause some browser to ignore it rather than have it expire immediately.
Even adding these extra cache controls won't stop some browsers from caching some things some of the time. FF quite often ignores a forced cache reload by the user, so you are in the browser makes hands to a certain extent.
Regarding your "Web page expired" message, this is (as mentioned) the result of the browser trying to stop you from resubmitting POST data (and potentially duplicating what you last did). The best way to get around this, and solve a number of other common UI issues on forms is to POST back to the same page, then if/when the action is completed, using a response.redirect to the same page, maybe with a URL encoded message to say "all done successfully". This allows your users to refresh and helps with the back button issue as most browsers now don't store properly redirected pages in their history.
Greetings,
Here's the problem I'm having. I have a page which redirects directly to another page the first time it is visited. If the user clicks 'back', though, the page behaves differently and instead displays content (tracking session IDs to make sure this is the second time the page has been loaded). To do this, I tell the user's browser to disable caching for the relevant page.
This works well in IE7, but Firefox 3 won't let me click 'back' to a page that resulted in a redirect. I assume it does this to prevent the typical back-->redirect again loop that frustrates so many users. Any ideas for how I may override this behavior?
Alexey
EDIT: The page which we redirect to is an external site over which we have no control. Server-side redirects won't work because this wouldn't generate a 'back' button for in the browser.
To quote:
Some people in the thread are talking about server-side redirect, and redirect headers (same thing)... keep in mind that we need client-side redirection which can be done in two ways:
a) A META header - Not recommended, and has some problems
b) Javascript, which can be done in at least three ways ("location", "location.href" and "location.replace()")
The server side redirect won't and shouldn't activate the back button, and can't display the typical "You'll be redirected now" page... so it's no good (it's what we're doing at the moment, actually.. where you're immediately redirected to the "lucky" page).
I think the Mozilla team takes a step into the right direction by breaking this particularly annoying pattern. Finding a way around it somehow defies the purpose, doesn't it?
Instead of redirecting on first encounter, you could simply make your page render differently when a user hits it the first time. Should be easy enough on the server side, since you already have the code that is able to make that distinction.
You can get around this by creating an iframe and saving the state of the page in a form field in the iframe before doing the redirect. All browsers save the form fields of an iframe.
This page has a really good description of how to get it working. This is the same technique google maps uses when you click on map search results.
I'm strongly in favor for the Firefox behaviour.
The most basic way to redirect is to let the server send HTTP status code 302 + Location header back to the client. This way the client (typically a browser) will not place the request URI into its history, but just resend the same request to the advocated URI.
Now it seems that Firefox started to apply the bevaviour also for server responses that try redirections e.g. by Javascript's onload event.
If you want the browser not to display a page, I think the best solution is if the server does not send the page in the first place.
Its possibly in aide to eliminate repeated actions.
A lot of ways people do things is
page 1 -> [Action] -> page 2 -> redirect to page 2 without the action parameters.
Now if you were permitted to click the back button in this situation and visit the page without the redirect, the action would be blindly re-performed.
Instead, firefox presumes the server sent a redirect header for a good reason.
Although it is noted, that you can however have content delivered after the redirect header, sending a redirect header ( at least in php ) doesn't terminate execution, so in theory, if you were to ingnore the redirect request you would get the page doing weird stuff.
( I circumvent this by the fact all our redirects are done via the same function call, where i call an explicit terminate directly after the redirect, because people when coding assume this is how it behaves )
In the URL window of firefox type about:config
Change this setting in firefox
browser.sessionstore.postdata
Change from a 0 to 1