Question

We have a form that absolutely requires JavaScript to function, and validation is done client side. Validation is also performed server side, but it would be an extreme amount of work to get it to show errors when server side verification fails.

Since there is no chance for the user to not have JavaScript, is it OK to just fail with an HTTP error? The only way they would fail server side verification was if they either are a malicious user, or can’t use JavaScript, in which case they wouldn’t be using the form anyway.

Thanks

Answer 1

I say this is fine, except for a certain class of errors.

Some validation errors are not a result of malice but simply cannot be checked and discovered at any other time than when the form is actually processed. This can be because of a scarce resource that needs to be reserved but cannot be (“this username is already in use”), or because of some server-side recoverable error (“The upstream Credit Card processor is not responding. Please try again later”). For these kinds of errors, you absolutely should have some kind of error message communicated back to the user. It’s hard to envision a design where sending these kinds of errors back would not be possible. At the very least you can do this:

1. Send your HTTP error response (4xx or 5xx depending on the nature of the error)
2. In the body of your response, package an error message in some data structure your javascript can understand easily. (JSON or XML, or even text/plain! Remember to set the mime type.)
3. Have the error-handler for the javascript request insert the text of the error at a visible place in your form (e.g. at the top or near the submit button).

The most important thing, however, is to have server-side validation and not trust the client. You are already doing this, so if you want to do anything further it is a matter of polish and making for the best possible user experience. Sometimes that requires a disproportionate amount of effort and that’s ok.