4

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/

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.

Simon Forsberg
  • 103
  • 4
ASertacAkkaya
  • 143
  • 1
  • 4

3 Answers3

4

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.

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • Not really an API, it will only be used by the privileged users(Site Admins), two different upload forms which will be processed in a single file, with query string parameters. Also adding this up to my question, as a good reminder. This will not only take place in backend, but also in the frontend where the guest/user interaction will happen and content will be published. So I am also worried about Google content manipulation by wrong headers. Giving out HTTP/1.1 200 OK or HTTP/1.1 403 Forbidden are only for real-existent contents(I suppose), however, in this case they're user-made values. – ASertacAkkaya Sep 30 '12 at 22:48
  • @TheDeadLike `404` is the response code that should be given if content does not exist. – Shane Madden Sep 30 '12 at 23:34
3

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.

Falcon Momot
  • 24,975
  • 13
  • 61
  • 92
2

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.

user9517
  • 114,104
  • 20
  • 206
  • 289
  • Thanks for extended rfc definitions. I have researched a bit more into HTTP/1.1 417 and found a good example in use of it on http://benramsey.com/blog/2008/04/http-status-100-continue/, which actually partially fits what I do. (accessing to a page that is dependant on query strings, an upload file processer.) It seems to be used for canceling the request when certain expections are not met. – ASertacAkkaya Sep 30 '12 at 22:59
  • @TheDeadLike That would be an invalid use of the response code. The bold, red text at the top of the post you linked covers that. `This post contains some false information. Particularly, you should not send back a 417 Expectation Failed response as a way of telling the client that the server could not fulfill the response because of data presented in any of the request headers other than the Expect header. I have corrected my statements here in a newer post, and I apologize if I caused any confusion.` – Shane Madden Sep 30 '12 at 23:35
  • Yes, I know, that's why I said "partially", I don't know if it's right to use "Expect header" for that, which I suppose not however. – ASertacAkkaya Oct 01 '12 at 00:09