We have these web applications that require specific information in a query string. If that information is not provided, the applications throw an error. It seems to me that we should explicitly handle this with a 404, since the URL without the query string does not point to an existing page.

Most of management seems to disagree with me; they argue:

It's not like anything links to the page without including the correct qs. So the only people who would end up at the 500 page are those who went there deliberately, or because of a broken copy-paste.

Isn't there additional overhead to 500s above and beyond what we might see for 200s and 404s, and if so, wouldn't it be easier for an attacker to trigger a DoS by focusing on URLs that throw an error?

(In this case we're using Oracle Weblogic, but I'm interested in the general case.)


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.