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.