: Is there additional overhead for status code 500s? We have these web applications that require specific information in a query string. If that information is not provided, the applications throw

@Carla537

I can see valid arguments for both ways. On one hand, the HTTP/1.1 standard, section 6 defines the 4xx and 5xx status codes like this:



4xx: Client Error - The request contains bad syntax or cannot
be fulfilled
5xx: Server Error - The server failed to fulfill an apparently
valid request



In this case, you say that a URL without the "specific information in a query string" is not an "apparently valid request", and such a malformed request can never be fulfilled by the application. Thus, formally, this is a client error, and the response should be a 4xx status code (e.g. 400 Bad Request, or possibly 404 Not Found).

On the other hand, from a practical viewpoint, there's no real reason not to just return a 500 Internal Server Error response if that's more convenient for you. Yeah, it's a little silly that your app is basically claiming that the URL is valid but it always fails to handle it, but let's face it, HTTP response codes are meant for computers, and computers don't care about "silly".

I suspect that, in practice, the only likely difference between 400 and 500 responses is that some search engines, if they somehow came across such an invalid URL, might be a little less eager to retry the request after a 400 response than after a 500. But even that is a rather marginal use case.

I'd say that, if you have no other reason to choose one or the other, you should use a 400 response for the sake of semantic accuracy, but if your app is already generating 500 responses, there's no real need to change it. There is no "additional overhead" for it — it's just a number.

Of course, I can't say anything definite about what happens inside your app and webserver. It's perfectly possible, though unlikely, that your webserver might do something very laborious whenever it sees a 500 response, in which case you indeed should avoid them. Somewhat more likely is that your app might waste some time processing the malformed request before encountering the error, in which case detecting such requests early could indeed save time (but only at the cost of a small amount of extra time for each valid request). In any case, it seems unlikely to me that your app would spend more time processing an invalid request than a valid one, so (unless valid requests are somehow difficult to generate) a potential DoS attacker could just spam you with valid requests instead.

Vote Up Vote Down

@Frith620

There is no extra overhead for a 500 status code. I would argue that your management is correct, because the application can accept queries at that URL, provided it is given the appropriate arguments.

Returning a 404 error instead of a 500 error to combat DoS attempts is really just an appeal to security through obscurity.

Vote Up Vote Down