I am using Jetty server with embedded web app. However, whenever I hit any resource which is not present it serves a default page which shows a message "Powered by Jetty".
This page is being served from org.eclipse.jetty.server.handler.DefaultHandler.handle.
I want write a custom handler for this, however while trying to register custom Handler in jetty.xml file, I am getting syntax exception and server doesn't start anymore.
I was able to resolve this issue by doing some tweaks along with changes mentioned in Deactivate Jetty's default 404 error handler.
Related
I have a requirement to catch this exception or show some log if browse with below invalid filename :
http://localhost/ABC/xyx.asmx
Server Error in '/' Application.
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /.asmx
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.8.4261.0
In web.config, you have two methods to custom error page.
When the error is caused by IIS or any other but not asp.net, IIS will shows error page like these.
If you want to change them, check the custom error pages in Error Pages module. Then delete the existing status code and corresponding page path, and add a new one.
When the error is caused by the asp.net, IIS will show error page like yello screen of death(YSOD). You can change it in section. If you want to show custom error page to remote visitor and YSOD to local vistor, you can set mode to RemoteOnly. You can configure this in .NET Error Pages Module.
I have an application that I'm deploying on a private CloudFoundry instance, using the Ruby buildpack. Sometimes, an in-bound request causes my application to crash and the container to restart. At this point, the user is served an error page, saying something like Error 502 - container was unable to service your request, or something. This is not an error served by my app, but by the infrastructure, so I don't have any control over it.
My app is designed to be run as part of a dashboard/kiosk that refreshes periodically, and adds a Refresh header to every successful request. The refresh time is dynamic and not always the same value (it may be anything from 5 mins to 0 seconds), and that's why I don't use a browser refresh extension.
When I hit the error page, there is no Refresh header so the page just sits there forever. How can I get CloudFoundry to add a Refresh header to the error page? I'd be content with that value being some static value set in my manifest.yml, but I can't see any option to get it to do that.
You can't modify responses that are generated by the Gorouters. If you want to customize THOSE, you should consider, if you have the authority, to put something in your external load balancer that would watch for errors from the infrastructure (I believe all such errors have headers that start with X-Cf-* but I may be mistaken) and customize when they are received.
We would like to add a maintenance page to our front-end which should appear when the back-end is currently unavailable (e.g. stopped or deploying). When the application is not running, the following message is displayed together with a 404 status code:
404 Not Found: Requested route ('name.scapp.io') does not exist.
Additionally, there is header present, when the application is stopped (and only then):
X-Cf-Routererror: unknown_route
Is this header reliably added if the application is not running? If this is the case, I can use this flag to display a maintenance page.
By the way: Wouldn't it make more sense to provide a 5xx status code if the application is not started/crashed, i.e. differ between stopped applications and wrong request routes? Catching a 503 error would be much easier, as it does not interfere with our business logic (404 is used inside the application).
Another option is to use a wildcard route.
https://docs.cloudfoundry.org/devguide/deploy-apps/routes-domains.html#create-an-http-route-with-wildcard-hostname
An application mapped to a wildcard route acts as a fallback app for route requests if the requested route does not exist.
Thus you can map a wildcard route to a static app that displays a maintenance page. Then if your app mapped to a specific route is down or unavailable the maintenance page will get displayed instead of the 404.
In regards to your question...
By the way: Wouldn't it make more sense to provide a 5xx status code if the application is not started/crashed, i.e. differ between stopped applications and wrong request routes? Catching a 503 error would be much easier, as it does not interfere with our business logic (404 is used inside the application).
The GoRouter maintains a list of routes for mapping incoming requests to applications. If your application is down then there is no route in the routing table, that's why you end up with a 404. If you think about it from the perspective of the GoRouter, it makes sense. There's no route, so it returns a 404 Not Found. For a 503 to make sense, the GoRouter would have to know about the app and know it's down or not responding.
I suppose you might be able to achieve that behavior if you used a wildcard route above, but instead of displaying a maintenance page just have it return an HTTP 503.
Hope that helps!
The 404 Error you see is generated by CloudFoundrys routing tier and is maintained upstream.
Generally if you don't want to get such error messages you can use blue-green deployments. Here is a detailed description of it in the CF docs: https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html
An other option is to add a routing service that implements this functionality for you. Have a look at the CF docs for this: https://docs.cloudfoundry.org/services/route-services.html
After building and deploying, checked the solution management from Central administration and it's up, a simple web service method that only created a Document Library list with a few columns when trying to retrieve the wsdl or even just by calling the WS fromt the adress since its a void method I recieve some error:
The file you are attempting to save or retrieve has been blocked from this Web site by the server administrators.<nativehr>0x800401e6</nativehr><nativestack></nativestack>
The very same method runs fine when called from another web service project that is already deployed so there's nothing wrong with the code. I'm most probably doing something wrong but can't figure.
The system is running on a win server 2008 with sharepoint 2010, framework 3.5 and "ANY" cpu mode.
thank you!
[edit]
Managed to get rid of the previous error by removing asmx extention from the blocked file list in central administration now instead I'm recieving a 404 error:
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /_layouts1/my2claims/tt_claims.asmx
it must run under the same application pool as SharePoint
I'm building a Django web service that is called from an application. When it throws an exception, I can't see the Django debug page, and can't get to it because the calling application doesn't behave like a web browser (and I don't have control over that application).
Is there a way to redirect the Django error page to a a log file rather than to the calling client, possibly via changing the FastCGI config (I'm using lighty + FastCGI)? Or maybe a "dump to file" config option or some sort of LogExceptionToFile() method within the framework itself?
You might try just creating custom ExceptionMiddleware. Just change the process_exception method to log the exception and request data somewhere.
Here's an example: http://www.peterbe.com/plog/who-was-logged-in-during-a-django-exception
If the exception in the django app is not caught, and DEBUG = True, then the exception should be sent to the client.
Some options to help you get debugging info:
Enable and configure logging
Set up email error reporting
Use something like Wireshark to inspect the HTTP request and responses.