HTTP/1.1 Status Codes 400 and 417, cannot choose which

Question

I've got a processing file which handles the user sent data, before that, however, it compares the input from client to the expected values to ensure no client-side data change.

I can say I don't know lot about HTTP status codes, but I have made up some research on it, and to choose which one is the best for unexpected input handling. So I came up with:

400 Bad Request: The request cannot be fulfilled due to bad syntax

417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field

Now, I cannot be really sure which one to use, I have seen 400 Bad Request being used alot, however, what I get from explanation is that the error is due to an unexistent request rather than an illegal input.

On the other side 417 Expectation Failed seems to just fit for my use, however, I have never seen or experimented this header status before.

I need your experience and opinions, thanks alot!

For a full detailed with form/process page drafts, and my experiments, follow this link.

Addition: One another reason-why I want this is to prevent Google manipulation. This will not only to be used in backend, but also in frontend where guest/user interaction will be shown and the page's content to be presented.

I believe*, Giving 200 OK or 403 Forbidden status codes are valid for pages that are existent, or allowed to be existed.

*Addition two: I've looked into 417 and 100 now, found that they're similiar to what I try to do (only for upload processing case, at least), in here: http://benramsey.com/blog/2008/04/http-status-100-continue/

• i.e: *A web page linking to the X site with http://www.example.com/page.php?query=lol&query2=fail would get indexed by Google since HTTP header is given as OK.

SOLUTION I CAME TO:

Indeed 404 is what I might be ending up with again. I just wanted a different solution than that, if HTTP provided it, but so far it seems 404 is still the best solution usable for this, thank you, all, my question has found it's answer.

Answer 1

If the parameters for a GET request are incorrect, the canonical thing to do is send back either a 404 (not found), or 200 (OK).

The RESTful way to use GET requests is to query a resource (get something). Therefore, if the required parameters don't correspond to an extant resource (because they are incomplete), you can accurately say the resource as queried in the URI is not found.

Practically, if you want to avoid things like browsers ignoring your 404 page and substituting their own (I am looking at IE 9 and 10), you may want to use 200. If you consider your application to be the resource, 200 is appropriate; you queried the application, and it returned a result (that happened to be an error, but not at the HTTP level). However, this use is not very RESTful.

Answer 2

The 417 error should only occur when the client sent an HTTP Expect header that the server could not fulfill, which doesn't relate in any way to the application's "expected inputs" in the request. Do not use it.

On the other hand, a 400 error should be sent only when there is bad syntax in the HTTP request that the server doesn't understand.

Neither of these is really appropriate for a validation failure in application logic, though I suppose 400 is a little more appropriate.

The 403 error that you were contemplating using in your question over on Stack Overflow is the best option in my opinion.

I just used 403 Forbidden header when the expected values weren't found in the $_GET, but, when thought for, it isn't really an action that requires login(not for this, ofcourse a user have to login to view the admin panel in the first place), it's more like an unexpected value input.

You're thinking of 401, which is the response code that's utilized when authentication is needed. 403 is a generic deny of the request, which sounds like exactly what you want.

This all assumes that you want to return a 4xx response code.. which makes sense for an API.. but for a user-facing HTML page, you'd more likely want to send a 200 with the error information in the body.

Answer 3

I can't quite figure out what your doing however there is an additional option that you may not have considered - 200 - OK. The reason is that you received the data correctly the problem is it's not valid for your application which isn't really a problem with the HTTP protocol.

The relevant rfc here is rfc2616. You could use 400 but you then need to provide the client the ability to modify the data, from the rfc

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

Regarding the 417 the rfc says

10.4.18 417 Expectation Failed

The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.

so if you're not using the expect header you probably shouldn't use this response.