Is “404 Not Found” really a client error?

A time-traveler is passing by 2013 and she opens a browser bookmark to

What HTTP status code does she get back from her response?

Well, it’s not going to be 200 OK, because it wasn’t OK with the server. The server couldn’t find the article that the client requested, because it won’t be published for another 43 years.

“Couldn’t find the article” sounds like a 404 Not Found status code. OK, very reasonable choice.

But, “The server couldn’t find the article” raises a bit of a doubt. A 404 is part of the 4xx-series status codes, which are all for client errors. Was this a client error, if it was the server’s fault for not finding the article? Shouldn’t she be getting 5xx Not Found?

HTTP error status codes fall into two broad categories; 4xx (400 – 499) and 5xx (500 – 599). Understanding these categories is more important than understanding the specific error codes, because the categories communicate a very important piece of information. 4xx status codes represent a problem with the HTTP request, whereas 5xx status codes represent a problem with the HTTP server.

However, the line can be blurry between these two categories, if you just consider them the difference between “HTTP request” or “HTTP server”. If resources can be created in the future, and they can, then the exact same HTTP request that was 404 today could be a 200 tomorrow. So, is it really a problem with the request?

To address this confusion, I like to add an additional rule to clarify between 4xx and 5xx. When servicing an HTTP request, was it possible to give a 200 OK response? Let’s say it was a bug-free application server, or possibly even a human being manually processing HTTP requests. If it is possible, given perfect software or infinite resources or a brilliant mind, to process the request, but an error occurred, then it should be a 5xx code response. On the other hand, if no amount of perfection, resources, or brilliance would have been capable of processing that request, then it is a 4xx error.

Maybe our time-traveler should get back a 505 HTTP Version Not Supported response, because the server could never have understood her attempt to use the HTTP/9.7 protocol. But other than that, she should get a good old 404 Not Found; even with bug-free flawless server software, it was impossible to process her request. A 4xx error code suggests that the HTTP client needs to do something differently; like time-travel forward 43 years.

Be Sociable, Share!

4 Comments on Is “404 Not Found” really a client error?

  1. ismael
    2013/09/11 at 12:53 pm (3 years ago)

    I had the same dilemma.

    I have the following situation: “forget password” field accept an email do be submitted. But sometimes the user mistype the email and obviously there must appear some error saying “email does not exists”.

    My dilemma is: Should the server respond with 404 Not Found when typing non-existing email?

    PS: This is done via WebApi, restful method.

  2. Nitin Dhar
    2013/09/15 at 6:50 pm (3 years ago)

    I find this post very interesting, but I’m not sure I agree with your point. Not sure how returning a 5XX response would make sense because there is no way the server could know whether a resource would be available in the future (or if it did in the past for that matter). HTTP, and therefore servers, are pretty stateless in concept and for them to hold this kind of logic doesn’t make much sense. I do think that 404’s are correctly categorized as client errors, since the client is the one requesting something that doesn’t exist. It should be client’s responsibility to figure out what resource to request and how. WDYT?

  3. Jonathan Neufeld
    2013/12/04 at 4:01 pm (3 years ago)

    I would not recommend on relying on 5xx range status codes unless absolutely necessary. If you look at the documented nature of this range of status codes they typically point to hardware or infrastructure failures requiring the intervention of a server administrator (as opposed to the client user) to rectify. That is virtually never the case for objects such as dynamic database-driven entities that constantly come and go.

    > If resources can be created in the future, and they can, then the exact same HTTP request that was 404 today could be a 200 tomorrow. So, is it really a problem with the request?

    Yes, 404 doesn’t imply a permanent non-existence. 410 does.

    Moreover, the semantic definition of 410 implying a permanent state that shall never change is in general a rather antiquated value and perspective of an industry that has proven to be relentlessly dynamic. Furthermore, from a philosophical standpoint, it’s impossible to guarantee. How do you know conclusively that said resource will still cease to exist a millenium from now when grandma Jones tries to access it from her comfy home on Kepler-62e? You can’t prove that it won’t, so the implied permanence is useless if not fallacious.

  4. Navneet
    2013/12/16 at 12:07 pm (3 years ago)

    In that case every non-existent Hostname should return 5xx error which is absurd given the fact it doesn’t exist.
    4xx makes it clear to point that User is wrong is making request which is not there and no matter now many times he tries it won’t be there, whereas 5xx would give hope to user to try after sometime.