SCRIPT7002: XMLHttpRequest: Network Error 0x2ee4, Could not complete the operation due to error 00002ee2.
In the developer tools Network Panel, I notice that the Result is stated as (Aborted). All other browsers work (chrome, firefox etc.)
00002ee2 is a timeout error code. If you run Fiddler, do you see the request actually hit the wire? If so, how long does it take for a response to be returned?
Is the request "interesting" in any way (e.g. to an Intranet site, or requiring NTLM authentication, or anything like that)?
Related
In Chrome Developer Tools, I'm getting a 500 error in the Console tab, for a GET request:
But in the Network tab, I don't see that request; I only see a POST request for the same page, with a 200 status:
Shouldn't I be seeing the SplitShip.aspx GET request in the Network tab?
Shouldn't I be seeing the SplitShip.aspx GET request in the Network tab?
You should of course, but maybe this request has been made using an AJAX call or something. So make sure you apply proper filter to your Network tab by selecting All:
This way Chrome will show All requests being sent to the server, including XHR ones. Are you seeing the smoking gun now?
Somehow, we are able to make a cross origin XHR request on Chrome (latest stable) & Firefox without using CORS or anything of the sort. I am puzzled by this, hence this question.
Make an XHR Post Request to http://partychat-hooks.appspot.com/post/p_mwe2ztni with the data:
{body:"Some text"}
If you are on a Jquery enabled site, just type $.post("http://partychat-hooks.appspot.com/post/p_mwe2ztni",{body:"Hello World"}) on the console. SO has Jquery, so you can just press F12 now and paste this in your console.
The request goes from "Pending" to "cancelled" over in the network tab. The browser even gives us a warning about However, wireshark tells me that the request is actually getting made. (and is confirmed by a ping on the chatroom (join us at abhshkdz#im.partych.at)).
The following screenshots shows 3 things:
The request was made by JS
The browser aborted the request as it was a Cross-Origin Request w/o CORS. (Presumably an OPTIONS request should have been sent)
The popup on top-right shows that the request succeeded somehow.
Here is a screenshot of WireShark showing the Request response (served over Google AppEngine)
You can get the pcap file from here.
Also, notable is the fact that I don't see any OPTIONS request being made by the browser at all (which it should to check for CORS support).
Someone please help us solve this mystery.
Provided the request is a 'simple method' (GET/HEAD/POST) and the headers are all 'simple headers', then the browser can follow the 'simple' steps for the request, which don't include an OPTIONS pre-flight.
I'm wondering if an invalid or expired SSL certificate could cause some ajax posts via Firefox to fail (not all ajax posts, some are successful)? I'm trying to determine the cause of my ajax request via firefox to be aborted (and is not seen in other browsers). If I'm using Fiddler, the post does work too.
Yes, attempting to connect to an HTTPS site that has an invalid certificate (for whatever reason) with a XHR request will make this request fail. Unlike direct requests, it won't be able to display the usual certificate warning message to ask you whether you want to proceed.
I just wanted to check if my HTTP caching for my website is working especially since I moved to a CDN.
Now I used both Fiddler and Firebug and what I am seeing is that requests for ALL scripts and images on my page every time I navigate to it. Response code is 200.
If I open the page in Chrome, the developer tools also show me all these requests but Chrome also tells me that the requests are served from the Cache. Chrome requests are not listed in Fiddler (while FF and IE requests are).
My original assumption was that if Firefox or Internet Explorer get a file from their cache that request wouldn't show up at all in Fiddler.
I checked my caching headers and since Chrome behaved exactly like I expected I am asking myself if my assumption about Fiddler was wrong. Are FF/IE behaving differently when Fiddler is started? Is Fiddler showing cache hits?
As a network proxy, Fiddler is not able to show anything that comes out of the cache. If you see a request in Fiddler, then that request was sent over the wire.
One thing to keep in mind is that if you're refreshing the page (e.g. with the button or F5) then the cache can be bypassed; see http://blogs.msdn.com/b/ieinternals/archive/2010/07/08/technical-information-about-conditional-http-requests-and-the-refresh-button.aspx
I've just come across a problem relating to IE that there seems to be virtually no documentation about on the 'Net - only a few people asking similar questions.
When I use jQuery (1.4.2) to send a POST request to my server (to which the server responds by sending JSON data), I occasionally get XHR 408 errors (meaning that the server timed out while waiting for the client to finish its request), and (less frequently), XHR 12152 errors (I don't know what these signify). There does not seem to be a pattern to this.
This only occurs in IE (version 8 - I haven't tried other versions, though I can confirm that the problem occurs on two different installations). Safari and Opera seem fine.
This doesn't seem to be a problem with GET requests.
If anyone has any thoughts on the matter, I'd be very grateful.
When you see IE returning things in status that clearly aren't HTTP status codes, they're actually Windows error numbers, typically from WinInet.
12152 ERROR_HTTP_INVALID_SERVER_RESPONSE would seem to confirm the 408's implication that there's a low-level HTTP-syntax problem between your browser and the server. Traditionally this has been a problem with the ActiveX implementation of XMLHttpRequest and keep-alives in HTTPS, but the exact cause is rather murky.
You could perhaps try having the server set Connection: close on XMLHttpRequests that come from IE, see if that helps? This will affect performance, unfortunately.
I solved it by adding "Connection: close" to ajax header also.
There is no need to add "Connection: close" to the response header from the server.
I have tested firing 1,000 requests.