When I make a XmlHttpRequest (via jQuery's $.ajax) to a particular URL, my Chrome consistently hangs every time with a status on the request of 'Pending'.
After that Chrome must be closed ie. forcibly from Task Manager, and it exhibits general signs of mayhem such as the Cookies and Scripts tabs being empty when they were full of normal looking data immediately prior.
This is odd because (a) my coworkers, running a seemingly identical everything, have no such problems; (b) I have been using Chrome to run this code (our company's JavaScript app) for many months and this just started happening for no apparent reason.
I checked out the Apache logs, they appear to be processing the request normally and to completion, but Chrome never sees the reply, apparently.
A couple of other clarifications: prior to the failure, the same Chrome and Apache return a truckload of JS and image files normally, eg., things seem to be fine right up until they aren't. The request is not particularly large (a few hundred bytes in and out) or complex in any obvious way.
If anybody can give me some hints of where to look, I'd be grateful!
I'm experiencing similar behavior with slightly different symptoms. My ajax requests work fine, every second request up to 6 requests, then they all start failing (same url as when working, same payload, etc), but in my case they're not even hitting the server, just stuck in "Pending" in Inspector.
I dont have an answer for you, but to help debug, have you tried chromes net-internals?
Point your browser at:
chrome://net-internals/#sockets
and/or
chrome://net-internals/#events
I see my requests in #sockets go into "active", but never come back, and in #events I can see that the request stalls after the HOST_RESOLVER_IMPL_REQUEST stage.
I'm thinking it could be a resource issue caused by not properly ending the request, but thats just pure speculation.
I just spent several hours of my life debugging this problem. I'm documenting it here for others.
Question:
I'm getting the following error when I try to click on an AjaxLink in Internet Explorer:
Wicket: ERROR: Wicket.Ajax.Call.failure: Error while parsing response: Object required
It works fine in all other browsers; just IE is busted.
Check to make sure that your HTML is 100% syntactically correct. Ajax responses are returned to the browser inside a CDATA section, and if the payload is not well-formed, IE will sometimes choke.
In my case I neglected to close a <link> tag in the <head> section. Simply closing that link tag made all the difference.
Aside: if you ever come across a tough-to-solve problem in Wicket, it's a good idea to create a quickstart project that reproduces your issue. It can be a lot of work to boil things down, but in doing so you often find the source of the problem.
I want to note one more potential reason for the issue with Wicket's AJAX in IE. It might help someone, who encounters similar problem.
In my case I had the following error message in IE:
Wicket: ERROR: Wicket.Ajax.Call.failure: Error while parsing response: could not find root <ajax-response> element
The reason was an incorrect Content-Type of AJAX response. I used AbstractTransformerBehavior and there was a bug in Wicket 1.4.x so this behavior was rewriting response Content-Type with text/html. IE does not parse such response as XML.
I'm using ABCPdf to convert HTML to a PDF. I'm using the method:
AddImageUrl()
This works fine in Dev and UAT, but on Production I continuously get the message:
Unable to render HTML. Unable to load
page
Anyone see this before? Need more info?
-Ev
I guess you are tying to do URL->pdf generation. It is difficult to directly to do URL->pdf conversion. We ended up URL-Save HTML in local folder ->read HTML and convert to PDF-> delete HTML file from folder - tricky approach but it works. The only flaw is that you need to give read/write permission on a folder on server. Its still better than decreasing security settings.
have you take a look at this http://www.itjungles.com/dotnet/abc2pdf-unable-to-render-html
The default timeout for abcpdf is 15 seconds. If the page is taking longer than 15 seconds, you will get this exception.
Add the line below just after object creation of the document to resolve the issue.
theDoc.XHtmlOptions.Timeout = 10000000;
I found by working backwards (removing elements) from a target html page that omitting the tag (of all things) created this error. also, calling localhost in the target url generated this error.
I have no idea what caused this error, but I stopped the scheduled task that was running, then restarted it and it's worked fnie ever since.
I'm trying to perform an Ajax/XMLHTTPrequest from within a local HTML file in QT 4.7RC QWebview. It consistently fails with an empty responseText and status 0. I've set the follwing
page->settings()->setAttribute(QWebSettings::LocalContentCanAccessRemoteUrls,true);
but it has no effect (I can load remote images without problems though).
It seems to be a known issue and I'm not sure if there is a solution already.
https://bugs.webkit.org/show_bug.cgi?id=31875
Any ideas for a workaround would be very helpful. Basically what I'm trying to do is running a HTML/Javascript WebApp in QWebview that talks to a local server at 127.0.0.0 and this problem is kind of a show-stopper. Interestingly, the actual query is sent and my server responds with 200 and the requested data. But the response never arrives in my Javascript callbacks.
Not sure about your question but are you sure that you are inside an AJAX security sandbox that works with webkit? In Firefox, IE and others using AJAXin different domains does not work. In fact, http://demo1.demo.com is different than demo2.demo.com
For some reason, while using AJAX (with my dashcode developed application) the browser just stops uploading and returns status codes of 0. Why does this happen?
Another case:
It could be possible to get a status code of 0 if you have sent an AJAX call and a refresh of the browser was triggered before getting the AJAX response. The AJAX call will be cancelled and you will get this status.
In my experience, you'll see a status of 0 when:
doing cross-site scripting (where access is denied)
requesting a URL that is unreachable (typo, DNS issues, etc)
the request is otherwise intercepted (check your ad blocker)
as above, if the request is interrupted (browser navigates away from the page)
Same problem here when using <button onclick="">submit</button>. Then solved by using <input type="button" onclick="">
Status code 0 means the requested url is not reachable. By changing http://something/something to https://something/something worked for me. IE throwns an error saying "permission denied" when the status code is 0, other browsers dont.
It is important to note, that ajax calls can fail even within a session which is defined by a cookie with a certain domain prefixed with www. When you then call your php script e.g. without the www. prefix in the url, the call will fail and viceversa, too.
Because this shows up when you google ajax status 0 I wanted to leave some tip that just took me hours of wasted time... I was using ajax to call a PHP service which happened to be Phil's REST_Controller for Codeigniter (not sure if this has anything to do with it or not) and kept getting status 0, readystate 0 and it was driving me nuts. I was debugging it and noticed when I would echo and return instead of exit the message I'd get a success. Finally I turned debugging off and tried and it worked. Seems the xDebug debugger with PHP was somehow modifying the response. If your using a PHP debugger try turning it off to see if that helps.
I found another case where jquery gives you status code 0 -- if for some reason XMLHttpRequest is not defined, you'll get this error.
Obviously this won't normally happen on the web, but a bug in a nightly firefox build caused this to crop up in an add-on I was writing. :)
This article helped me. I was submitting form via AJAX and forgotten to use return false (after my ajax request) which led to classic form submission but strangely it was not completed.
"Accidental" form submission was exactly the problem I was having. I just removed the FORM tags altogether and that seems to fix the problem. Thank you, everybody!
I had the same problem, and it was related to XSS (cross site scripting) block by the browser. I managed to make it work using a server.
Take a look at: http://www.daniweb.com/web-development/javascript-dhtml-ajax/threads/282972/why-am-i-getting-xmlhttprequest.status0
We had similar problem - status code 0 on jquery ajax call - and it took us whole day to diagnose it. Since no one had mentioned this reason yet, I thought I'll share.
In our case the problem was HTTP server crash. Some bug in PHP was blowing Apache, so on client end it looked like this:
mirek#toccata:~$ telnet our.server.com 80
Trying 180.153.xxx.xxx...
Connected to our.server.com.
Escape character is '^]'.
GET /test.php HTTP/1.0
Host: our.server.com
Connection closed by foreign host.
mirek#toccata:~$
where test.php contained the crashing code.
No data returned from the server (not even headers) => ajax call was aborted with status 0.
In my case, it was caused by running my django server under http://127.0.0.1:8000/ but sending the ajax call to http://localhost:8000/. Even though you would expect them to map to the same address, they don't so make sure you're not sending your requests to localhost.
In our case, the page link was changed from https to http. Even though the users were logged in, they were prevented from loading with AJAX.
In my case, setting url: '' in ajax settings would result in a status code 0 in ie8.. It seems ie just doesn't tolerate such a setting.
For me, the problem was caused by the hosting company (Godaddy) treating POST operations which had substantial response data (anything more than tens of kilobytes) as some sort of security threat. If more than 6 of these occurred in one minute, the host refused to execute the PHP code that responded to the POST request during the next minute. I'm not entirely sure what the host did instead, but I did see, with tcpdump, a TCP reset packet coming as the response to a POST request from the browser. This caused the http status code returned in a jqXHR object to be 0.
Changing the operations from POST to GET fixed the problem. It's not clear why Godaddy impose this limit, but changing the code was easier than changing the host.
I think I know what may cause this error.
In google chrome there is an in-built feature to prevent ddos attacks for google chrome extensions.
When ajax requests continuously return 500+ status errors, it starts to throttle the requests.
Hence it is possible to receive status 0 on following requests.
In an attempt to win the prize for most dumbest reason for the problem described.
Forgetting to call
xmlhttp.send(); //yes, you need this pivotal line!
Yes, I was still getting status returns of zero from the 'open' call.
In my case, I was getting this but only on Safari Mobile. The problem is that I was using the full URL (http://example.com/whatever.php) instead of the relative one (whatever.php). This doesn't make any sense though, it can't be a XSS issue because my site is hosted at http://example.com. I guess Safari looks at the http part and automatically flags it as an insecure request without inspecting the rest of the URL.
In my troubleshooting, I found this AJAX xmlhttpRequest.status == 0 could mean the client call had NOT reached the server yet, but failed due to issue on the client side. If the response was from server, then the status must be either those 1xx/2xx/3xx/4xx/5xx HTTP Response code. Henceforth, the troubleshooting shall focus on the CLIENT issue, and could be internet network connection down or one of those described by #Langdon above.
In my case, I was making a Firefox Add-on and forgot to add the permission for the url/domain I was trying to ajax, hope this saves someone a lot of time.
Observe the browser Console while making the request, if you are seeing "The Same Origin Policy disallows reading the remote resource at http ajax..... reason: cors header ‘access-control-allow-origin’ missing" then you need to add "Access-Control-Allow-Origin" in response header. exa: in java you can set this like response.setHeader("Access-Control-Allow-Origin", "*") where response is HttpServletResponse.