No, it’s not. Falling back on 500 Server Error for everything outside of the “happy path” through your code is sloppy coding.

I say this for three reasons:

The 5xx response codes are for server-side errors.

If the code is working properly but the request is wrong (no such document, an invalid request, or insufficient user privileges for the requested operation), the 4xx response codes are more appropriate. You should only return a 5xx series error message when your application is broken.

A generic “oops” page hides the cause of the error from the user.

Maybe the user followed a bad link, that goes to a document that has been deleted. They should see a 404 Not Found response, not a 500 Server Error. This is especially important if the user agent is a web service client actively under development. And remember that you can still customize the response body, so a 404 can show a search or site map to help them find the content that was Not Found, and a 403 might suggest that the user upgrade their subscription so they can see the Forbidden content.

Failing to trap bogus input is a recipe for a security vulnerability.

Rails will detect ridiculous input in many cases, but it doesn’t know about your business rules.

For example, what if someone fires up Firebug and figures out your API, and deletes her ex-boyfriend’s account because you forgot to check that the ID being deleted matches the currently logged in user? Oops.

You know who else got pwn3d because they put their security rules in the client? AOL. Don’t be like AOL. They got pwn3d big time. Make sure your controller handles the “unhappy path” too, and responds appropriately.

You make sure your controller handles these cases by writing tests, and checking that the response is correct. To do this, you need unambiguous errors that clearly explain what the controller didn’t like about the request.

Your controller tests should never expect an exception. Exceptions belong inside the application (such as between a model and a controller), not at the boundary.

Instead, you should be using something like assert_response :bad_request, and providing a useful textual message in the page that will help the user understand what they did wrong.

A nice bonus of using the right HTTP error responses is that your tests are more readable. And since controller tests tend to be really verbose already (mine tend to be ~10x as many LOC as the controller itself), the extra readability is really nice.

Sometimes this is helpful. Sometimes this is really annoying and incorrect. Assuming you are a moderately well informed sysadmin and know that this message can safely be ignored, you might have been stumped trying to silence it. You may have tried every option in man ssh_options and even some of your own (STFU on?) I think I may be able to help.

First, let’s make sure we understand the situation. OpenSSH is trying to protect you from an exploit. If you are connecting via SSH to www.foobar.com for the first time, you may be vulnerable to a man in the middle attack. If the forward and reverse DNS don’t match, that might be a sign that this sort of attack is being attempted.

If you’re sure you know what you’re doing, though, and your OpenSSH client is warning you about a situation that you already know about, then try the SSH option:

GSSAPIAuthentication no

(I figured this out by using the -vv option to the SSH command line client. It says Next authentication method: gssapi-with-mic right before the error.)

In my case the client and server are already acquainted via mutual public key exchange (client has known_hosts for the server, and server has authorized_keys for the client) so whether or not the DNS entries look hinky is immaterial. I’m in the process of migrating from one hosting environment to another so I can’t “fix” the DNS situation for another couple of weeks. Meanwhile I’m getting these warnings every hour in an email to root, which is annoying, as it currently forwards to me. And since I’m not using GSSAPI, turning it off is fine also.

Please do make sure you know that your situation is secure before disabling warnings like this. OK now I’ve said it enough times, make the annoying warnings go away.