By default, the HTTP response code for "file not found" has always been 404. I never really thought about it until recently someone was saying that if the missing file is part of an application then the response should be 500 (internal server error) because it's not a client error (4xx error class). The example for that situation was when the deployment for media files failed.

So, in that situation, should the status be 404 or 500? If it's 404, what is the reason for that situation?

  • 1
    404 is a client asking (or guessing) for something nobody knows if it exists. The server looks for it and it does not fail at searching. it just doesn't find it. 500 is the server failing at searching/serving the file due to a crash that was not meant to happens.
    – Laiv
    Commented Mar 20, 2019 at 13:53
  • @Laiv their idea is they don't want to show to users a 404 page because the client app doesn't have search feature. So, when the user stumble upon a broken link then it must be a server issue
    – imel96
    Commented Mar 20, 2019 at 14:23
  • I think you need to clarify a bit here: for starters, is the file in question being retrieved by the call or is it some sort of configuration file?
    – JimmyJames
    Commented Mar 20, 2019 at 14:32
  • 4
    I agree with your friend. If a web application is borked because a file it needs to run properly is missing, on an URL that would otherwise be valid, it's a 500, not a 404. Commented Mar 20, 2019 at 14:46
  • 1
    @Laiv I don't think that's right on the semantics. The text of the RFC states: "The 4xx (Client Error) class of status code indicates that the client seems to have erred." That's clearly not the case here.
    – JimmyJames
    Commented Mar 20, 2019 at 15:12

2 Answers 2


Technically, if there's never a reason why this file should be unavailable when your application is configured and running properly, you probably should return a 500 (or 500 class error). It's an unexpected server side issue.

In practice, however, it's typical to use a 404 here because that's what web servers tend to do on static file retrieval. I wouldn't spend a lot of time on trying to fix this unless there's some meaningful impact either way.

  • 1
    I agree, if we rely on semantics then a 5xx error would be the most indicated (the server is unable to fulfill the request as it has encountered an unexpected condition that prevents it from completing it successfully), however probably a 404 is the best choice when we talk about missing imported static files (usually a 5xx error implicitly refers to a malfunction, not to a missing file). Upvote for I wouldn't spend a lot of time on trying to fix this unless there's some meaningful impact either way.
    – n0idea
    Commented Mar 22, 2019 at 8:56

As far as I understand it, there is no way to know that "missing file is part of an application". Client comes with some URL "https://example.com/foo", and the "foo" is just not there. Was it client mistake of application improperly installed? You don't know, but generally you assume that the first is more probable. So it's 404. If you verify path some other way, and conclude that the path would be working if you install the application properly, then you can return some 5xx status, for example "503 Service Unavailable";

  • I'm going to upvote this, but no further analysis is required. If the application falls over because a deploy file is missing on an otherwise working URL, it's a 5xx. Very likely, the server with throw some sort of exception before it ever determines that the URL is valid. Commented Mar 20, 2019 at 14:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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