strategy-cluster.html example fails after reloading in IE6 and IE7

[ahocevar]

 http://n2.nabble.com/Fwd%3A-IE-cluster-protocol-error---%27status%27-is-null-or-not-an-object-td1836423.html#a20830502

The example only works in IE when loading it for the first time. Reloading it, or using it when it is still in the browser cache, will cause it to fail with a "status is null or not an object" error in the handleResponse method of Protocol/HTTP.js. This has to be investigated further. What makes IE finally break is that the priv property of the response is null, but until now I have no idea why.

[igrcic]

Replying to ahocevar:

 http://n2.nabble.com/Fwd%3A-IE-cluster-protocol-error---%27status%27-is-null-or-not-an-object-td1836423.html#a20830502 The example only works in IE when loading it for the first time. Reloading it, or using it when it is still in the browser cache, will cause it to fail with a "status is null or not an object" error in the handleResponse method of Protocol/HTTP.js. This has to be investigated further. What makes IE finally break is that the priv property of the response is null, but until now I have no idea why.

Yes var request = resp.priv; in Protocol.HTTP on line 322 is null. I remember I added one extra check on line 324, to see if request is truthy if(request&&(request.status>=200&&request.status<300))

Since then I dont get this error thrown in IE, obviously. I know its not the right way to do it, but as I dont know much about background of the error, its workable temporary solution for me.

[ahocevar]

Ok, after some investigation it seems that IE fires an onReadyState event with readyState=4 immediately (i.e. before the creation of the request object is finished) if the requested document is already in the cache. The fix Ivan tried is almost correct, it just has to be done one line above to avoid a FAILURE response code in the Protocol:

    handleResponse: function(resp, options) {
        var request = resp.priv;
        if(request && options.callback) {
        ...

Fortunately, the onReadyStateChange will still be fired again properly with readyState=4 after the request object is created, so the handleResponse method will be called again, and this time with the priv property set.

Patch to come in a few minutes.

[tschaub]

I'm curious to see if we can address this a bit further upstream. Please check the upcoming patch to see if this solves the issue.

[tschaub]

make return available before sending data

[ahocevar]

Tim: I am convinced that your patch is the right way to do it. Just tested in IE, and it resolves the issue.

Just one concern: I think this breaks applications where people issue requests with async=false when they expect to work with request.responseText or request.responseXML right after returning from request.issue.

[ahocevar]

Replying to ahocevar:

Just one concern: I think this breaks applications where people issue requests with async=false when they expect to work with request.responseText or request.responseXML right after returning from request.issue.

Not only applications will break, but also parts of OpenLayers. Format.KML for instance, which does the following:

    fetchLink: function(href) {
        var request = OpenLayers.Request.GET({url: href, async: false});
        if (request) {
            return request.responseText;
        }
    },

Maybe we could use the setTimeout only when async==true. Attaching a patch which does that.

[igrcic]

Tried the patch, works in IE7! Thank you Andreas

[tschaub]

delay for cached docs in ie

[tschaub]

Tests need to be modified to accommodate this change. We only have one case where we are testing send with an asynchronous call. The latest patch tests with a delay.

Please commit if you confirm tests pass in IE.

[ahocevar]

Tests also pass in IE. Thanks Tim for the important contributions to this fix, thanks Ivan and Tim for the review.

[ahocevar]

(In [8816]) fixed a caching issue with asynchronous requests in IE. r=igrcic, tschaub (closes #1896)