I've written a bunch of xhr stuff over the years, but today I ran into a curious thing. In firefox with firebug every time my server responds, I get a syntax error in the console. And the error context is the message response text.
The message response text is a string of numbers separated by pipes "|".
Sure it's not valid xml, but I've never sent valid xml before and never had a problem.
Is this a firebug thing or is firefox really unhappy about my response text?
No. It can be xml, json, or some other structure of your choosing.
Related
Getting a 416 error when trying to GET a website with HTTParty. Works just fine in the browser.
I have never gotten this error before, so I went online and found this:
It occurs when the server is unable to fulfill the request. This may
be, for example, because the client asked for the 800th-900th bytes of
a document, but the document is only 200 bytes long.
The request includes a Range request-header field, and not any of the
range-specifier values in this field overlaps the current extent of
the selected resource, and also the request does not include an
If-Range request-header field.
Wondering if anyone has gotten 416 with HTTParty before and if there is a way to prevent this form happening. Thanks
Example website where error occurs:
http://www.bizjournals.com/jacksonville/blog/morning-edition/2014/07/teens-make-up-less-of-summer-workforce-than-ever.html
It appears that bizjournals is able to detect you are a bot (not accessing in the browser) and therefore returns a 416.
irb(main):005:0> HTTParty.get('http://www.bizjournals.com/jacksonville/blog/morning-edition/2014/07/teens-make-up-less-of-summer-workforce-than-ever.html').body
=> "........As you were browsing <strong>http://www.bizjournals.com</strong> something about your browser made us think you were a bot. There are a few reasons this might happen........"
You could either ask bizjournals to allow you to make requests or try to change the headers to make bizjournals think you are not a bot.
I have a web application that crashes on ajax requests with google chrome (it works with every other web browser it was tested it). After debugging I found that the error is caused by response.responseText being undefined. The xhr object looks like this:
argument: undefined
isAbort: false
isTimeout: undefined
status: 0
statusText: "communication failure"
tId: 3
In debugger in the 'network' tab I get "(failed)", however all the headers are there and I can even copy into clipboard the response body (which is a valid JSON).
My question is - how can I debug this problem? Where to find additional information, what causes this request to fail?
I finally found the solution to my problem : AdBlocks, when it blocks an ajax request, it just says "communication failure".
The first thing I would double-check is that the data coming back from the response is valid JSON. Just pass it through a JSON validator like this online JSONLint: http://jsonlint.com/
I assume that you are using something like jQuery to make your AJAX requests. If so, then make sure that you are using the development version of that library. Now that you are using the development version (uncompressed) of the script, find the particular function that you are using (eg. $.ajax) and then, within the Chrome inspector, insert a breakpoint in the code where the AJAX response is first handled (eg. https://github.com/jquery/jquery/blob/master/src/ajax.js#L579). Then proceed to step through the code, inspecting various return-values to see exactly what is going wrong.
If you are not using something like jQuery to make AJAX calls, then I'd recommend using a framework to avoid possible cross-browser compatibility issues like you might be experiencing right now.
I've got a .NET MVC site that uses JSON to perform AJAX form Posts. If a validation error occurs (ie user misses a required field etc), then the server returns the validation errors in a JSON object and sets the HTTP status code of the response to something in the 400 range. On our local machines, this works absolutely fine.
However on our CI environment, it has suddenly stopped working, without any code changes. The response comes back from the server with the correct HTTP code, but the content is not the JSON our controller returns, but the standard .NET error page HTML, ie just the 11-byte 'Bad Request' response if the status code is 400.
The error code is correct for each validation error, so we are hitting the right controller/action, and the validation is working correctly, but for some reason our JSON is getting snipped out. Any ideas why this might be happening?
You are getting 400 code because your request syntax in not correct. Check if you have actually encode json data correctly or not.
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 have 3 AJAX functions to move data between a Django app on my website and some JavaScript using YUI in the browser. There is not a major difference between them in terms of their structure, concept, code, etc. 2 of them work fine, but in the 3rd one, I get one spurious HTTP request immediately after the intended request. Its POST data contains a subset of the POST data of the intended request. The request meta data is identical except for the CONTENT_LENGTH (obviously) and the CONTENT_TYPE which is 'text/plain; charset=UTF-8' for the intended and 'application/x-www-form-urlencoded' for the unwanted request. I do not set the content type explicitely at all which seems to suggest both requests do not have the same origin and the second one just pops out of thin air.
The intended request sets HTTP_CACHE_CONTROL': 'no-cache' and 'HTTP_PRAGMA': 'no-cache', the spurious one does not. The dev server log output for both requests is
[15/Feb/2010 15:00:12] "POST /settings/ HTTP/1.1" 200 0
What does the last 0 at the end mean ? Could not find any documentation on that. This value is usually non-zero... In Apache, it is the total size in bytes of the server response, can someone confirm it's the same for Django ?
My problem obviously is to find out where this additional request comes from.
I am fairly familiar with JS debugging using Firebug and I think I'm good at Python and Django, but I do not know a lot about the internals of HTTP requests and responses. I can breakpoint and step through the JS code that sends the intended XMLHTTP request, but that breakpoint does not get hit again.
The problem occurs with both FF3 and Safari, I'm on Snow Leopard, so I can't test with IE or Chrome.
I've looked at Django debugging techniques and tools like http://robhudson.github.com/django-debug-toolbar/ but I think I already have the information they can give me.
Can someone advise on a strategy or a tool to narrow the problem down ?
The problematic AJAX function submits form data, the working two don't. Forms have a default action which takes place when the form is submitted: post a request with the form data. I failed to prevent this default action.
So the spurious request did indeed come out of the dark underwood of the browser, there is no code in my js files that sends it.
Solution:
YAHOO.util.Event.preventDefault(event);
at the beginning of the form submit event handler.
See also http://developer.yahoo.com/yui/examples/event/eventsimple.html