Take the 2-minute tour ×

Imagine you've got a form on a page, and you POST that form's data to the server in an AJAXian way, e.g. jQuery.post(). The server judges that the data is invalid because, say, the email address doesn't contain an '@' symbol.

I think that the spirit of HTTP says the server should return an "HTTP 400 Bad Request" status code with its response to indicate to the client that it couldn't process the request. The reason (data didn't validate) should be in the body of the response.

But I'm working in an ASP.NET MVC environment that has traditionally implemented "partial views"--HTML fragments sent as responses, meant to be substituted into the client's DOM when received from an AJAX request. In this paradigm, the server typically constructs an alternative version of the form, filled with the (invalid) submitted values and styled with red highlights and alerts indicating that the email address was invalid and should be corrected. The client substitutes that form into its DOM, and the user sees the problem.

This is a common enough pattern in MVC world, but I don't see anybody taking the care to set an appropriate HTTP status code. I can't figure out why.

Is it "okay" to include HTML markup in a non-HTTP-200 response so that the client can show a validation? I can't find anything that says it isn't.

share|improve this question
"I can't figure out why." Just want to comment on this: Sometimes all error status codes are mapped to the status-code 200 as part of a general blanket security concern - for the same reason you'd not want an attacker to see stacktraces, sometimes you also don't want your error code to convey if the request broke it or an internal server error broke it, or anything that 'detailed'. (continued) –  pinkgothic May 25 '11 at 9:48
So you blanket-map everything outside the allowed ranges to 200. The reason 200 is often picked is twofold: (1) because picking an error code that can be used as a blanket-wrap for 4xx/5xx isn't really trivial; (2) because it forces automated attacking tools to analyse the message body to see if they hit on something. (continued) –  pinkgothic May 25 '11 at 9:48
It's security by obscurity, of course, but fairly common as far as I'm aware. So maybe that's people's 'motivation'. It's equally likely they just didn't give it a thought, though (the status-code mapping is often done at webserver level, so the application itself? Can send whatever it wants). –  pinkgothic May 25 '11 at 9:48

2 Answers 2

up vote 0 down vote accepted

If you know that the response could be parsed, send a json/xml document with the right mime type and informations inside. Else just send a human readable HTML content. In both cases obviously set the right HTTP status code.

share|improve this answer

Depends on how you will use that code, but most definitely: Yes.

share|improve this answer

Your Answer


