XMLHttpRequest in IE 7



  • I have written something using AJAX (please, no flames!) that works in Firefox 2, Opera 9, and IE 6 - but NOT in IE 7. Basically, when the user selects something from one select form element (onChange = foo();), Javascript functions sends a HTTP GET request to a Perl script, which queries a database and sends back results, which populate the other form element.

     As I said, it works OK in all browsers that I have, except IE 7. And there it's not totally broken. It will work the first time the user selects something, but not the other. Refreshing the page, you can try the other choice (only 2 for testing), and you get the same thing: it works ONCE.

     Since this seems to be an IE 7 only thing - and I know the object is being created, since it does work once - I was wondering if anyone has experienced or heard of anything like this. I still believe it's my code, but since it works in all other browsers... I can post the code upon request.

    Thanks, R. Flowers

     



  • My apologies if you're already doing this and I'm simply restating the obvious. :)

    This sounds like the browser is trying to re-fetch the "page" from the cache, which is a typical issue with GET request Ajax. The standard workaround is to generate a random number or integer time stamp in your Javascript, and tack that on as a throwaway query string variable, like this:

    http://somesite/ajaxservice.cgi?meaninglessnumber=38610418

    The different value each time will make the browser think it's a different page, and it'll make another request. You might also be able to achieve the same effect by spitting out some HTTP headers that specify it shouldn't be cached, but I haven't tried that approach.



  • Thanks for the response. I did indeed try that, along with sending a "Cache-Control: no-cache" header from the Perl server-side script.

    However, I have at least found a workable solution for testing. In IE's options, you can set it so that it uses the IE 6 behavior for AJAX, i.e., an ActiveX component. (I'm not explaining it very well; here: http://msdn2.microsoft.com/en-gb/library/ms537505.aspx ).

    This is intended to be an intranet application, with the browser choice locked down, so that's fine for now.  



  • [quote user="db2"]You might also be able to achieve the same effect by spitting out some HTTP headers that specify it shouldn't be cached, but I haven't tried that approach.[/quote]

    Don't. It doesn't really work for IE, in the testing I've done (I also work on AJAXy blago-web-netty applications) at least.

    Enforcing modified browser options may cause trouble down the line for other applications; I really would suggest tacking on the throw-away value like db2 suggested.



  • [quote user="Volmarias"][quote user="db2"]You might also be able to achieve the same effect by spitting out some HTTP headers that specify it shouldn't be cached, but I haven't tried that approach.[/quote]

    Don't. It doesn't really work for IE, in the testing I've done (I also work on AJAXy blago-web-netty applications) at least.

    Enforcing modified browser options may cause trouble down the line for other applications; I really would suggest tacking on the throw-away value like db2 suggested.
    [/quote]

    I guess that might be one way out given the stories about aggressive caching that IE7 employs.

    My first try would however involve a GET request that is different on every invocation.



  • What about changing to POST? Since POST is counted as non-repeatable, the results should not be cached as the GET does (that is why you get that little message about rePOSTing data when you refresh a page that you got from a POST form submission).

    -REW 



  • [quote user="rewind"]

    What about changing to POST? Since POST is counted as non-repeatable, the results should not be cached as the GET does (that is why you get that little message about rePOSTing data when you refresh a page that you got from a POST form submission).

    [/quote]

    That's an interesting suggestion. Although I found my work-around, I will try that when I get back to work Monday. Thanks. 



  • Please share your findings. I am experiencing same problem in the same circumstances, only i am using clasic asp on the server side. Like said, i too generated unique query strings, http headers all for vain. Also, on the same mechine this works just fine with firefox.

    Changing to post? can anyone with same situation report of any kind of advancement with this?



  • I will share the steps that I have taken, and they seem to cover most bases.

    First, a random value appended to your regular URL (to force fresh data) seems to help, and can't hurt. Thus, instead of:

        req.open("GET","my_program.cgi?somevalue=39",true);

    we would have:

        req.open("GET","my_program.cgi?somevalue=39&bogusvalue=325290238",true); 

     

    A typical xmlHttpRequest is implemented something like this:

            req.onreadystatechange = processReqChange;
            req.open("GET", url, true);
            req.send(null);

    I found  a blog entry somewhere (if I could find it, I would give credit) that advised re-ordering those 3 steps:

            req.open("GET", url, true);      
            req.onreadystatechange = processReqChange;
            req.send(null);

    or - maybe it's the other way around. I'm not sure. My code is on my computer at work.

    Last, I ran into the problem of conflicts when trying to use the same xmlHttpRequest object for varying tasks. If the object is still waiting for a server response, you will encounter an error if you try to re-use it again for another request. Either be sure to check the object's readyState before using, or create enough objects to do the tasks you need.



  • I've always used POST for my requests, and haven't had any caching issues.



    Why even use GET at all? It doesn't have any advantages.


Log in to reply