4

If someone makes a request with a Content-Type that doesn't match the syntax of the request body, how should the server respond? Is there a standard way of handling this (seems like there would be), or is it up to the discretion of the service implementor?

EG Someone posts something with Content-Type 'application/json', but the post body has urlencoded syntax. How should this be handled?

  • 2
    From a security point of view, whenever you can't think of a valid response to a network request, "do nothing" is always the best response. But I'm not sure how common it is for client programs to make this mistake. – Ixrec Jul 21 '15 at 21:46
  • 1
    You could also return an HTTP status code of 400 ("Bad Request"). – Ixrec Jul 21 '15 at 21:53
  • 1
    @Ixrec Huh? What's that? Is this supposed to be json? My json parser cannot read this at all and it's plain to see that this is a command to operate on my file system. Jeeez, these client's these days are messing up the simplest things. But I'm a good server and obviously run this rm ... command instead of parsing it as json. – null Jul 21 '15 at 21:58
  • Be liberal in what you accept and conservative in what you produce. Nobody should ever generate urleencoded request bodies that say 'Content-type: application/json', but in reality sometimes they do. It's perfectly fine to accept them and parse them and understand them. At the end of the day, sometimes you've just got to deal with non-conforming clients. – Miles Rout Mar 5 '17 at 2:24
5

You should respond with HTTP 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.

The response body should include an explanation of why the request was rejected—e.g., “Invalid JSON”.

  • Figured as much, but wasn't sure if there was a standard for the content returned with the response. Do you see anything wrong with just returning generic response content, like "Invalid Request Body"? – EJay Jul 21 '15 at 22:08
  • Generic responses (without HTTP status codes) will not be understood by many clients; they will assume their message was ok and just fail to decode your answer. Worse yet, they can just send you a message and just ignore the answer ("Server answers status is 200: Ok, so my message was correctly processed; that is all I need to know") – SJuan76 Jul 21 '15 at 22:19
  • @ej_dutch: It depends on the circumstances. I would try to err on the side of providing good error messages, since it makes an API much nicer to use. In this case it’s pretty simple—“You submitted a JSON request with invalid JSON”. – Jon Purdy Jul 21 '15 at 23:02
  • In case it isn't clear, if you provide error messages like this they should be in the response body, and you must still give an HTTP 400. You are technically allowed to say 'HTTP/1.1 400 Invalid JSON' instead of 'HTTP/1.1 400 Bad Request' but that's bound to confuse some clients. – Miles Rout Mar 5 '17 at 2:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.