Our website runs a lot of javascripts, I want to capture those client side errors, including javascript errors together with http errors (403 forbidden, 404 not found), and send them back to server via ajax call.
Right now I am able to capture javascript errors with window.onerror function, but for those 403 404 http errors I have no clue, this discussion is very helpful if the missing resource has img tag, and I am able to record it, but is there any more general way to detect 403/404 errors, not just for 'img' tag?
PS: I know that chrome console shows all http errors, but I want to detect it using javascript.
Thanks!
Related
Using the Azure Storage JS Client library to upload an image throws an error: "Refused to set unsafe header "user-agent""
All requests in the network tab are 200 or 201, it appears like the xhr requests are working. Is it possible to not set this header or filter it out before the post call? I would like to avoid this error in the console.
https://github.com/Azure/azure-storage-node#azure-storage-javascript-client-library-for-browsers
Have tested the sample azurestoragejs-2.9.100-preview in link you mentioned, it causes no error on my side(both Chrome and Firefox).
Open azure-storage.blob.js lib file, search variable var unsafeHeaders and check whether user-agent is in its list. I saw it on my side and reproduce your problem after deleting it. So it might be missing in your file.
If your lib is unbroken, you can ignore this "error" as nothing goes wrong and it's all implemented by storage lib and browser.
Explanation:
When http request executes, method in this lib will make sure headers in unsafeHeaders list won't be set by xhr. If not, browsers will throw warnings as you have seen, because it's a requirement of xhr standard.
See remarks in this lib.
This check is not necessary, but it prevents warnings from browsers about setting unsafe headers.To be honest I'm not entirely sure hiding these warnings is a good thing, but http-browserify did it, so I will too.
Everyting does work on your side may have proved the check is not necessary. Also in xhr standard, user-agent is no more an unsafe header, but browser doesn't catch up.
In my Google Chrome console I keep receiving errors when the xmlhttp status does not result in 200. For example, in certain cases I intentionally set the header of my PHP files to 500 so in javascript I can display the error and avoid anything that requires that PHP file. Since I have my own error handler for this, is there anyway to suppress the default error?
Error Example:
POST http://localhost/mama/cgi-bin/pages/Module-Install.php 500 (Internal server error)
It seems that there is no way to supress these warnings in google chrome when handling the error yourself. For any of those who are looking for an alternate solution, embed the error code in a json object, and parse the json object client side for any errors.
This error was sended by Server side, not browser, not js. You can not just "hide" it from console. You can handle it in onerror event:
request.onerror = function (e) {
// do something to fix the results of server error...
};
In other words, this is a server error and it CAN break your code execution, but if you make couple steps to resume the job after a possible exception from xmlHttp class, the code will be fine.
UPD:
Just if you are pure perfectionist, and you cares about flawless environment:
In a server side you must implement the server answer without a firing any statuses except 200. It's not a super hard job.
For ASP: Suppressing HTTP 500 response codes;
For PHP: http://php.net/manual/en/function.http-response-code.php .
I've a web application wich makes Ajax requests to a server with Codeigniter-php code. The Ajax requests work correctly in local server but not when the application is hosted in remote server.
The console errors are:
XMLHttpRequest cannot load http://localhost/CI-example/index.php/control/controlHome. Origin http://www.page.com is not allowed by Access-Control-Allow-Origin.
Surprisingly, the request is made in the server but not the response.
The URL that I use to Ajax request is:
AJAX_URL = "http://localhost/CI-example/site/index.php/control/controlHome";
But, also I've tried with:
AJAX_URL = "http://www.page.com/CI-example/site/index.php/control/controlHome";
And the next error is captured:
POST http://www.page.com/webdom/site/index.php/control/controlHome 500 (Internal Server Error)
How can I do?
Edit:
www.page.com is a subdomain. Is necessary to do some configuration when a subdomain is used to Ajax request?
And the folders organization is:
/CI-example
---/application/controllers/control.php
---/system
---/site/js/ajaxRequest.js
As I am getting here, while you are sending ajax requests to the server than it's returning 500 (Internal Server Error). I'm sure that the error is from server side, and there may be following reason-
If everything is fine in the codes, then may be your base_url is different from what you are requesting. Yes this can cause the problem, for example if you have hosted your web application and your base_url is www.mysite.com and you are requesting for mysite.com.
Next reason may be, that you have developed your project in windows or any system which is in-case-sensitive but when you will upload to any linux like server than each and every file name will be case-sensitive. For example suppose a model file name you have given is MyModel.php but when you will load the model, it will generate the error like Unable to find the specific class.
You cannot make HTTP POST requests using AJAX to a different domain, unless that page allows you to do so using a special header called "Access-Control-Allow-Origin".
localhost is different to page.com which is why this will not work.
Response on the http://www.page.com's url say something has gone wrong during the page execution. Your PHP error log should help you to find what.
Adding the line ini_set('display_errors', 1) might return the error to the ajax request, in the error handler. Don't forget to remove the line after use, you don't want this lying around in production code.
The second error is : 500 (Internal Server Error)
This means there was an error on the server side - not a cross-origin policy problem.
This is probably an error in the execution of your PHP script.
Check your error log (e.g : if you use the standard LAMP stack, the error log should be somewhere in /var/log/apache2/)
try this,
http://localhost/CI-example/index.php/control/controlHome
instead of
http://localhost/CI-example/site/index.php/control/controlHome
in your ajax URL.
As from your folder structure, there is no need to include "site" in your URL
We had an interesting issue this morning - the details of the issue itself aren't relevant here, and I already fixed it, but I did run into something strange, to me, about jQuery.
The site I am building internally runs on https, only, so Apache is set to redirect any inbound http request to its https equivalent. This redirect is working fine. But, I had a bug in my software where I was trying to send the following ajax request:
jQuery.ajax({ type: "PUT",
url: "http://somewhere.com/cmdt/todo_lists/8457/toggle",
data: { deployment_id: 827},
dataType: "script"});
I understand that this would fail - I'm alright with jQuery not wanting to follow a redirect. But the actual behaviour is even weirder: I never see an xhr request go out at all! And there's no javascript error! It just fails, silently. If I change the url to https, or to a relative path, it works fine, no problem. My question is, why wasn't it TRYING to send out the request before? And why didn't it raise an error?
The reason you're not getting a failure is because it's a cross-site request, and so instead of using XMLHttpRequest, it's actually generating an HTML <script> tag and dropping it into the DOM, and using that mechanism to load the file.
This works reasonably well (considering it's a complete hack around wrong-headed browser "security" notions) but there's no way for jQuery to trap errors at that point, sadly. You will likely get a browser error if you have developer mode turned on, but that's it.
If you run that from an url that's https and try to open the equivalent http page you run into cross domain problems due to the different protocols they use. Have a look at same origin policy.
I have written a web application that posts a file via http to a restful web service. The web service can reply with a 400 or 403 response if the service finds any problems with the request. The response also contains xml describing the reason(s) for replying with a http error code.
My web application posts the file to a hidden iFrame and uses the iFrame's onload event handler to execute a function that parses the server response presented in the iFrame and let's the user know how the file upload went.
My solution works great with firefox and chrome but not in internet explorer 7.
My problem is that if the server responds with an error code e.g. 400 or 403 internet explorer 7 loads its own static error page. This means that my script can't parse the error message sent in the response since the static error page is not from the same domain as the script itself and violates the same origin policy (and since it's a static error page the web service's detailed error message won't be there anyway).
I see only two workarounds to this problem and I would prefer to avoid them both if possible:
A) Have the web service return 200, when the user-agent indicates internet explorer, even though an error has occured but include a xml response that indicates an error.
B) Have the web application post to an "intermediary" that forwards the request to the web service, reads the response and then translates it to a 200 or anything else that works (so it's basically option A but more flexible and at least this keeps the restful web service "clean").
Is there another way to solve my problem?
Assuming you have control of the server, you may find the best solution is to use the iframe only for sending the file (i.e. one way....client to server). Then use an ajax polling solution to determine whether or not the post was successful. It can be a bit messy, but should be much more reliable, and you can also get information back before the post is complete.
I managed to solve this since a colleague remembered that if the response body is not of a certain length when sending a 4xx response, Internet Explorer will load its static error page.
The workaround is to send back a longer response body with your 4xx response, e.g. a xml-comment containing white space.