I've been looking into New Relic, BugSnag, and a few others, but no one seems to be catching 404 errors in their client-side monitoring. For example, say I have the following script tag in a given page:
<script src="//cdn.example.com/app.js1445291270"></script>
with the minor but critical typo of missing a ? after .js.
This of course returns a 404 and the script never loads.
Are there any services that would catch client-side errors like this?
You should be able to do this with Bugsnag. You can detect whether the status= 404, and use Bugsnag.notifyException() to send the error in. Hope this helps!
TrackJS error monitoring supports this use case. Here is how to add monitoring for resource loading failures.
Related
All of a sudden we are seeing this random error / exception in our web application.
Failed to load resource: the server responded with a status of 502 (Bad Gateway).
In the Log Stream, we are seeing the following details, with specific error code as 502.3 - Bad Gateway: Forwarder Connection Error (ARR).
Also, sometimes in the browser itself we see "The CGI application did not return a valid set of HTTP errors." getting displayed.
Most of the searches for these error codes refer to "IIS / Proxy Server" configuration. But, we haven't changed any such settings.
The error happens very randomly and not specific to any user action/function. Same functionality works first and on second execution immediately after first one throws this error.
How to figure out what is causing this and how to fix?
I google this question, because the program was normal at the beginning, and the subsequent 502.3 error. After I checked the information on the Internet, I feel that it can only give us an inspiration, and it cannot solve your problem immediately.
So my suggestion is that first you browse post1 and post2 I provided.
Next, proceed to Troubleshoot according to the steps of the official documentation. Specific errors require specific analysis.
I am backing a web app with a Flask API that returns custom error codes. The API runs through Apache and the WSGI module, in daemon mode.
I included a WSGIErrorOverride Off instruction in the Apache conf file for the API (which is supposed to be the default but I included it anyway).
Yet anytime my Flask app returns a custom error code (they work when I run the app using the built-in server), Apache sends an error 500. How can I prevent that?
Thanks to comments by duskwuff and Graham Dumpleton, I found that the problem doesn't come from Apache WSGI but from my Flask app.
More precisely, I was using the Flask-RESTful package, which is in charge, among other things, of transforming my views' return values into actual responses.
When those views are decorated (here with an equivalent of #login_required), those decorators are called by the Flask-RESTful package itself, and when an exception is thrown, something goes wrong.
For some reason, my app returns the custom error when I run the built-in server and an error 500 when I run it over Apache. Not quite sure why yet, I'm guessing Flask-RESTful is doing something that is not WSGI-compliant. I was on the verge of dropping it anyway for other reasons, so I'm OK with this solution.
Update: it looks like the problem does indeed come from Flask-RESTful: https://github.com/flask-restful/flask-restful/issues/372
I came across 404 error a few times and i have difficulties in debugging this kind of problem.
What is the strategy and tools available to analyse such problems (firebug, logs...).
How to differentiate and fix the cause ?
page not existing ,wrong path , redirection and rewriting ,server problem ...
404 error code means that a file is not found for whatever reason.
Just check that the file exists and that the path you use is right.
You can analyse sent requests and received responses headers and body in your browser's developper console if you want more details about why some request failed.
We are getting a 405 error and the following exception from IIS7 when attempting to apply a ResponseStreamFilter to HttpResponse.Filter:
HttpException:
The HTTP verb POST used to access path '/app/Thing.asmx/Command' is not allowed.
We are applying the filter by using an HttpModule with code like this:
var rfs = new ResponseFilterStream(HttpContext.Current.Response.Filter);
rfs.TransformStream +=
new Func<System.IO.MemoryStream, System.IO.MemoryStream>(ProcessStream);
HttpContext.Current.Response.Filter = rfs;
Log("Response stream filter applied correctly.");
All of the code in our HttpModule works just fine... it's all wrapped in a try-catch just to be safe and isn't throwing any exceptions, and diagnostic logging like the last line above is working correctly.
But it looks like our ProcessStream method in the above code is never being called. If we apply the filter to HttpResponse.Filter at all, IIS throws the 405 exception before our filter begins processing.
Our code has worked before on several similar systems, so we suspect IIS/machine configuration on this specific server is responsible. What could be causing this?
The most commonly reported cause for a 405 error in a situation like this seems to be using Url.Rewrite. (The HTTP verb POST used to access path '/test.html' is not allowed) However, we are never using a Url.Rewrite.
Another commonly reported cause is trailing slashes in the request URL. (HTTP 405 on Error on HTTP POST IIS ASP .NET) But as mentioned above, the URL being requested does not end with a slash.
The app pool is running .NET 4.0 in a Classic pipeline (jQuery AJAX post receives 405 error (HTTP verb POST not allowed)), but our code has run without issue on many other systems under a Classic app pool, so there would still have to be something unique to this server's configuration. Changing to Integrated pipeline breaks the application our code is filtering, so that's not a possible workaround anyway.
Turns out, it was a very obscure IIS bug:
http://support.microsoft.com/kb/980368
The ExtensionlessUrl handler (*.) was incorrectly getting involved with the request instead of just the WebServiceHandlerFactory (*.asmx) as expected. The workaround was:
Manually deleting the ExtensionlessUrl handler entries from the web application's handler mappings
Manually moving the ExtensionlessUrl handler entries under anything you actually expect to be hit
Adding a web.config entry under system.webServer/handlers to remove the ExtensionslessUrl handler as needed (we went with this option to make sure it got included with app demployment)
We had to burn a Microsoft support ticket on this one, since there's no way we would have figured this out in any reasonable timeframe. Hopefully this helps someone else.
Something is access my site using this URL:
/(Yvax:%20uggc:/jjj.tbbtyr-nanylgvpf.pbz/hepuva.wf)uggc:/jjj.tbbtyr-nanylgvpf.pbz/hepuva.wf
So I get error:
[error] [exception.CHttpException.404] exception 'CHttpException'
Is it something to worry about?
How can I stop YII from reporting on this specific error and other similar 404 errors that are unwanted?
Probably just a scanner script. We get hit by these all the time. Review security, but as long as that checks out you should be fine.