Need Help on HTTP Status Code

Imagine the following situation:

  1. You have an HTML sign up form for a user.
  2. One of the fields is for the user’s email.
  3. The user fills in the data and POSTs the response to the server.
  4. The server rejects the request, perhaps the email address is already taken.

Is there an appropriate HTTP status code for this? It seems to me this falls into the 4xx range since the client provided invalid data. Its not a 400 though since the server understood the request. And none of the other 4xx codes seem to fit.

I ran into a similar situation today, except that I’m doing it via an XmlHttpRequest. When posting some data to the server, the request always returns HTTP status code 200 whether or not data was actually inserted into the backend database. Thus, the server has to return back a response that tells the client what happened – probably via a little bit of JavaScript. But it seems like using an HTTP status code would be a much cleaner solution.

Any ideas? Or am I trying to misuse HTTP status codes?

Update – I’ve happily found my answer. A similar problem was posted by Jan Algermissen on the Yahoo Rest discussion list. Bill de hora answered use a new HTTP status code, 418. And in response to that, Roy Fielding, one of the authors of HTTP specification, asked if he should standardize it. Yes please.

Now, let’s see what happens when I try this trick with the browsers.

  1. March 31, 2006

    I think the 4xx (client errors) are intended for errors within the HTTP protocol, not within data carried over HTTP.

    Remember the second T in HTTP stands for transport – its intended that applications build *on top* of that transport, not use it exclusively.

  2. March 31, 2006

    Whether or not it’s an appropriate use, your specific scenario sounds like a 409 Conflict. The resource that is in conflict is the username and the user can resolve the conflict by resubmitting the request.

    If it works for you, use it.

  3. Charlie
    March 31, 2006

    Jonno – I see what you are saying, but this seems like a reasonable use of HTTP codes to me. For example, 402 is “Payment Required” while 409 is the resource is in a conflicted state. Neither of those indicate problems within the HTTP protocol itself, they are more about the state of the resource. What I’m after is some code like “Invalid Request” – yes the server understood the request, but no, it doesn’t want to fullfil it. Having said that, I suspect my view is incorrect because this seems like such an obvious thing that it must have been discussed and rejected for some reason during HTTP’s development (haven’t found anything on Google yet though).

  4. Charlie
    March 31, 2006

    Jeff – I considered using 409. But it seems like a bit of stretch. The last paragraph in the HTTP RFC worries me:

    Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can’t complete the request.

    Thus, it seems that 409 is really only about conflicts.

  5. June 30, 2006

    Hi Charlie,

    FYI: Later on in the mailing list they talk about using the status code “422 Unprocessable Entity” instead of inventing a new one. It was standardized for WebDAV,
    and its intent was to say that the format itself may be parsable, but that the parsed data is invalid.