Member Avatar for Bliksempie

Hi everyone,

I have an issue with IE7 not responding as it should after a log-in to a website I built for a client. This same problem also affects the add to basket or add to wish-list functionality, the checkout process, and all other Ajax requests. Here is a breakdown of what happens...

1. User clicks on the "log-in" link.
2. Log-in page opens (new page).
3. User logs in (Ajax submission of credentials, page supposed to reload, but does not in IE7)
4. Log-in block is supposed to show user details now, but does not, because page did not refresh.
5. User presses Control+F5, and page now shows user logged in.

Now the user continues...

1. User adds item to basket (ajax request firing, and popup says "added to basket" but basket is not refreshed.
2. User presses Control+F5, basket is refreshed.

So, as far as I can tell, this seems to be sessions/ajax related, but I am not sure where to check - this works wonderfully well for all browsers except IE7.

Any advice please?

Thank you!

Kobus

  • 2 Contributors
  • 5 Replies
  • 203 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by MooGeek

Dani AI

Generated

Short diagnosis and practical fixes based on the symptoms you described (and ’s Fiddler observations): IE7 will happily serve cached responses for identical GET/XHR calls unless the server instructs otherwise, so an AJAX login or “add to cart” GET can appear to succeed but leave the page showing stale HTML. (support.microsoft.com) Another, independent cause is server-side session locking (PHP’s default session handler locks the session file while a request runs), which makes concurrent AJAX requests from the same browser queue or see inconsistent session state — call session_write_close() as soon as you’re done mutating the session. (php.net) Finally, IE7’s low per-host connection limit can change request ordering/timing and amplify these effects. (stevesouders.com)

Quick, actionable steps to try (apply one at a time and re-test):

  • Stop relying on a plain GET + reload. Force a fresh fetch or update the DOM from the AJAX response. Easiest client-side cache-buster (vanilla XHR):

    var url = '/applets/addtocart.php?prodID=46659&_=' + Date.now();
xhr.open('GET', url, true);
xhr.send();

    Appending ?_= prevents IE from returning a cached result; jQuery’s cache:false does the same. (stackoverflow.com)

  • Prefer POST for state-changing actions (add-to-cart/login) or ensure the server returns explicit no-cache headers. Example PHP headers to prevent caching:

    header('Cache-Control: no-cache, no-store, must-revalidate');
header('Pragma: no-cache');
header('Expires: 0');

    These are the supported ways to stop IE from serving stale XHR responses. (support.microsoft.com)

  • If the app uses PHP sessions, call session_write_close() immediately after you update session variables so other AJAX calls won’t block or race:

    session_start();
$_SESSION['user_id'] = $id;
session_write_close();
// now return JSON / continue processing

    This releases the session lock so concurrent requests behave properly. (php.net)

Note: programmatic location.reload(true) is unreliable across browsers; prefer the cache-buster navigation pattern or update the page fragment directly. (mdn2.netlify.app)

Troubleshooting checklist: reproduce in a controlled environment, watch server logs to confirm IE actually hits the server, inspect response headers in Fiddler, try converting the problematic AJAX GETs to POSTs, and add session_write_close() in the login/add-to-cart handlers. That approach will root out whether the issue is client caching, server locking, or a timing/connection artifact (IE7). is right: IE quirks make this fiddly — but the above sequence usually isolates and fixes it.

Recommended Answers

All 5 Replies

Member Avatar for Bliksempie

Using Fiddler, I see nothing out of the ordinary - the scripts are fire as they should be, session IDs are not overwritten, but somehow the Ajax requests simply does not refresh the elements they are supposed to. Only after pressing Control+F5 does it work. The HTTP headers return 200, not 304 so I don't think it is a caching issue in the script - perhaps a caching issue in the client's browser or client's network settings?

Member Avatar for Bliksempie

Further testing indicates that even though the header returns 200, the script fires "too fast" it sends an HTTP/200 header, but does not actually run (I made an alert to popup if you click the add to cart button) and the alert more often does not display than it does. It displays around once every 15 times or so. Very weird...

Member Avatar for Bliksempie

Sorry for the spamming of my own topic, but I am just trying to provide more information as I get it...

Closer inspection in fiddler indicates that the original request is sent to the server via Ajax, but the server sometimes does not respond appropriately. Here is an excerpt:

GET
200 OK (text/html)

This should return this:

GET
200 OK (text/html)

Now - this sometimes happens, and sometimes not, more often not.

Our internet connection is very slow today. Perhaps this is related? I figured (it seems like) FF just waits long enough for a response, and IE7 does not. Perhaps it is related to our internet connectivity? Client and I are not using same ISP, but what we do have in common is the same telecoms provider Telkom (affectionately known as Hellkom in South Africa) and the hosted server. The server is hosted at the data center of a large cellular provider in South Africa, but I believe Telkom still does the "last mile" of all internet traffic in South Africa (unless I missed the lifting of this historic change in SA democracy).

Member Avatar for Bliksempie

So - the social.msdn forums are getting somewhere with this problems - various MVP's browsing my topic and giving hints to try and test. I will provide some information here if the problem gets solved, for other interested parties.

Member Avatar for MooGeek

IE just sucks, we all know that. It's a fact :D

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.